Is there any way to set the character set to unicode in a mail sent by the Servicemix-mail component? Thank you -- -- View this message in context: http://www.nabble.com/Servicemix-mail-content-type-header-tp22274083p22274083.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
Hi, When the methods convertJBIToMail() or convertMailToJBI() from the DefaultMailMarshaler are call, the first thing that they do is do copy mail headers or fill mail headers. For example, when you use the servicemix-mail component to send an e-mail (using the sender endpoint), the component uses the convertJBIToMail() method from the DefaultMailMarshaler. This convertJBIToMail() method first calls the fillMailHeaders() method. It's like this that the mail recipients are populated (using the <to/> tag of the incoming message). The list of incoming tags supported are defined in the AbstractMailMarshaler. By default, the mail charset encoding can't be specified in the DefaultMailMarshaler. Nevertheless, you can define your own marshaler (that extend the DefaultMailMarshaler) to "force" the mail charset encoding. On the other hand, you can raise a Jira to add an improvement request. Regards JB On Sunday 01 March 2009 - 07:29, larjohn wrote: > > Is there any way to set the character set to unicode in a mail sent by the > Servicemix-mail component? > > Thank you > -- > View this message in context: http://www.nabble.com/Servicemix-mail-content-type-header-tp22274083p22274083.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. >(Continue reading)
2009/2/27 cmoulliard <cmoulliard@...>: > > Hi, > > I work very hard since a couple of days on SMX4 (kernel, fuse, ... versions) > and I'm terribly frustrated about the difficulty to package a application > (bnd, pax construct, ...) top of an OSGI server when we have by example non > osgi bundles like iText, JasperReport, Hibernate, ... combined with our osgi > bundles. > > In a development team, the work and workload is distributed between > different team and developers. In consequence, the packaging of such > application where we don't EAR, WAR tools is a critical factor that the > project manager will put in the 'balance' before to take the decision to use > such technology. Moreover, imagine How you will explain to deployer team of > big companies (with poor or insufficient knowledge in java, maven, ant, ... > except maybe if you ask them to copy a file from a folder to another, ...) > how they will deploy your osgi projects in acceptance and next production > environment > > This is why I would like to make the following suggestion to help the debate > about OSGI packaging and distribution. > > Obviously, this idea is based on the features (see file : > org.apache.servicemix.features.cfg) available under SMX4. > > idea : create a maven archetype with the following goal to : > > - Create features file : will create a src folder with an empty feature.xml > file. By adding in the pom.xml file the module names of the osgi projects,(Continue reading)
THis log snippet is related to sending the response, but the problem comes from the SAX parse excpetion: The prefix "xsi" for attribute "xsi:nil" associated with an element type "identity" is not bound. which happens to be exact if you look at the second web service request. Could you paste the log which shows the JBI exchange sent by Ode to servicemix-http for that request ? Also, have you tried using the new servicemix-http endpoints or a CXF-BC consumer ? 2009/2/27 MrNinni <mmurtas@...>: > > yes, of course. thankyou. > I use TCPMon for read the soap messages. > > this is the request from the client: > > POST /SiTraAuthentication/services/Authentication HTTP/1.1 > Content-Type: text/xml;charset=UTF-8 > Content-Length: 372 > SOAPAction: "" > User-Agent: Jakarta Commons-HttpClient/3.0 > Host: 127.0.0.1:8087 > > <?xml version='1.0' encoding='UTF-8'?> > <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> > <env:Body> > <authenticate > xmlns="http://webservices.authentication.sitra.sardegnait.it"> > <username>USERNAME</username>(Continue reading)
The full ServiceMix log:
DEBUG - ConsumerProcessor - Receiving HTTP request: POST
/examples/ HTTP/1.1
Host: localhost:8192
Content-Type: text/xml; charset=utf-8
Content-Length: 383
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: IBM Web Services Explorer
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Connection: close
DEBUG - HttpComponent - Created correlation id:
ID:172.30.253.78-11fc6303bba-11:0
DEBUG - DeliveryChannelImpl - Send
ID:172.30.253.78-11fc6303bba-11:0 in DeliveryChannel{servicemix-http}
DEBUG - SecuredBroker - send exchange with secure broker
DEBUG - SecuredBroker - service name
:{http://sardegnait.it/AA}AAService
DEBUG - SecuredBroker - operation name
:{http://www.springframework.org/schema/beans}AA
DEBUG - SedaFlow - Called Flow send
DEBUG - ConsumerProcessor - Suspending continuation for
exchange: ID:172.30.253.78-11fc6303bba-11:0
DEBUG - jetty - continuation
RetryContinuation <at> 15161873,pending
(Continue reading)
Thanks. So the JBI exchange sent by Ode actually contains the xsi
namesapce declaration so it sounds like a bug in servicemix-http.
Could you try with the new http endpoints instead ?
See http://servicemix.apache.org/servicemix-http-new-endpoints.html
Try using a <http:soap-provider ... useJbiWrapper="false">
On Mon, Mar 2, 2009 at 09:11, MrNinni <mmurtas-7oAJUQ9IzsUVo99As/2U6w <at> public.gmane.org> wrote:
>
> The full ServiceMix log:
>
> DEBUG - ConsumerProcessor - Receiving HTTP request: POST
> /examples/ HTTP/1.1
> Host: localhost:8192
> Content-Type: text/xml; charset=utf-8
> Content-Length: 383
> Accept: application/soap+xml, application/dime, multipart/related, text/*
> User-Agent: IBM Web Services Explorer
> Cache-Control: no-cache
> Pragma: no-cache
> SOAPAction: ""
> Connection: close
>
>
> DEBUG - HttpComponent - Created correlation id:
> ID:172.30.253.78-11fc6303bba-11:0
> DEBUG - DeliveryChannelImpl - Send
> ID:172.30.253.78-11fc6303bba-11:0 in DeliveryChannel{servicemix-http}
> DEBUG - SecuredBroker - send exchange with secure broker
> DEBUG - SecuredBroker - service name
> :{http://sardegnait.it/AA}AAService
(Continue reading)
Hi, Thank you for your reply, it seems to be a commons-dbcp problem when used with Oracle, see here: https://issues.apache.org/jira/browse/DBCP-279 BTW i've tried to download a snapshot build from dbcp build system, but it's not working, the last thing to try is to get a newer version of oracle driver ( now i'm using ojdbc14.jar ), and i'll give a try to ojdbc5. Jean-Baptiste Onofré ha scritto: > Hi, > > Your JDBC URL seems correct. > > Try to don't use the XADataSource property, use directly the driverClassName property in place like this : > > <property name="driverClassName" value="oracle.jdbc.xa.client.OracleXADataSource"/> > > As the issue looks like around the JDBC URL, I think it will not help. > > Could you send the complete log stack trace ? > > Thanks > Regards > > On Friday 27 February 2009 - 13:51, Andrea Zoppello wrote: >(Continue reading)
Hi,
I've developed a custom servicemix-bean component that initialize a jbpm
engine.
The engine use hibernate and i want to configure the hibernate.cf.xml
file to be able to use JTA Transactions.
The hibernate.cfg.xml file looks like:
<hibernate-configuration>
<session-factory>
<!-- hibernate dialect -->
<property
name="hibernate.dialect">org.hibernate.dialect.MySQLInnoDBDialect</property>
<property
name="hibernate.connection.datasource">java:comp/env/jdbc/jbpm</property>
<property
name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.GeronimoTransactionManagerLookup</property>
<property
name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
<property name="hibernate.query.substitutions">true 1, false
0</property>
<property
name="jta.UserTransaction">java:comp/UserTransaction</property>
.....
(Continue reading)
ok thank you very much. gnodet wrote: > > Thanks. So the JBI exchange sent by Ode actually contains the xsi > namesapce declaration so it sounds like a bug in servicemix-http. > Could you try with the new http endpoints instead ? > See http://servicemix.apache.org/servicemix-http-new-endpoints.html > Try using a <http:soap-provider ... useJbiWrapper="false"> > > On Mon, Mar 2, 2009 at 09:11, MrNinni <mmurtas-7oAJUQ9IzsUVo99As/2U6w <at> public.gmane.org> wrote: >> >> The full ServiceMix log: >> >> DEBUG - ConsumerProcessor - Receiving HTTP request: POST >> /examples/ HTTP/1.1 >> Host: localhost:8192 >> Content-Type: text/xml; charset=utf-8 >> Content-Length: 383 >> Accept: application/soap+xml, application/dime, multipart/related, text/* >> User-Agent: IBM Web Services Explorer >> Cache-Control: no-cache >> Pragma: no-cache >> SOAPAction: "" >> Connection: close(Continue reading)
gnodet wrote: > > 2009/2/27 cmoulliard <cmoulliard@...>: >> >> Hi, >> >> I work very hard since a couple of days on SMX4 (kernel, fuse, ... >> versions) >> and I'm terribly frustrated about the difficulty to package a application >> (bnd, pax construct, ...) top of an OSGI server when we have by example >> non >> osgi bundles like iText, JasperReport, Hibernate, ... combined with our >> osgi >> bundles. >> >> In a development team, the work and workload is distributed between >> different team and developers. In consequence, the packaging of such >> application where we don't EAR, WAR tools is a critical factor that the >> project manager will put in the 'balance' before to take the decision to >> use >> such technology. Moreover, imagine How you will explain to deployer team >> of >> big companies (with poor or insufficient knowledge in java, maven, ant, >> ... >> except maybe if you ask them to copy a file from a folder to another, >> ...) >> how they will deploy your osgi projects in acceptance and next production >> environment >>(Continue reading)
RSS Feed112 | |
|---|---|
74 | |
50 | |
80 | |
65 | |
41 | |
52 | |
57 | |
29 | |
142 | |
123 | |
68 | |
146 | |
88 | |
95 | |
133 | |
140 | |
81 | |
93 | |
177 | |
221 | |
290 | |
250 | |
190 | |
55 | |
150 | |
184 | |
129 | |
133 | |
90 | |
109 | |
171 | |
211 | |
212 | |
143 | |
248 | |
258 | |
337 | |
407 | |
230 | |
294 | |
187 | |
342 | |
299 | |
455 | |
319 | |
414 | |
480 | |
313 | |
334 | |
597 | |
344 | |
499 | |
518 | |
514 | |
485 | |
574 | |
620 | |
669 | |
455 | |
600 | |
692 | |
601 | |
517 | |
613 | |
384 | |
335 | |
547 | |
324 | |
391 | |
588 | |
544 | |
487 | |
378 | |
704 | |
493 | |
602 | |
509 | |
585 | |
875 | |
643 | |
733 | |
499 | |
561 | |
684 | |
516 | |
249 | |
44 | |
189 | |
176 | |
275 | |
138 | |
189 | |
135 |
