Re: camel-bean-validator and hibernate-validator for OSGi
Thanks for your reply Christian. However, the JAR you refer to isn't an OSGi bundle either. In fact I think its the publicly released jar from JBoss which I had problems with. I tried to use the OSGi wrapped version they use in Glassfish: http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar But it turns out it requires the packages org.glassfish.api.naming.* that I assume only exist in Glassfish. Related to the above, one also needs an OSGi bundle for the API: javax.validation. Glassfish wraps it in the same jar I mentioned above. From where does Camel take it? I don't quite understand how Camel can use the non-OSGi:fied version of hibernate-validator. Have you tried this deployed in an OSGi container? /Bengt 2010/9/11 Christian Müller christian.muel...@gmail.com Hello Bengt, we use the following on [1]. I think we could also update to 4.1.0. I opened a JIRA for it [2]. Hope this helps, Christian [1] http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar [2] https://issues.apache.org/activemq/browse/CAMEL-3115 On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav be...@rodehav.com wrote: I''m experimenting with the Java Bean Validation API (JSR 303). I'm not currently doing it with Camel but thought I might ask for help here anyway. I'm deploying in an OSGi context and need OSGi bundles for both the API (java.validation) and Hibernate's reference implementation (preferably the latest version which I believe is 4.1). I haven't been able to find one. The only one I've found is bundled for Glassfish but has dependencies on Glassfish specific classes and therefore doesn't work outside Glassfish. Since Camel 2.4 contains the camel-bean-validator component I'm wondering if anyone can tell me how this problem was solved in Camel. /Bengt
Re: camel-bean-validator and hibernate-validator for OSGi
Hello Bengt! Sorry, I overlooked it. Apache Servicemix provides the OSGI-fied version for us. You can find the released version 4.0.2 here [1] [1] http://repo2.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.hibernate-validator/4.0.2.GA_2/ Cheers, Christian On Sat, Sep 11, 2010 at 10:23 AM, Bengt Rodehav be...@rodehav.com wrote: Thanks for your reply Christian. However, the JAR you refer to isn't an OSGi bundle either. In fact I think its the publicly released jar from JBoss which I had problems with. I tried to use the OSGi wrapped version they use in Glassfish: http://download.java.net/maven/2/org/glassfish/bean-validator/3.0-JBoss-4.0.2/bean-validator-3.0-JBoss-4.0.2.jar But it turns out it requires the packages org.glassfish.api.naming.* that I assume only exist in Glassfish. Related to the above, one also needs an OSGi bundle for the API: javax.validation. Glassfish wraps it in the same jar I mentioned above. From where does Camel take it? I don't quite understand how Camel can use the non-OSGi:fied version of hibernate-validator. Have you tried this deployed in an OSGi container? /Bengt 2010/9/11 Christian Müller christian.muel...@gmail.com Hello Bengt, we use the following on [1]. I think we could also update to 4.1.0. I opened a JIRA for it [2]. Hope this helps, Christian [1] http://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-validator/4.0.2.GA/hibernate-validator-4.0.2.GA.jar [2] https://issues.apache.org/activemq/browse/CAMEL-3115 On Sat, Sep 11, 2010 at 1:07 AM, Bengt Rodehav be...@rodehav.com wrote: I''m experimenting with the Java Bean Validation API (JSR 303). I'm not currently doing it with Camel but thought I might ask for help here anyway. I'm deploying in an OSGi context and need OSGi bundles for both the API (java.validation) and Hibernate's reference implementation (preferably the latest version which I believe is 4.1). I haven't been able to find one. The only one I've found is bundled for Glassfish but has dependencies on Glassfish specific classes and therefore doesn't work outside Glassfish. Since Camel 2.4 contains the camel-bean-validator component I'm wondering if anyone can tell me how this problem was solved in Camel. /Bengt
Camel Exchange Patters
Hello list!
I read Claus, Jonathan and Hadrians book Camel in Action and I studied the
Camel site [1]. I also hat a short conversation with Ade from Progress about
the exchange pattern, but still I have the feeling I doesn't understand all
aspects. May be you can help me to understand it correct. Here are my
questions:
- In the book and the Camel site only the exchange patterns InOut and InOnly
are mentioned but org.apache.camel.ExchangePattern defines the following
exchange patterns: InOnly, RobustInOnly, InOut, InOptionalOut, OutOnly,
RobustOutOnly, OutIn, OutOptionalIn. Should we only use InOut and InOnly?
- If I understood Ade correct, after each processing on a
component/processor the message goes throught the pipieline before it
receives the next component/processor. In the case of an InOut exchange, the
pipeline will copy the out message body, headers and attachments into the in
message. So that in the next component/processor can access these data from
the in message again. If I use the InOnly exchange pattern, the
component/processor will write the response into the in message and the
pipeline has nothing to copy. From the end user perspective it looks like it
doesn't matter, whether to use the InOnly or InOut exchange pattern.
- The only one component I know which handle InOnly and InOut really
defferently is the jms-component. It will only send a reply message if the
exchange pattern InOut is used.
- If I use a InOnly exchange for the following routes, I takes also more
than 5 seconds until my templeate.send() method returns. I would expect that
the call returns after the exchange was placed into the next sub route
(after a few milliseconds). My key point here is not to improve the
performance. Only to understand the exchange pattern correct, how the work
and how they are used in the right way...
from(direct:start)
.to(direct:sub);
from(direct:sub)
.process(*new* Processor() {
@Override
*public* *void* process(Exchange exchange) *
throws* Exception {
Thread.*sleep*(5000);
}
})
.to(mock:result);
- Do you have recommendations when to use InOnly and InOut?
- If we write our own processor which modifies the in message, should they
write the modified body into the out message, if the exchnage is out capable
(and also copy all header and attachments we need for further processing)?
Or should we always modify the in message because it requires less action?
- The same question for our own type converters. I know the type converter
is implemented in this way, that it will return the new (converted) object.
But our type converters also have to modify the message header. Should they
also check whether the exchange is out capable and than modify the out (if
out capable) or in (if not out capable) message? Is this the way camel
handels the converted object from the type converter?
[1] http://camel.apache.org/exchange-pattern.html
Thanks in advance for your help and taking time for my questions,
Christian
Re: CXFRS consumers - is there a better way?
Hi Willem, Just a FYI, I've resolved this issue and provided a patch on the JIRA issue. Let me know if you think it warrants a test case as I found it pretty trivial to implement. Kind regards, Christopher -- View this message in context: http://camel.465427.n5.nabble.com/CXFRS-consumers-is-there-a-better-way-tp2834502p2836101.html Sent from the Camel - Users mailing list archive at Nabble.com.
