[jira] [Commented] (CAMEL-15727) Simplify camel-cdi dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472016#comment-17472016 ] Romain Manni-Bucau commented on CAMEL-15727: here you are https://github.com/apache/camel/pull/6705 > Simplify camel-cdi dependencies > --- > > Key: CAMEL-15727 > URL: https://issues.apache.org/jira/browse/CAMEL-15727 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > seems mock and main dependencies should be dropped in favor of > camel-core-languages (and camel-core-engine but it is transitive from > language one). Other ones can be added in a camel-cdi-main module or so but > are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472015#comment-17472015 ] Romain Manni-Bucau commented on CAMEL-15724: FYI [https://github.com/apache/camel/pull/6705] but reviewing the usage I think camel-jta and camel-cdi don't need to be linked together at all, it looks just a DSL thing and it is not in CDI scope in general (actually it is misleading since in a lot of cases you don't want this but a resource local kind of txmgr which is not provided by this integration directly) so maybe something to plan to drop/deprecate?. > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.15.0 > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-15727) Simplify camel-cdi dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471829#comment-17471829 ] Romain Manni-Bucau commented on CAMEL-15727: [~davsclaus] looks like this can be replaced by a CDI extension and using a bit of reflection we can keep the integration fully functional without requiring mock module to be there (will avoid to have as much modules as #components!), no? If you care about quarkus, same can be done in camel-quarkus at build time. > Simplify camel-cdi dependencies > --- > > Key: CAMEL-15727 > URL: https://issues.apache.org/jira/browse/CAMEL-15727 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > seems mock and main dependencies should be dropped in favor of > camel-core-languages (and camel-core-engine but it is transitive from > language one). Other ones can be added in a camel-cdi-main module or so but > are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471787#comment-17471787 ] Romain Manni-Bucau commented on CAMEL-15724: Why is it closed as "wont fix"? It is an issue to use camel-cdi or was there a mitigation fix I missed in between? > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-15724) Decouple camel-cdi from JTA
[ https://issues.apache.org/jira/browse/CAMEL-15724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254451#comment-17254451 ] Romain Manni-Bucau commented on CAMEL-15724: Hi [~zhfeng], not really, it just moved part of it but camel-cdi still depends on JTA which is the issue of this module. With CDI this dependency is not needed at all since when importing JTA module you can override/add/enrich CDI module beans. So to solve that ticket [https://github.com/apache/camel/blob/master/components/camel-cdi/pom.xml#L120] must be removed (as well as all javax.transaction imports). > Decouple camel-cdi from JTA > --- > > Key: CAMEL-15724 > URL: https://issues.apache.org/jira/browse/CAMEL-15724 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > JTA is fully optional and when undesired it makes camel-cdi module unusable. > Would be great to keep camel-cdi only depending on CDI and have a jta > integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-11731) Servlet Component isn't really async
[
https://issues.apache.org/jira/browse/CAMEL-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17233469#comment-17233469
]
Romain Manni-Bucau commented on CAMEL-11731:
[~davsclaus] sure: https://github.com/apache/camel/pull/4617
> Servlet Component isn't really async
>
>
> Key: CAMEL-11731
> URL: https://issues.apache.org/jira/browse/CAMEL-11731
> Project: Camel
> Issue Type: Improvement
> Components: camel-servlet
>Affects Versions: 2.18.4, 2.19.2
> Environment: All
>Reporter: Nick Houghton
>Priority: Major
> Fix For: Future
>
>
> So my assumption reading the servlet component doco is that with 2.18+ and a
> Servlet 3+ container, the component supports async, which it kind of does
> with the async=true init config, and there is even a method in CamelServlet
> called "doServiceAsync" but from what i can tell it doesn't really do it in a
> asynchronous manner, where there are no blocked threads while a request is
> awaiting an async operation (like an AHC call for example).
> Looking at:
> https://github.com/apache/camel/blob/master/components/camel-http-common/src/main/java/org/apache/camel/http/common/CamelServlet.java
> While processing a request, we check if we are in async mode and call
> doServiceAsync..
> {code:java}
> @Override
> protected final void service(HttpServletRequest req, HttpServletResponse
> resp) throws ServletException, IOException {
> if (isAsync()) {
> final AsyncContext context = req.startAsync();
> //run async
> context.start(() -> doServiceAsync(context));
> } else {
> doService(req, resp);
> }
> }
> {code}
> then in doServiceAsync() we call doService().. and then we call
> getProcessor().process(exchange), not process(exchange, asyncCallback) which
> is the proper async method..
> {code:java}
> try {
> if (log.isTraceEnabled()) {
> log.trace("Processing request for exchangeId: {}",
> exchange.getExchangeId());
> }
> // process the exchange
> consumer.getProcessor().process(exchange);
> } catch (Exception e) {
> exchange.setException(e);
> }
> {code}
> So the actual behaviour is an inbound request in async mode that ends up just
> blocking waiting for the request to complete, in a totally sync manner. I
> presume this is not the desired behaviour?
> It seems the fix would be to move the doService() logic to doServiceAsync()
> and have doService() call it and use the AsyncProcessorConverterHelper. Or
> the other alternative would be to update the documentation to explicitly note
> that it is actually not async at all.
> I can probably PR it in, just wanted to get thoughts on the actual intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-11731) Servlet Component isn't really async
[
https://issues.apache.org/jira/browse/CAMEL-11731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231376#comment-17231376
]
Romain Manni-Bucau commented on CAMEL-11731:
Any way it moves forward? Currently i'm using something like
[https://gist.github.com/rmannibucau/3dc9f98ca444732e894fdb4e8251a9e2]
Only changes are to use the async processor instead of sync processor for the
consumer (can be an instanceof check to keep it generic) and moving the
asyncContext.complete() after the processing.
Side note: fully unrelated but saw it while working on that: OPTIONS
allowedMethods logic tests null instead of isEmpty()/isBlank(), guess it is a
bug introduce by moving to streams.
> Servlet Component isn't really async
>
>
> Key: CAMEL-11731
> URL: https://issues.apache.org/jira/browse/CAMEL-11731
> Project: Camel
> Issue Type: Improvement
> Components: camel-servlet
>Affects Versions: 2.18.4, 2.19.2
> Environment: All
>Reporter: Nick Houghton
>Priority: Major
> Fix For: Future
>
>
> So my assumption reading the servlet component doco is that with 2.18+ and a
> Servlet 3+ container, the component supports async, which it kind of does
> with the async=true init config, and there is even a method in CamelServlet
> called "doServiceAsync" but from what i can tell it doesn't really do it in a
> asynchronous manner, where there are no blocked threads while a request is
> awaiting an async operation (like an AHC call for example).
> Looking at:
> https://github.com/apache/camel/blob/master/components/camel-http-common/src/main/java/org/apache/camel/http/common/CamelServlet.java
> While processing a request, we check if we are in async mode and call
> doServiceAsync..
> {code:java}
> @Override
> protected final void service(HttpServletRequest req, HttpServletResponse
> resp) throws ServletException, IOException {
> if (isAsync()) {
> final AsyncContext context = req.startAsync();
> //run async
> context.start(() -> doServiceAsync(context));
> } else {
> doService(req, resp);
> }
> }
> {code}
> then in doServiceAsync() we call doService().. and then we call
> getProcessor().process(exchange), not process(exchange, asyncCallback) which
> is the proper async method..
> {code:java}
> try {
> if (log.isTraceEnabled()) {
> log.trace("Processing request for exchangeId: {}",
> exchange.getExchangeId());
> }
> // process the exchange
> consumer.getProcessor().process(exchange);
> } catch (Exception e) {
> exchange.setException(e);
> }
> {code}
> So the actual behaviour is an inbound request in async mode that ends up just
> blocking waiting for the request to complete, in a totally sync manner. I
> presume this is not the desired behaviour?
> It seems the fix would be to move the doService() logic to doServiceAsync()
> and have doService() call it and use the AsyncProcessorConverterHelper. Or
> the other alternative would be to update the documentation to explicitly note
> that it is actually not async at all.
> I can probably PR it in, just wanted to get thoughts on the actual intention.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-15838) Support microprofile openapi
Romain Manni-Bucau created CAMEL-15838: -- Summary: Support microprofile openapi Key: CAMEL-15838 URL: https://issues.apache.org/jira/browse/CAMEL-15838 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau Goal is to use microprofile openapi (therefore + jsonb) instead of io.apicurio.datamodels and jackson. This enables MP applications using camel to not rely on undesired 3rd party libraries. MP OpenAPI provides a factory for its component (model) so this can be portable. Code is likely more or less the same than the existing one but with a fully different stack. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
[ https://issues.apache.org/jira/browse/CAMEL-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225937#comment-17225937 ] Romain Manni-Bucau commented on CAMEL-15725: Here it is [https://github.com/apache/camel/pull/4562] > Make camel-cdi OSGi CDI friendly > > > Key: CAMEL-15725 > URL: https://issues.apache.org/jira/browse/CAMEL-15725 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
[ https://issues.apache.org/jira/browse/CAMEL-15725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225252#comment-17225252 ] Romain Manni-Bucau commented on CAMEL-15725: [~davsclaus] sorry i don't get it, it is just about fixing the manifest.mf and CDI is support in karaf thanks OSGi-CDI spec (aries cdi as impl @asf) so the jar should be fixed IMHO. > Make camel-cdi OSGi CDI friendly > > > Key: CAMEL-15725 > URL: https://issues.apache.org/jira/browse/CAMEL-15725 > Project: Camel > Issue Type: Task > Components: camel-cdi >Reporter: Romain Manni-Bucau >Priority: Minor > Fix For: 3.x > > > Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15780) Make camel-openapi-java use Jsonb instead of Jackson
Romain Manni-Bucau created CAMEL-15780: -- Summary: Make camel-openapi-java use Jsonb instead of Jackson Key: CAMEL-15780 URL: https://issues.apache.org/jira/browse/CAMEL-15780 Project: Camel Issue Type: Task Components: rest Affects Versions: 3.6.0 Reporter: Romain Manni-Bucau Goal are: # Ensure user can rely on its JSON-Java mapper implementation # Reduce the size of the dependency tree for that concern (openapi generation) but still use camel integration with the rest DSL If it helps we can extract the model from [https://github.com/apache/geronimo-openapi/tree/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/impl/model] in its own jar -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15728) [cdi] @ContextName does not exist anymore
Romain Manni-Bucau created CAMEL-15728: -- Summary: [cdi] @ContextName does not exist anymore Key: CAMEL-15728 URL: https://issues.apache.org/jira/browse/CAMEL-15728 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau Its mention should probably be dropped from org.apache.camel.cdi.CdiCamelContext javadoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15727) Simplify camel-cdi dependencies
Romain Manni-Bucau created CAMEL-15727: -- Summary: Simplify camel-cdi dependencies Key: CAMEL-15727 URL: https://issues.apache.org/jira/browse/CAMEL-15727 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau seems mock and main dependencies should be dropped in favor of camel-core-languages (and camel-core-engine but it is transitive from language one). Other ones can be added in a camel-cdi-main module or so but are undesired for main deployments IMHO. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15725) Make camel-cdi OSGi CDI friendly
Romain Manni-Bucau created CAMEL-15725: -- Summary: Make camel-cdi OSGi CDI friendly Key: CAMEL-15725 URL: https://issues.apache.org/jira/browse/CAMEL-15725 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau Needs to exposes the cdi extension in capabilities mainly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15724) Decouple camel-cdi from JTA
Romain Manni-Bucau created CAMEL-15724: -- Summary: Decouple camel-cdi from JTA Key: CAMEL-15724 URL: https://issues.apache.org/jira/browse/CAMEL-15724 Project: Camel Issue Type: Task Reporter: Romain Manni-Bucau JTA is fully optional and when undesired it makes camel-cdi module unusable. Would be great to keep camel-cdi only depending on CDI and have a jta integration either in a new module or in a jta module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15692) Add JSON-B dataformat support
Romain Manni-Bucau created CAMEL-15692: -- Summary: Add JSON-B dataformat support Key: CAMEL-15692 URL: https://issues.apache.org/jira/browse/CAMEL-15692 Project: Camel Issue Type: New Feature Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15691) Johnzon DataFormat doc references Jackson instead of Johnzon
Romain Manni-Bucau created CAMEL-15691: -- Summary: Johnzon DataFormat doc references Jackson instead of Johnzon Key: CAMEL-15691 URL: https://issues.apache.org/jira/browse/CAMEL-15691 Project: Camel Issue Type: Bug Affects Versions: 3.5.0 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-12954) Add a camel-websocket component 100% using only JSR356
Romain Manni-Bucau created CAMEL-12954: -- Summary: Add a camel-websocket component 100% using only JSR356 Key: CAMEL-12954 URL: https://issues.apache.org/jira/browse/CAMEL-12954 Project: Camel Issue Type: New Feature Reporter: Romain Manni-Bucau Goal is to rely on the standard javax specification and not require to setup Atmosphere in containers which now support it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-4015) camel-hazelcast - Allow to specify operation in uri instead of just as a header
[ https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13791240#comment-13791240 ] Romain Manni-Bucau commented on CAMEL-4015: --- @James: it works for me. Note for the operation and other configs (even the Id!) i proposed to set them optionally as query param instead of inlined. The id is to follow the format location?config. camel-hazelcast - Allow to specify operation in uri instead of just as a header --- Key: CAMEL-4015 URL: https://issues.apache.org/jira/browse/CAMEL-4015 Project: Camel Issue Type: Improvement Components: camel-hazelcast Reporter: Romain Manni-Bucau Assignee: James Carman Priority: Minor Fix For: 2.13.0 It could be nice to be able to specify type operation (and maybe the key for map) in the uri instead of headers: from(hazelcast:map:foo?operation=getid=myStringId).to(log:display); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CAMEL-4015) camel hazelcast uri format
[ https://issues.apache.org/jira/browse/CAMEL-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780889#comment-13780889 ] Romain Manni-Bucau commented on CAMEL-4015: --- Yes the patch matches the need. Thks camel hazelcast uri format -- Key: CAMEL-4015 URL: https://issues.apache.org/jira/browse/CAMEL-4015 Project: Camel Issue Type: Improvement Components: camel-hazelcast Reporter: Romain Manni-Bucau Priority: Trivial Attachments: CAMEL-4015.patch It could be nice to be able to specify type operation (and maybe the key for map) in the uri instead of headers: from(hazelcast:map:foo?operation=getid=myStringId).to(log:display); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6337) camel-cdi dependencies are wrong for most cases
[ https://issues.apache.org/jira/browse/CAMEL-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CAMEL-6337: -- Attachment: camel-6447.patch Adding provided scope for API jars. Note: jaxb-impl comes from parent pom. Same note: i think it should be scoped provided in camel parent pom but i let you judging it regading all components (not directly linked to this particular issue). camel-cdi dependencies are wrong for most cases --- Key: CAMEL-6337 URL: https://issues.apache.org/jira/browse/CAMEL-6337 Project: Camel Issue Type: Improvement Components: camel-cdi Affects Versions: 2.11.0 Reporter: Romain Manni-Bucau Priority: Minor Fix For: Future Attachments: camel-6447.patch Hi, because of its main camel-cdi import: exclusions !-- provided by the container -- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-atinject_1.0_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jcdi_1.0_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-interceptor_1.1_spec/artifactId /exclusion exclusion groupIdcom.sun.xml.bind/groupId artifactIdjaxb-impl/artifactId /exclusion /exclusions It is wrong since all containers (embedded or not) will provide it. The only case where it is relevant is the main and IMO it is better to use scope provided and ask for inclusion when needed (main). The main case shouldn't drive any dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6356) link to camel registry in camel-stax is missing
Romain Manni-Bucau created CAMEL-6356: - Summary: link to camel registry in camel-stax is missing Key: CAMEL-6356 URL: https://issues.apache.org/jira/browse/CAMEL-6356 Project: Camel Issue Type: Bug Affects Versions: 2.11.0 Reporter: Romain Manni-Bucau -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6337) camel-cdi dependencies are wrong for most cases
Romain Manni-Bucau created CAMEL-6337: - Summary: camel-cdi dependencies are wrong for most cases Key: CAMEL-6337 URL: https://issues.apache.org/jira/browse/CAMEL-6337 Project: Camel Issue Type: Bug Affects Versions: 2.11.0 Reporter: Romain Manni-Bucau Hi, because of its main camel-cdi import: exclusions !-- provided by the container -- exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-atinject_1.0_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jcdi_1.0_spec/artifactId /exclusion exclusion groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-interceptor_1.1_spec/artifactId /exclusion exclusion groupIdcom.sun.xml.bind/groupId artifactIdjaxb-impl/artifactId /exclusion /exclusions It is wrong since all containers (embedded or not) will provide it. The only case where it is relevant is the main and IMO it is better to use scope provided and ask for inclusion when needed (main). The main case shouldn't drive any dependency. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6338) camel-cdi shouldn't use deltapsike bean manager provider in the CamelExtension
Romain Manni-Bucau created CAMEL-6338: - Summary: camel-cdi shouldn't use deltapsike bean manager provider in the CamelExtension Key: CAMEL-6338 URL: https://issues.apache.org/jira/browse/CAMEL-6338 Project: Camel Issue Type: Bug Reporter: Romain Manni-Bucau In an cdi extension the bean manager is injected so camel cdi shouldn't use deltaspike for it. A nice side effect of it will be it will remove WARNING The only trick it will need will be to give org.apache.camel.cdi.CdiBeanRegistry the bean manager to use. A thread local or delegate (registry.getDelegate()) falling back to DS if null should be fine. It just needs to be resetted after extension startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5566) provide an annotation to auto-register a RouteBuilder with a CamelContext (lazily creating a new CamelContext if a different contextName is specified)
[ https://issues.apache.org/jira/browse/CAMEL-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13598362#comment-13598362 ] Romain Manni-Bucau commented on CAMEL-5566: --- Thought it was handled through @ContextName provide an annotation to auto-register a RouteBuilder with a CamelContext (lazily creating a new CamelContext if a different contextName is specified) -- Key: CAMEL-5566 URL: https://issues.apache.org/jira/browse/CAMEL-5566 Project: Camel Issue Type: Improvement Components: camel-cdi Reporter: james strachan Assignee: james strachan Fix For: 2.11.0 Attachments: CAMEL-5566.patch as per Romain's ideas on the dev list, it would be nice to have an annotation to make it easy to inject a RouteBuilder instance then bind it to a CamelContext (basically creating the CamelContext for the given context name and calling CamelContext.addRoutes(routes)). Previously Romain had gone with @CamelContextId though am thinking, @Named is the way of associating an id/name with a bean and its really more about camel lifecycles, so thinking of using @CamelStartup to make it more obvious what it does (with the contextName being an optional parameter too; since multiple contexts within the same class loader are kinda rare - there's no huge need for more than one CamelContext). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5700) enhance camel-cdi to support annotatedtypes
[ https://issues.apache.org/jira/browse/CAMEL-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13479930#comment-13479930 ] Romain Manni-Bucau commented on CAMEL-5700: --- well the last patch was the one to use the annotated type part can be skipped i think since processbean is used. i thought Charles commited what was needed (in particular other parts for OSGi) @Charles: can you confirm it? if yes i think we can close enhance camel-cdi to support annotatedtypes --- Key: CAMEL-5700 URL: https://issues.apache.org/jira/browse/CAMEL-5700 Project: Camel Issue Type: Wish Components: camel-cdi Affects Versions: 2.11.0 Reporter: Romain Manni-Bucau Fix For: 2.11.0 Attachments: camel-cdi.patch, camel-cdi.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5700) enhance camel-cdi to support annotatedtypes
Romain Manni-Bucau created CAMEL-5700: - Summary: enhance camel-cdi to support annotatedtypes Key: CAMEL-5700 URL: https://issues.apache.org/jira/browse/CAMEL-5700 Project: Camel Issue Type: Wish Reporter: Romain Manni-Bucau Attachments: camel-cdi.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5700) enhance camel-cdi to support annotatedtypes
[ https://issues.apache.org/jira/browse/CAMEL-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated CAMEL-5700: -- Attachment: camel-cdi.patch enhance camel-cdi to support annotatedtypes --- Key: CAMEL-5700 URL: https://issues.apache.org/jira/browse/CAMEL-5700 Project: Camel Issue Type: Wish Reporter: Romain Manni-Bucau Attachments: camel-cdi.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4935) camel-openejb component to deploy/undeploy an app from a route
[ https://issues.apache.org/jira/browse/CAMEL-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407967#comment-13407967 ] Romain Manni-Bucau commented on CAMEL-4935: --- hmm, Claus your answer is not consistent with the component, it is not an EJB component, it is a deployment/undeployement integration. not link with EJBs camel-openejb component to deploy/undeploy an app from a route -- Key: CAMEL-4935 URL: https://issues.apache.org/jira/browse/CAMEL-4935 Project: Camel Issue Type: New Feature Reporter: Romain Manni-Bucau Assignee: Claus Ibsen Priority: Minor Attachments: CAMEL-4935.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
