Re: Unable to reach Nabble site
Since years, the nabble site was just a backup of the apache mailing lists. They are still available from https://lists.apache.org/list.html?users@camel.apache.org and https://lists.apache.org/list.html?d...@camel.apache.org as indicated in https://camel.apache.org/community/mailing-list/ ... Le mar. 31 août 2021 à 17:40, John F. Berry a écrit : > Thanks, Andrea, for the heads up. > > I had the same question.. It's a pity, it was a great place as a > "source".If it is defunct, are we left now with only strict documentation > sites, and not to see how people overcome technical struggles?Or is it we > are waiting out some technical work to restore the service? > > On Tuesday, August 31, 2021, 11:15:37 AM EDT, Andrea Cosentino < > anco...@gmail.com> wrote: > > It's not working anymore. Do not consider it as source > > Il mar 31 ago 2021, 17:09 Wilken Marci J > ha scritto: > > > Morning everyone, > > Is something up with the nabble site or has it been moved? > > camel.465427.n5.nabble.com. get me "This site can't be reached" > > > > Regards- > > Marci Wilken > > > -- Guillaume Nodet
Re: Simple language in 3.1.0
The syntax without placeholders had been deprecated in the 2.x branch since
a long time.
You now need to use simple('${headers.entityMap.sourceTableName}')
Le jeu. 23 avr. 2020 à 15:42, Remco Schoen a écrit :
> Hi,
>
> I have a question about the Simple language and the use of ${}.
>
> Before Camel 3 this worked in getting data from the object in the header:
> .setHeader('tableName').simple('headers.entityMap.sourceTableName’)
> .setHeader('fields').simple('headers.entityMap.sourceFields')
>
> In Camel 3.1.0 this no longer works and I get the string in my new headers.
>
> In the migration documentation I don’t see anything about a change here
> and according the documentation this still seems to be supported.
>
> https://camel.apache.org/components/latest/languages/simple-language.html
>
> “The simple language uses ${body} placeholders for complex expressions
> where the expression contains constant literals. The $\{ } placeholders can
> be omitted if the expression is only the token itself.”
>
> Should this still work in Camel 3?
>
> Kind regards,
>
> Remco Schoen
>
> P.S. I haven’t had time yet to research the upgrade to Camel 3.2.0, sorry.
>
--
Guillaume Nodet
Re: Camel Endpoint DSL
Le jeu. 23 avr. 2020 à 10:06, Mikael Andersson Wigander <
mikael.grevs...@gmail.com> a écrit :
> Hi
>
> How can I combine the endpoint DSL with dynamic property definitions such
> as:
>
You can use property placeholders with the endpoint DSL, but the goal of
the
dsl is to provide some type safety for properties. In order to do that,
you need to
know the endpoint type beforehand. Soin your use case where the component
is not know, you can't leverage the endpoint dsl much.
>
> final String toStr = "{{shuttle.ftp.outgoing.url}}" +
> "={{shuttle.ftp.username}}" +
> "={{shuttle.ftp.password}}" +
> "=false" +
> "=true" +
> "=true" +
> "=#defaultPollStrategy";
>
> from("{{shuttle.outgoing.transactions}}")
> .routeId("Sending-SHUTTLE-FTP")
> .autoStartup("{{shuttle.ftp.outgoing.startup}}")
> .wireTap("seda:ping")
> .to(toStr)
> .log("XML file(s) sent")
> .end();
>
>
> What I’d like is to have the option to have our DEV environment setup
> using say FTP but in INTEGRATION and PROD it will be SFTP. Since the
> endpointDSL is somewhat “hardcoding” the endpoint I don’t really know how
> to do it
>
> Thx
>
> M
--
Guillaume Nodet
Re: How to prevent the logging of patient identifiers
You can also investigate writing your own log4j / logback filter / appender
to filter out log statements that may contain sensitive information.
Le mar. 17 mars 2020 à 11:07, Claus Ibsen a écrit :
> Hi
>
> You can configure the error handler logging level, incl / excl stracktraces
> etc.
> Or you can do a custom onException and then handle the exception, and then
> do your own logging etc.
>
>
>
> On Tue, Mar 17, 2020 at 10:44 AM Paw B Sørensen
> wrote:
>
> > Hi,
> >
> >
> >
> > I am using the camel fhir component to retrieve observations for a
> > patient. As part of the request I set the URL including query params
> > identifying the patient:
> >
> >
> >
> > .setHeader(FhirConstants.PROPERTY_PREFIX + "url",
> > constant("Observation?subject:Patient=091234"))
> >
> > .toD(String.format("fhir:%s/%s",
> >
> >
> >
> FhirApiCollection.getCollection().getApiName(FhirSearchApiMethod.class).getName(),
> >
> > FhirSearchApiMethod.SEARCHBYURL.getName()) +
> >
> > "?encoding=XML" +
> >
> > "=false" +
> >
> > "=NEVER")
> >
> >
> >
> > If the request fails for example HTTP 404 Not Found because the patient
> > was unknown then the resulting RuntimeCamelException logged by the
> > RedeliveryErrorHandler includes the URL.
> >
> > This is a problem because of GDPR we cannot allow a patient identifier in
> > the log files.
> >
> > Is there any way to prevent the logging or to remove the URL before the
> > logging
> >
> >
> >
> >
> >
> > Paw B Sørensen
> >
> > paw.b.soren...@systematic.com
> >
> >
> >
> > Med venlig hilsen / Kind regards
> >
> > [image: Systematic Logo] <http://www.systematic.com/>
> > *Paw B Sørensen*
> > Systems Engineer
> >
> > Søren Frichs Vej 39, 8000 Aarhus C
> > Denmark
> >
> > Mobile: +45 2544 9834
> > paw.b.soren...@systematic.com
> > www.systematic.com
> >
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Guillaume Nodet
Re: Camel 3.1.0: error handling changed, route no longer stops
Would you mind raising a JIRA issue and attaching your test ? I'll have a look at the problem. Le lun. 9 mars 2020 à 15:48, Remco Schoen a écrit : > Hi, > > I noticed that the error handling has changed in 3.1.0 from 3.0.1. We use > a DeadLetterChannel and when the error has been handled, I expect the > original route to stop and not to continue. > > When we use enrich we pass the exchange property CamelErrorHandlerHandled > back to ensure the calling route stops, but that has changed. Is this > correct and should we change our aggregation strategy? > > I added the strategy and it’s test. > > Kind regards, > > Remco Schoen > > > > -- Guillaume Nodet
Re: Route Tracing with Camel 3.0 and BluePrint
Looks similar to
https://issues.apache.org/jira/projects/CAMEL/issues/CAMEL-14462
I need to investigate it asap.
Le mer. 5 févr. 2020 à 17:48, Alex Soto a écrit :
> This used to work with Camel 2.X, now it seems it is ignoring the
> settings
>
>
>
> class="org.apache.camel.support.processor.DefaultExchangeFormatter">
> value="#{camel.trace.showProperties}"/>
> value="#{camel.trace.showExchangePattern}"/>
> value="#{camel.trace.showExchangeId}"/>
>
>
>
>
> http://camel.apache.org/schema/blueprint;
> id="admin" trace=“true”>
>
> Specifically, when I set the showHeaders property to true the exchange
> headers are still not logged. Any idea?
>
>
> Best regards,
> Alex soto
>
>
>
>
>
--
Guillaume Nodet
Re: [DISCUSS] - Apache Camel 3 - A new tagline
> Apache Camel 3 - A full-stack integration framework for building > cloud-native micro integrations > I think the proposed tagline focuses too much on cloud, and even if that's definitely something we want to emphasize in the set of capabilities that Camel provides, having it in the tag line kinda implies that Camel is mainly focusing on cloud and not traditional integration. > "Integrate everything" > "Integrate everything without humps" ;-) > +1 I like both a lot. In the same direction, and to keep the versatile side we could have: "Integrate everything everywhere" but not sure it's better. Guillaume Le mer. 20 févr. 2019 à 08:28, Burkard Stephan a écrit : > Hi all > > +1 for "Integrate everything!" > because it is short, catchy and it refers to Camels outstanding > versatility with its hundreds of components. > > It is true that Camel has a lot of other noteworthy features like runtime > flexibility etc. but as soon as the tagline wants to cover multiple things, > it gets "bulky" or "buzzwordy". > > To link the tagline back to the project name and add a pinch of humor it > could also be > "Integrate everything without humps" ;-) > > > -Ursprüngliche Nachricht- > Von: Steve Huston > Gesendet: Dienstag, 19. Februar 2019 18:32 > An: users@camel.apache.org > Betreff: RE: [DISCUSS] - Apache Camel 3 - A new tagline > > "Integrate everything!" > > > -Original Message- > > From: Claus Ibsen > > Sent: Tuesday, February 19, 2019 10:52 AM > > To: users@camel.apache.org > > Subject: [DISCUSS] - Apache Camel 3 - A new tagline > > > > Hi > > > > As part of Apache Camel 3, we are working on a new modern website > > (yeah its long overdue, but work are in progress). > > > > As part of that, we should get a new front-page with a new short > > summary what Apache Camel is (eg a tagline). > > > > It would be good to get some ideas rolling what such a tagline could > > be and for users of Camel to come up with suggestions. > > > > As Apache Camel has been around for so long, and that it covers so > > many different use-cases, then its maybe harder to come up with a > > single tag-line that spans all use-cases. > > > > However with the new modern world of containers I came up with: > > > > * Apache Camel 3 - A full-stack integration framework for building > > cloud- native micro integrations > > > > > > > > -- > > Claus Ibsen > > - > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > -- Guillaume Nodet
Re: Blueprint, property-place-holder error name is already instanciated as null and cannot be removed
Could you please raise a JIRA with the needed information and patch ?
2018-02-23 19:03 GMT+01:00 Alex Soto <alex.s...@envieta.com>:
> Thank you Guillaume,
>
> You are correct, I tried your suggestion locally and it does work.
> I don’t know what are the potential side effects of this change though.
> Probably better that somebody more familiar with this code takes a look
> and fixes it.
>
> Best regards,
> Alex soto
>
>
> > On Feb 23, 2018, at 12:04 PM, Guillaume Nodet <gno...@apache.org> wrote:
> >
> > As I indicated on the Karaf mailing list, I suspect the problem comes
> from
> >
> > https://github.com/apache/camel/blob/master/components/
> camel-blueprint/src/main/java/org/apache/camel/blueprint/
> handler/CamelNamespaceHandler.java#L1056
> >
> > I think it should call getComponent(component, false) instead to ensure
> the
> > component is not created eagerly.
> >
> > The reason is that the exception is saying that the processor (the
> property
> > placeholder) can't process the bean because it has been already
> > instantiated. And that call could be the culprit as the OSGi camel
> context
> > may attempt to create the component.
> >
> > That could break the original intent though, in which case, we'd need to
> go
> > to the blueprint container and check if the component is available
> without
> > creating it.
> >
> > Guillaume
> >
> >
> > 2018-02-23 17:55 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com
> >:
> >
> >> That makes more sense :-)
> >>
> >> When I’ve seen this kind of stuff before, it’s usually that the
> >> initialization of bean that is a dependency of another bean fails. I
> start
> >> at the first exception I see - that usually points me to the right
> place.
> >>
> >> In this case, it’s acting like it can’t find a setter for the correct
> type
> >> - maybe that changed across Camel versions?
> >>
> >>> On Feb 23, 2018, at 6:49 AM, Alex Soto <alex.s...@envieta.com> wrote:
> >>>
> >>> The actual code is well-formed, this was just error formatting the code
> >> for the post. I’ll try again:
> >>>
> >>> http://www.osgi.org/xmlns/blueprint/v1.0.0;
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >>> xmlns:camel="http://camel.apache.org/schema/blueprint;
> >>> xmlns:cm="http://aries.apache.
> >> org/blueprint/xmlns/blueprint-cm/v1.1.0"
> >>> xmlns:ext="http://aries.apache.org/blueprint/xmlns/
> >> blueprint-ext/v1.0.0"
> >>> xsi:schemaLocation="
> >>> http://www.osgi.org/xmlns/blueprint/v1.0.0
> >>> https://www.osgi.org/xmlns/
> >> blueprint/v1.0.0/blueprint.xsd”>
> >>>
> >>> >>> update-strategy="reload”
> >>> placeholder-prefix="#{" placeholder-suffix="}">
> >>>
> >>>
> >>> >> value="600" />
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Feb 22, 2018, at 9:56 PM, Quinn Stevenson <
> >> qu...@pronoia-solutions.com> wrote:
> >>>>
> >>>> Is that really the XML? It’s not well formed - you start with a
> >> cm:property-placeholder element and end with a cm:default-properties
> >> element.
> >>>>
> >>>>> On Feb 22, 2018, at 12:48 PM, Alex Soto <alex.s...@envieta.com>
> wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I am having some problems migrating to Camel 2.20.2 from 2.17.4. I
> >> have blueprint configuration:
> >>>>>
> >>>>> >>>>>persistent-id=“audit.log”
> >>>>>update-strategy="reload”
> >>>>>placeholder-prefix="#{"
> >> placeholder-suffix="}”>
> >>>>>
> >>>>> >> />
> >>>>>
> >>>>>
> >>>>>
> >>>>> A component configuration (in this case for Quartz2, but I don’t
&
Re: Blueprint, property-place-holder error name is already instanciated as null and cannot be removed
As I indicated on the Karaf mailing list, I suspect the problem comes from
https://github.com/apache/camel/blob/master/components/camel-blueprint/src/main/java/org/apache/camel/blueprint/handler/CamelNamespaceHandler.java#L1056
I think it should call getComponent(component, false) instead to ensure the
component is not created eagerly.
The reason is that the exception is saying that the processor (the property
placeholder) can't process the bean because it has been already
instantiated. And that call could be the culprit as the OSGi camel context
may attempt to create the component.
That could break the original intent though, in which case, we'd need to go
to the blueprint container and check if the component is available without
creating it.
Guillaume
2018-02-23 17:55 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:
> That makes more sense :-)
>
> When I’ve seen this kind of stuff before, it’s usually that the
> initialization of bean that is a dependency of another bean fails. I start
> at the first exception I see - that usually points me to the right place.
>
> In this case, it’s acting like it can’t find a setter for the correct type
> - maybe that changed across Camel versions?
>
> > On Feb 23, 2018, at 6:49 AM, Alex Soto <alex.s...@envieta.com> wrote:
> >
> > The actual code is well-formed, this was just error formatting the code
> for the post. I’ll try again:
> >
> > http://www.osgi.org/xmlns/blueprint/v1.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xmlns:camel="http://camel.apache.org/schema/blueprint;
> > xmlns:cm="http://aries.apache.
> org/blueprint/xmlns/blueprint-cm/v1.1.0"
> > xmlns:ext="http://aries.apache.org/blueprint/xmlns/
> blueprint-ext/v1.0.0"
> > xsi:schemaLocation="
> > http://www.osgi.org/xmlns/blueprint/v1.0.0
> > https://www.osgi.org/xmlns/
> blueprint/v1.0.0/blueprint.xsd”>
> >
> >> update-strategy="reload”
> > placeholder-prefix="#{" placeholder-suffix="}">
> >
> >
> > value="600" />
> >
> >
> >
> >
> >
> >> On Feb 22, 2018, at 9:56 PM, Quinn Stevenson <
> qu...@pronoia-solutions.com> wrote:
> >>
> >> Is that really the XML? It’s not well formed - you start with a
> cm:property-placeholder element and end with a cm:default-properties
> element.
> >>
> >>> On Feb 22, 2018, at 12:48 PM, Alex Soto <alex.s...@envieta.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I am having some problems migrating to Camel 2.20.2 from 2.17.4. I
> have blueprint configuration:
> >>>
> >>> >>> persistent-id=“audit.log”
> >>> update-strategy="reload”
> >>> placeholder-prefix="#{"
> placeholder-suffix="}”>
> >>>
> >>> />
> >>>
> >>>
> >>>
> >>> A component configuration (in this case for Quartz2, but I don’t think
> this is related to Quartz2):
> >>>
> >>>
> >>> value="#{startDelaySeconds}" />
> >>>
> >>>
> >>> Then use this in a route:
> >>>
> >>>
> >>> />
> >>> ...
> >>>
> >>> When I run this (Karaf 4.2.5) an exception is thrown:
> >>>
> >>> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Name audit-log-reaper-quartz is already instanciated as null and cannot be
> removed.
> >>> at org.apache.aries.blueprint.container.BlueprintRepository.
> removeRecipe(BlueprintRepository.java:131) [38:org.apache.aries.
> blueprint.core:1.8.3]
> >>> at org.apache.aries.blueprint.container.BlueprintContainerImpl.
> updateUninstantiatedRecipes(BlueprintContainerImpl.java:572)
> [38:org.apache.aries.blueprint.core:1.8.3]
> >>> at org.apache.aries.blueprint.container.BlueprintContainerImpl.
> processProcessors(BlueprintContainerImpl.java:559) [38:org.apache.aries.
> blueprint.core:1.8.3]
> >>> at org.apache.aries.blueprint.container.
> BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:394)
> [38:org.apache.aries.blueprint.core:1.8.3]
> >>> at org.apache.aries.blueprint.container.
> BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
> [38:org.apache.aries.blueprint.core:1.8.3]
> >>>
> >>>
> >>> This was working fine in Camel 2.17.4. Interestingly, if I remove
> property place holder:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Then it works fine, no errors. So this seems to be related to the
> property placeholders. Has anybody seen this?
> >>> I appreciate any insight on how to solve this problem.
> >>>
> >>> Best regards,
> >>> Alex soto
> >>>
> >>>
> >>>
> >>
> >
>
>
--
Guillaume Nodet
Re: JSch connection issue with Maverick SSHD server
Your server is configured with zlib compression only, while the client only supports compression none, so there's a mismatch and both can't talk to each other. You need to configure the server with both zlib *and* none compression factories. 2014-09-15 7:39 GMT+02:00 Baweja, Keshav keshav.baw...@jpmorgan.com.invalid : Hello I am using Camel 2.13.2 in my application to build up routes to download files from sftp server locations. The codebase has been tested ok against 5 different sftp servers. However against one particular sftp server, JSch the sftp implementation used by Camel seems to disconnect immediately after connecting. Could you please advise what could be the issue here. The log from application is as below - [2014-09-15 05:52:32.236] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using private keyfile: /home/.ssh/id_rsa [2014-09-15 05:52:32.238] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using knownhosts file: /home/.ssh/known_hosts [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] DEBUG org.apache.camel.component.file.remote.SftpOperations - Using StrickHostKeyChecking: no [2014-09-15 05:52:32.329] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - Connecting to hostname port port [2014-09-15 05:52:32.462] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - Connection established [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - Remote version string: SSH-2.0-Maverick_SSHD [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - Local version string: SSH-2.0-JSCH-0.1.50 [2014-09-15 05:52:32.589] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256 [2014-09-15 05:52:32.598] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - CheckKexes: diffie-hellman-group14-sha1 [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - SSH_MSG_KEXINIT sent [2014-09-15 05:52:32.621] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - SSH_MSG_KEXINIT received [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1 [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: ssh-rsa [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: aes128-cbc,aes256-cbc,aes192-cbc,3des-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,blowfish-cbc,cast128-cbc [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: hmac-sha1,hmac-sha1-96 [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: hmac-sha1,hmac-sha1-96 [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: zlib [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: zlib [2014-09-15 05:52:32.622] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH - kex: server: [2014-09-15 05:52:32.623] [Camel (camel-1) thread #0 - sftp://user@hostname:port/data] INFO
Fwd: direct-vm in OSGI
On Wed, Mar 6, 2013 at 2:17 AM, Raúl Kripalani r...@evosent.com wrote: Blueprint starts bundles asynchronously, which leads to the start level not being honoured in most cases. And if it is honoured, it's by fluke and not by design. Aries Blueprint 0.4 introduces an option to make bundles start synchronously [1] [2], but it seems to be available only from Karaf 3.0.0 onwards. This is available in 2.3.x too fwiw. Good news is that Spring DM *does* offer a way to make your bundles start synchronously, thus honouring the start level. You need to add a Spring-Context header to your OSGi MANIFEST, with the option create-asynchronously=false. See [3] for more info. In practice, this approach has worked nicely for me in extraordinary cases where observing the start-level was critical. Does that help? Another way would be to use OSGi services in order to make sure the route is not started before the other bundle is ready. This may need to be improved, and we could have the VM component not fail in such a case, though the risk is really not keep messages and run OOM. Regards, [1] https://issues.apache.org/jira/browse/ARIES-536 [2] https://issues.apache.org/jira/browse/KARAF-1002 [3] http://static.springsource.org/osgi/docs/1.1.0/reference/html/app-deploy.html#app-deploy:headers --- Raúl Kripalani Enterprise Architect, Program Manager, Open Source Integration specialist Apache Camel Committer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Mar 2, 2013, at 20:58, Antoni Mylka wrote: Hi, I've been investigating an issue in our application. It works on Karaf, uses Blueprint and has a number of bundles that start Camel contexts. We use direct-vm endpoints to send messages between contexts residing in different bundles and use karaf start levels to enforce startup ordering. The problem is that most of the time the direct-vm endpoints work, but sometimes they don't. At startup, when the sending bundle sends a message we sometimes get an exception saying that no consumers are available on the endpoint. It looks like a race condition. After some investigation two questions arose: 1. Bundle Start, Blueprint Start, Camel start are done synchronously. With start levels, the bundles on the higher level will start when all camel contexts from all bundles on the previous level have been started. Can assume that in my implementation? How do Aries and camel-blueprint work in this respect? 2. If the above is true, then are direct-vm endpoints safe for inter-bundle communication? Maybe they are a completely bad idea. If the above is false, then I'd need some solution that would wait until consumers become available. Can camel-osgi endpoints do that? Antoni Myłka antoni.my...@gmail.com -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi Fuse Fabric
Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf web console is bound to OSGi even if it can be reused with Camel or ActiveMQ. So the Camel and ActiveMQ community will never drop their own console, because the OSGi users is only a fraction of the user base. Hawtio enable all projects to cooperate on a single web console, at last. So it serves a more general purpose imnsho.
Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi Fuse Fabric
On Fri, Jan 25, 2013 at 2:36 PM, Łukasz Dywicki l...@code-house.org wrote: I'm not angry. I'm just telling the truth. Nobody told to you yet. Thx for that, I think I was really erring on the dark side before ;-) Why you think it's bound to OSGi? We have WAR packaging. Overall destination was always to support other runtimes. The war packaging does start an OSGi framework inside the war. In addition the console heavily depends on pax-wicket, which afaik, does need OSGi. As you said, injection is done through OSGi services. My understanding (feel free to correct me if I'm wrong) is that the camel plugins is injected with a list of CamelContext coming from OSGi. Which kinda means to me, that you need to deploy your camel contexts in OSGi, next to the console itself. Charles was talking about that and he found even a name for it once it will get TLP (Orion). But it was so long ago you propably don't remember. Maybe I missed something, but when the Orion proposal was raised, Karaf web console did not really exist yet. The proposal was to create a TLP for an OSGi web console with a real web framework. None of these ideas did sound good to me at that time (having a TLP for an OSGi web console and rewriting the existing webconsole with a web framework). We disagree, but these 2 years did not really changed my mind. Now, a few people went ahead and rewrote an OSGi based web console, which is nice, but it's still is an OSGi web console and I still don't like the technical design decisions that were taken. And more importantly, this console does not really help half of our camel users which do not use OSGi. Cheers, :) Np. We've been trying to get the webconsole problems fixed since the beginning with ServiceMix 3, so that's almost 6 years ago now. it became even more complicated with ServiceMix 4 switching to OSGi. I think we have a clean solution now that can work for all projects with hawtio. Will the project last and pick up ? No one knows yet. Not all projects are bound to suceed. The one that do usually solves real problems in a clean way. I think hawtio is a good bet now ... until someone comes up with a better project. That's how it works. Lukasz Wiadomość napisana przez Guillaume Nodet gno...@gmail.com w dniu 25 sty 2013, o godz. 14:08: Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf web console is bound to OSGi even if it can be reused with Camel or ActiveMQ. So the Camel and ActiveMQ community will never drop their own console, because the OSGi users is only a fraction of the user base. Hawtio enable all projects to cooperate on a single web console, at last. So it serves a more general purpose imnsho. -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi Fuse Fabric
You misunderstood me. So I rephrase. Camel and ActiveMQ community needs a versatile console which can run in a non OSGi environement, so they can't drop their current web console in favor of the karaf one. This discussion is imho totally relevant for the camel community, as it is for all other projects. I already forwarded the email to the karaf community and other projects may be involved too. On Fri, Jan 25, 2013 at 4:24 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: This is one more reason why the hawt.io discussions should take place in the hawt.io communities. Not here. Thanks, Hadrian On 01/25/2013 08:08 AM, Guillaume Nodet wrote: Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf web console is bound to OSGi even if it can be reused with Camel or ActiveMQ. So the Camel and ActiveMQ community will never drop their own console, because the OSGi users is only a fraction of the user base. Hawtio enable all projects to cooperate on a single web console, at last. So it serves a more general purpose imnsho. -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: [ANN] hawtio: a new lightweight HTML5 console for Apache Camel, ActiveMQ, JMX, OSGi Fuse Fabric
FWIW, I think I first mentioned hawtio in the Camel 3.0 thread (message from 8:27 am) when you asked Lukasz to look at the lightweight web console, only saying we should look at it. James started this different thread to actually not pollute the Camel 3 discussion with hawtio details. So I think we're on the same page. On Fri, Jan 25, 2013 at 4:58 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Ok, that is a different discussion I would rather have in the context of Camel 3.0. I will start a separate thread for this. Having the conversation in the context of the subject of this thread may be confusing. Sorry for the misunderstanding. Cheers, Hadrian On 01/25/2013 10:42 AM, Guillaume Nodet wrote: You misunderstood me. So I rephrase. Camel and ActiveMQ community needs a versatile console which can run in a non OSGi environement, so they can't drop their current web console in favor of the karaf one. This discussion is imho totally relevant for the camel community, as it is for all other projects. I already forwarded the email to the karaf community and other projects may be involved too. On Fri, Jan 25, 2013 at 4:24 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: This is one more reason why the hawt.io discussions should take place in the hawt.io communities. Not here. Thanks, Hadrian On 01/25/2013 08:08 AM, Guillaume Nodet wrote: Lukasz, I'm sorry you're angry, but you're missing the point that the Karaf web console is bound to OSGi even if it can be reused with Camel or ActiveMQ. So the Camel and ActiveMQ community will never drop their own console, because the OSGi users is only a fraction of the user base. Hawtio enable all projects to cooperate on a single web console, at last. So it serves a more general purpose imnsho. -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
Re: Camel OSGi services component
Yes, or something even more flexible such as to(direct-vm:/parent/child) and for the expression, a simple xpath like: from(foo:bar).recipientList(directVm(/parent/*)) or /parent//* Just a thought though, not sure if that's really needed. On Sat, Jun 23, 2012 at 9:18 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Jun 22, 2012 at 10:41 PM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello Guillaume, I suppose static method to retrieve consumers that can be filtered by a custom expression will be quite enough. Yeah that may be a good idea and fairly easy to implement. The regular direct component could in theory also support this, but I guess direct-vm makes the most sense only, as its cross CamelContext communication. The filter expression could also be defined in the uri, if we want to consider that, though the foo name would then become a dummy? Or would it be to confusing if the name is a filter itself .to(direct-vm:dummy?filter=someFilterStuffHere) .to(direct-vm:someFilterStuffHere) Regards, Sergey On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component
Re: Camel OSGi services component
On Fri, Jun 22, 2012 at 6:33 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hello, guys, I agree that if the camel-core could be enhanced to achieve easy cross-context communication in the single JVM it would be fine. Claus committed the direct-vm component recently which is part of 2.10: http://camel.apache.org/direct-vm.html In that case I would not tire the core to OSGi anyhow to be really environment-independent. I suppose that camel context could be published into the JNDI to be retrieved at some time lately to discover consuming endpoints. Thus we can achieve the similar behavior in different environments and from(foo:bar).recipientList(osgiServices(myldapfilter)) would become from(foo:bar).recipientList(vm(myfilter)) Atm, the direct-vm queues are not really accessible afaik, so we may need to enhance the direct-vm slightly to allow retrieving the set of registered consumers (adding a static getRegisteredConsumers on the component should be sufficient). Those are mapped by the path component of the consumer uris, so it already provides some kinda of tree based structure. If that's sufficient, we would just need a simple expression that would filter them based on some regular expression maybe. Regards, Sergey Agree, I think that enhancing the existing could achieve this. Regards JB On 06/21/2012 08:51 AM, Guillaume Nodet wrote: That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast
Re: Camel OSGi services component
Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitsky szh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel OSGi services component
That's really my main goal. If we fit into what already exists more, we'll be able to better leverage everything. On Thu, Jun 21, 2012 at 8:48 AM, Christian Schneider ch...@die-schneider.net wrote: +1 I like that aproach. It would make the OSGi services component a lot simpler. from(foo:bar).recipientList(osgiServices(myldapfilter)) I guess we can use a similar aproach to achieve load balancing. Not sure if the example below already would work but I am sure we could make it work this way or similar: from(foo:bar).loadbalance().roundRobin().recepientList(osgiServices(myldapfilter)) Christian Am 21.06.2012 08:27, schrieb Guillaume Nodet: Yeah, and I agree leveraging OSGi services for that is a good idea. That's not really what I'm concerned about. The goal is to have a way to multicast a message to a set of endpoint which will be discovered at runtime, and that's not really OSGi specific (though the fact that OSGi has a service registry make that use case very relevant). I'd like to reuse what camel-core provides for that instead of going around and implementing a brand new component. The dynamic recipient list works with an Expression which returns a list of endpoints (either Endpoint or string uris), so why not writing such an expression ? This expression could easily use a ServiceTracker internally to track changes on services and the expression itself could be an osgi filter... from(foo:bar).recipientList(osgiServices(myldapfilter)) We could even maybe make use of the CamelContext internal registry which can do some type of discovery (though the osgi implementation is lacking a lot of stuff). A simple one would at least be some kind of regular expression that would match some endpoints. We may need something slightly more specific for vm:// and direct-vm:// which can be used for cross-camelContext exchanges. And sorry if I seem a bit reluctant, I'm just trying to make things fit more cleanly in camel, and improve camel core where it needs rather than implementing a new component. It just seems that your requirements are not really osgi specific and could be made slightly mode generic. On Thu, Jun 21, 2012 at 7:41 AM, Sergey Zhemzhitskyszh.s...@gmail.com wrote: Hi Guillaume, Of course if there is more convenient way to communicate between bundles there is no need in the component. On the moment of development of this component there were multiple ways to do that, for instance: 1. jms component which is rather heavyweight to do inter-bundle communication in the same jvm. 2. vm component which is asynchronous and does not support transactions 3. nmr component which can be used in synchronous mode, but does not support pub-sub, although it does not prevent user from registering multiple consuming endpoints with the same name, so the messages are sent only to the first registered nmr-consumer. The new direct-vm component solves the issue with transactions (like synchronous nmr does) but it does not support pub-sub too. To use a dynamic recipient list it's necessary to have some kind of custom code that will resolve addresses of recipients at runtime. In such a case syncronous nmr can be used as well. The benefit of OSGi services is that this is a standard functionality of OSGi runtime and even OSGi api predisposed to work with an array of them. Furthermore you will get all the benefits of OSGi services, i.e. dynamism, priorities, etc. It would be nice if direct-vm allowed to configure pub-sub with all the options of multicast processor. Regards, Sergey I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM,szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel OSGi services component
I'm a bit skeptic about this component. It seems at first glance that if conflates a few things like osgi service access, multicast, etc... If the goal is to do inter-bundle communication, the new component coming from CAMEL-5370 should already do that and I don't really see the need for the component. For the multicast, using a dynamic recipient list coupled with direct-vm should work. On Tue, May 22, 2012 at 7:57 PM, szh.s...@gmail.com wrote: Hi gurus, Recently I've published camel component that uses OSGi services to communicate between endpoints in different bundles. Here is the link: https://github.com/szhem/camel-osgi I've already raised JIRA issue - https://issues.apache.org/jira/browse/CAMEL-5292 So I'd like to have some feedback if it seems to be useful. Regards, Sergey -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel under OSGi without Spring et al.
That's why you should not try to use Spring-DM. I strongly suggest switching to blueprint if you plan to deploy routes in OSGi. The start level won't even fix the spring problems iirc, or at least not at 100%, mostly because things happen asynchronously, so even after subsequent startup, spring won't wait for the handlers. I suppose your way (using a programmatic wait) might work, but I'm not sure you can even know when the handler will be ready. Though I haven't really worked on Spring-DM since a long time. FWIW, you'll find a detailed post at http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html On Fri, Jan 20, 2012 at 16:00, metatech metatec...@gmail.com wrote: Hi, I agree with both of you, start-levels should be avoided. However, in this case, the application is defined with a Spring XML using Camel routes, so no Java beans are present in the bundle. The application must wait until the Camel namespace is properly registered in the camel-spring OSGi activator. The namespace must be available before the Spring XML file is parsed (which constructs the Spring bean definitions). This cannot be done with a osgi:reference nor a depends-on dependency, because they happen too late. Start levels are not reliable on the first start-up, but they are reliable for the next start-ups. Only a programmatic call in an OSGi activator for the application can wait for the camel-spring bundle be fully activated, but it is a bit cumbersome. Regards, metatech Start-level can't really be trusted, especially if you use blueprint for example, which does actually start the blueprint stuff asynchronously. On Thu, Jan 19, 2012 at 15:49, Donald Whytock lt;dwhytock@gt; wrote: It may be a matter of personal taste, but I disagree with reliance on start levels. It should be more reliable to use a BundleListener to track whether a particular bundle has loaded, or a ServiceTracker with the bundle being watched for launching a here I am service when initialization is complete. Don -- View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5160645.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Camel under OSGi without Spring et al.
Start-level can't really be trusted, especially if you use blueprint for example, which does actually start the blueprint stuff asynchronously. On Thu, Jan 19, 2012 at 15:49, Donald Whytock dwhyt...@gmail.com wrote: It may be a matter of personal taste, but I disagree with reliance on start levels. It should be more reliable to use a BundleListener to track whether a particular bundle has loaded, or a ServiceTracker with the bundle being watched for launching a here I am service when initialization is complete. Don On Thu, Jan 19, 2012 at 9:39 AM, metatech metatec...@gmail.com wrote: Hi, My previous conclusion was not correct. The Camel initialization happens indeed in the addingBundle method, but is called from a SynchronousBundleListener, in the same thread that activates the bundle, and there is only one thread (FelixStartlevel) that activates all feature bundles, so it should it should fully initialized. However, when the problem happens, the following error is logged : 2012-01-19 09:35:41,655 | INFO | ExtenderThread-5 | | CamelNamespaceHandler | OSGi environment not detected. This can happen if the OSGi activator of the bundle camel-spring was not executed before the Camel context is starting. In SMX 4.4, camel-spring is at start-level 50, and applications are at start-level 60, so the activator is meant to be completed before applications are starting. However, during the first start-up, or when the bundle cache is cleaned up, the bundles delivered as Karaf features are installed in parallel with the deployment of applications in the deploy directory. This can explain that the camel-spring (not yet installed at level 50) is executed after some applications are starting. The only solution I can think of is that the bundle cache should be built in a first phase, then the bundle are started in a second phase. Regards, metatech metatech wrote However, the Camel initialization is not finished yet, it is performed in the addingBundle method, which registers Camel components, languages, type converters, ... -- View this message in context: http://camel.465427.n5.nabble.com/Camel-under-OSGi-without-Spring-et-al-tp4507473p5157820.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com
Re: Blueprint bundle + plain Main class from the same project?
I would either use integration tests based on pax-exam, or even easier, deploy your bundle (using osgi:install mvn:groupId/artifactId/version-SNAPSHOT) in a standalone karaf instance and use the dev:watch * command. Each time you rebuild your project using maven, the bundle in karaf will be automatically updated. On Tue, Nov 29, 2011 at 09:14, Alexander Krauss alexander.kra...@qaware.de wrote: On Tue, Nov 29, 2011 at 8:12 AM, Guillaume Nodet gno...@gmail.com wrote: The cxf-example-osgi-blueprint only can be ran inside of OSGi container. You can not run it as a stand-alone Java process. [...] There's a way actually. You need to use PojoSR which is a small library to emulate an OSGi framework but without the classloading (only the registry really). I've been able to have it run Blueprint. Thanks for the pointer. Actually, I was more expecting a solution in terms of the build process, such as being able to build both a blueprint bundle and a stand-alone Java application from the same source tree. But I realize that this is tricky, since the dependencies are quite different in both cases, and also the actual camel context xml seems to be different, too, even if the actual route spec is the same... Instead, what is the recommended way for developing blueprint bundles? Do people usually run Karaf locally or Felix in the IDE? Alex -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Blueprint bundle + plain Main class from the same project?
) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3182) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1927) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:705) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2755) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:235) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284) at org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:75) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:388) ... 23 more -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Component for SSH CLI
Yes, Mina SSHD could be used if needed, but could you elaborate a bit more, I'm not really sure to understand what you have in mind. You want a camel component that would connect through SSH and execute commands remotely ? Maybe that could be a camel-exec enhancement somehow. On Fri, Nov 25, 2011 at 09:20, Claus Ibsen claus.ib...@gmail.com wrote: Apache Mina project has a SSH sub project. Its used by Apache Karaf I think. On Thu, Nov 24, 2011 at 11:15 AM, diwakar diwakar.j...@nsn.com wrote: Hi, Is there a Camel component for SSH command line interface. Please let me know your comment. With Best Regards, Diwakar -- View this message in context: http://camel.465427.n5.nabble.com/Component-for-SSH-CLI-tp5019772p5019772.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Best practices to communicate between Camel Contexts in different OSGi bundles
Avoiding serialization is the most important one I think. On Wed, Oct 12, 2011 at 10:01, Christian Müller christian.muel...@gmail.com wrote: We use the camel jms/activemq component for this. @Charles: Could you please share the advantges of camel nmr over camel jms/activemq with us!? Best, Christian On Wed, Oct 12, 2011 at 8:36 AM, Charles Moulliard cmoulli...@gmail.com wrote: Hi, On Karaf/Servicemix, the recommended approach to communicate between camel routes deployed in separate bundles is to use camel-nmr component Regards, Charles On Fri, Sep 23, 2011 at 12:40 PM, Christian Schneider ch...@die-schneider.net wrote: Hi Andrei, how about using simple OSGi services? You can create a service reference in your spring context and call it as a bean in a camel route. This has the advantage that the communication is not tied to camel. So the bundle implementing the service does not have to know about camel. Christian Am 23.09.2011 09:46, schrieb Andrei Shakirin: Hi, I would like to ask what is the best practice to establish communication between two Camel contexts deployed in a different bundles in OSGi environment. Actually I see the following ways: A) VM component. Declare and deploy different contexts and provide communication using vm: Disadvantage: VM designed for async communication and creates new threads for consuming messages that not always desired. Addition settings for VM is necessary to get synchronious response. B) JMS component. The same as (A) but uses JMS component Disadvantage: JMS produces overhead that is not always desired. C) Share Camel Context as OSGi Service and provide communication using direct: Expose Camel Context as OSGi service, get it in other bundles and add the routes. Use direct: for communication. Disadvantage: have no idea how use this approach with Spring routes configuration D) Expose routes as OSGi services Each route is exposed as OSGi service and uses the producerTemplate to kick off the route when another bundle invokes on the service. Disadvantage: requires additional code to expose and invoke the routes E) Share Spring context via import resource One bundle exports spring configuration as resource, another one imports it in Spring configuration. Spring and Camel context are shared. Disadvantage: import resources is not the best OSGi practice, bundles are staying coupled Do you prefer one of proposed ways or there is a different one? Regards, Andrei. -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: intercept route
If they are registered as OSGi services, the InterceptStrategy should be available in all contexts create with spring and blueprint. However this won't work with java or scala DSLs for examples. I'm going to need that for ServiceMix so I hope to have it ready for 2.8, but in the mean time, an OSGi service should work. On Mon, Jun 27, 2011 at 00:21, Marco Westermann marwesterm...@gmx.de wrote: Hi, just tested the interceptor this page describes: http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html (chapter: Using container wide interceptors). But this doesn't work for me. If I understand it right, the interceptor is only taken from the routes defined in the same osgi-bundle (jar-file deployed to smx) (this could be the mentioned container) But I want to intercept every route deployed in smx without changing the route itself. My goal is to develop an interactive monitoring tool for camel routes, where you can see the following things: Which routes are active in smx at the moment. Which endpoints have been processed. Which messages have been sent to these endpoints. Therefor I'd like to intercept each route by deploying a seperate component (osgi-bundle) to smx. The component takes the informations about the routes (route-infos, bodies, headers etc.) and sends them to a remote service (maybe a web service). An independent application then can visualize the routes and the messages passed through the routes. One idea is to implement this tool into the smx web-console. If I get this to work, I would like to provide the tool to camel if you are interested in such a thing. best regards, Marco Am 24.06.2011 17:10, schrieb Marco Westermann: Hi, is it somehow possible to intercept a route from outside the camel context? I'd like to write a module which intercept every route which is deployed in SMX and does something with the intercepted messages. Thank you in advance. Marco -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: intercept route
On Mon, Jun 27, 2011 at 09:14, Marco Westermann marwesterm...@gmx.de wrote: Hi Guilliaume, thank you for your answer. But if I use an osgi-service I have to include that service into my routes somehow, don't I. Your solution goes this way: http://camel.465427.n5.nabble.com/Camel-OSGI-and-container-wide-interceptors-td2269044.html ? Yeah, I think you're right. Of course the better solution would be to inject every route in all contexts without implementing the monitoring in the route-project itself. Camel 2.8 is supposed to be released soon, so I guess i'll have to work on that for 2.9 as I don't have a good understanding of what I really need yet. But I think you and me are trying to achieve the same things, so I do hope we'll find a common solution. regards, Marco Am 27.06.2011 08:51, schrieb Guillaume Nodet: If they are registered as OSGi services, the InterceptStrategy should be available in all contexts create with spring and blueprint. However this won't work with java or scala DSLs for examples. I'm going to need that for ServiceMix so I hope to have it ready for 2.8, but in the mean time, an OSGi service should work. On Mon, Jun 27, 2011 at 00:21, Marco Westermannmarwesterm...@gmx.de wrote: Hi, just tested the interceptor this page describes: http://camel.apache.org/advanced-configuration-of-camelcontext-using-spring.html (chapter: Using container wide interceptors). But this doesn't work for me. If I understand it right, the interceptor is only taken from the routes defined in the same osgi-bundle (jar-file deployed to smx) (this could be the mentioned container) But I want to intercept every route deployed in smx without changing the route itself. My goal is to develop an interactive monitoring tool for camel routes, where you can see the following things: Which routes are active in smx at the moment. Which endpoints have been processed. Which messages have been sent to these endpoints. Therefor I'd like to intercept each route by deploying a seperate component (osgi-bundle) to smx. The component takes the informations about the routes (route-infos, bodies, headers etc.) and sends them to a remote service (maybe a web service). An independent application then can visualize the routes and the messages passed through the routes. One idea is to implement this tool into the smx web-console. If I get this to work, I would like to provide the tool to camel if you are interested in such a thing. best regards, Marco Am 24.06.2011 17:10, schrieb Marco Westermann: Hi, is it somehow possible to intercept a route from outside the camel context? I'd like to write a module which intercept every route which is deployed in SMX and does something with the intercepted messages. Thank you in advance. Marco -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: intercept route
It seems there's currently no easy way to add an InterceptStrategy without having full control over the CamelContext. I think what would be needed is a static global list of InterceptStrategy that would be automatically added to each CamelContext at creation time. That should be an easy and safe enhancement to the DefaultCamelContext, but I need to make sure it fulfills the need before going that way. Actually, I'm investigating the exact same thing to include in ServiceMix. If you're interested, monitor the servicemix dev list as I plan to start a thread about that next week. On Fri, Jun 24, 2011 at 17:10, Marco Westermann marwesterm...@gmx.de wrote: Hi, is it somehow possible to intercept a route from outside the camel context? I'd like to write a module which intercept every route which is deployed in SMX and does something with the intercepted messages. Thank you in advance. Marco -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Migration from Spring-DM to Blueprint. How to test?
Last week, I've been experimenting with PojoSR (http://code.google.com/p/pojosr/) which looks like a good solution for testing OSGi stuff in a lightweight way. The idea is that you don't boot a full OSGi runtime, but rather emulate an OSGi framewokr in a flat class loader. This project has been initially developped to deploy OSGi based applications into Google App Engine, and it seems to work well enough. Here's a test i've written: https://gist.github.com/953272 Note that by default, all maven dependencies that are bundles will be installed in the osgi framework (which is static and does not support dynamic addition or removal of bundles), so you need to exclude any transitive dep you don't want. The example above actually use blueprint, so it does indeed work. On Fri, Apr 29, 2011 at 23:56, Christian Müller christian.muel...@gmail.com wrote: Hello list! We are planing to migrate from ServiceMix 4.2.0-fuse-02-00 to 4.3.1-fuse-01-09 and from Camel 2.2.0-fuse-02-00 to Camel 2.6.0-fuse-01-09. We also thinking about to migrate from Spring-DM to Blueprint. At present, each of our projects contains three Spring configuration files: - src/main/resources/META-INF/spring/bundle-context.xml - src/main/resources/META-INF/spring/bundle-context-osgi.xml - src/test/resources/META-INF/spring/bundle-context-test.xml bundle-context.xml contains the route definition and all bean definitions. bundle-context-osgi.xml looks up some beans from the OSGI registry (e.g. ActiveMQ connection factory) and the OSGI Config service configuration (osgix:cm-properties). bundle-context-test.xml replaces the bundle-context-osgi.xml in our unit tests and provides plain Spring bean definitions for the services we look up from the OSGI service registry when deployed into ServiceMix. But when we migrate to Blueprint, we depend on OSGI and I'm not sure if it's possible to test our routes in the way we do it at present, using the CamelTestSupport oder CamelSpringTestSupport. I know we also have CamelOSGITestSupport, but it's more complex and less lightweight. Do I miss something? Has anyone a sample test which use Blueprint and not depend on PAX Exam? Thanks in advance, Christian -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com Connect at CamelOne May 24-26 The Open Source Integration Conference http://camelone.com/
Re: Camel Log4j Appender
In case you deploy camel in karaf, camel already defines a custom pax-logging appender which intercepts all log events (slf4j, log4j, jul, jcl) and can process them. See http://camel.apache.org/pax-logging.html On Thu, Apr 14, 2011 at 14:49, Claus Ibsen claus.ib...@gmail.com wrote: Yeah this can be tricky as you would have different classloaders and whatnot. Also the log4j could be shared among different Camel applications. You can use a remote transport of some sort, and send data over HTTP. However if you run in Karaf, then pax-logging, may have some osgi related stuff you can leverage. On Thu, Apr 14, 2011 at 2:17 PM, Gert Villemos gville...@yahoo.de wrote: Creating a custom log4j appender is very easy (... indeed we have one but we are not happy with it as it only injects into ActiveMQ and not into a Camel route). Our only problem (and this is now turning into a developer question more than a user question) is how can the custom Appender which is a part of the log4j hierarchy get a reference to a route producer template? If we for example 1. Configure an instance of the custom appender and using the log4j.properties / log4j.xml file configure it to inject into the route direct:logs. 2. Configure a Camel route 'from(direct:logs).to(activemq:topic:logs)' How do we in the log4j Appender get a reference to the ProducerTemplate with the identifier 'direct:logs'? -- View this message in context: http://camel.465427.n5.nabble.com/Using-Camel-Log4j-on-Multiple-Machines-tp466678p4302852.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com CamelOne 2011: http://fusesource.com/camelone2011/ Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com Connect at CamelOne May 24-26 The Open Source Integration Conference http://camelone.com/
Re: Camel webconsole in Karaf
I'll work on that, but I think that's actually a tricky issue. More on that later... On Friday, February 4, 2011, Bengt Rodehav be...@rodehav.com wrote: That looks a bit discouraging :-( Has this issues stopped completely then or is any progress being mad? /Bengt 2011/2/4 ben.oday ben.o...@initekconsulting.com I was working on adding this features, but have been unable to get it deployed properly (https://issues.apache.org/jira/browse/CAMEL-3519). If anyone has the steps to get this to work, let me know... - Ben O'Day IT Consultant -http://benoday.blogspot.com -- View this message in context: http://camel.465427.n5.nabble.com/Camel-webconsole-in-Karaf-tp3368226p3371232.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel webconsole in Karaf
See my comment on the issue. On Fri, Feb 4, 2011 at 19:46, Guillaume Nodet gno...@gmail.com wrote: I'll work on that, but I think that's actually a tricky issue. More on that later... On Friday, February 4, 2011, Bengt Rodehav be...@rodehav.com wrote: That looks a bit discouraging :-( Has this issues stopped completely then or is any progress being mad? /Bengt 2011/2/4 ben.oday ben.o...@initekconsulting.com I was working on adding this features, but have been unable to get it deployed properly (https://issues.apache.org/jira/browse/CAMEL-3519). If anyone has the steps to get this to work, let me know... - Ben O'Day IT Consultant -http://benoday.blogspot.com -- View this message in context: http://camel.465427.n5.nabble.com/Camel-webconsole-in-Karaf-tp3368226p3371232.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Issue with camel-soap on Karaf
- FuseSource Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Issue with camel-soap on Karaf
Can you remove the boot delegation on com.sun.* and retry ? On Tue, Jan 4, 2011 at 18:04, Charles Moulliard cmoulli...@gmail.com wrote: * which jaxb bundle is/are deployed ? [ 200] [Active ] [ ] [ ] [ 60] Apache ServiceMix :: Bundles :: jaxb-impl (2.1.13.1) * does the system bundle export the sun packages ? No 200 com.sun.xml.bind.v2 200 com.sun.xml.bind.v2.model.annotation 200 com.sun.xml.bind.unmarshaller 200 com.sun.xml.bind.api.impl 200 com.sun.xml.bind.v2.schemagen.episode 200 com.sun.xml.bind.v2.util 200 com.sun.xml.bind.v2.runtime.unmarshaller 200 com.sun.xml.bind.marshaller 200 com.sun.xml.bind.v2.model.runtime 200 com.sun.xml.bind.v2.runtime.reflect.opt 200 com.sun.xml.bind.v2.schemagen.xmlschema 200 com.sun.xml.bind 200 com.sun.xml.bind.v2.model.core 200 com.sun.xml.bind.v2.runtime.output 200 com.sun.xml.bind.v2.bytecode 200 com.sun.xml.bind.api 200 com.sun.xml.bind.v2.model.impl 200 com.sun.xml.bind.v2.model.nav 200 com.sun.xml.bind.v2.schemagen 200 com.sun.xml.bind.util 200 com.sun.xml.bind.v2.runtime.reflect 200 com.sun.xml.bind.v2.runtime 200 com.sun.xml.bind.annotation 200 com.sun.xml.bind.v2.runtime.property * is there a boot delegation on the com.sun.* packages from the jre ? Yes (karaf - 2.1-SNAPSHOT) On Tue, Jan 4, 2011 at 5:58 PM, Guillaume Nodet gno...@gmail.com wrote: Looks like the wrong implementation is used for jaxb. * which jaxb bundle is/are deployed ? * does the system bundle export the sun packages ? * is there a boot delegation on the com.sun.* packages from the jre ? On Tue, Jan 4, 2011 at 17:40, Charles Moulliard cmoulli...@gmail.com wrote: Hi, I would like to use camel-soap into the following camel route cxf:cxfEndpoint id=busServicesFinder address=http://localhost:8282/cxf/serviceFinder; serviceClass=fr.client.proxy.Services /cxf:cxfEndpoint camelContext trace=true xmlns=http://camel.apache.org/schema/spring; dataFormats soapjaxb id=soap contextPath=fr.client.proxy/ /dataFormats route from uri=cxf:bean:busServicesFinder?dataFormat=MESSAGE/ log message=WebService called loggingLevel=INFO/ !-- convertBodyTo type=String/ -- unmarshal ref=soap/ ... but I get the following error in karaf when CXF extract the content and parse it with JAXB as thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Unable to create context at org.apache.camel.component.cxf.CxfConsumer$1.checkFailure(CxfConsumer.java:223)[600:org.apache.camel.camel-cxf:2.5.0] at org.apache.camel.component.cxf.CxfConsumer$1.setResponseBack(CxfConsumer.java:200)[600:org.apache.camel.camel-cxf:2.5.0] at org.apache.camel.component.cxf.CxfConsumer$1.asyncInvoke(CxfConsumer.java:113)[600:org.apache.camel.camel-cxf:2.5.0] at org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:68)[600:org.apache.camel.camel-cxf:2.5.0] at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)[598:org.apache.cxf.bundle:2.2.11] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_22] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_22] at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_22] at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:311)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:275)[598:org.apache.cxf.bundle:2.2.11] at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)[598:org.apache.cxf.bundle:2.2.11] at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)[569:org.apache.servicemix.bundles.jetty-bundle:6.1.22.1] at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)[569:org.apache.servicemix.bundles.jetty-bundle:6.1.22.1] at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)[569:org.apache.servicemix.bundles.jetty-bundle:6.1.22.1] at org.mortbay.jetty.Server.handle(Server.java
Re: Is it possible to cluster camel endpoint?
] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:62)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:104)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:272)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:98)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:91)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:62)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:98)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:89)[92:org.apache.camel.camel-core:2.4.0.fuse-00-00] Is it possible to use clustered endpoints in camel? Best Regards, Sergey -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Claus Ibsen - FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: property-placeholder and classpath
FWIW, you may want to try with blueprint instead of spring-dm (the camel schema is the same, so migration is really easy) and you should be able to leverage property placeholders fully (they are similar to the spring ones). On Fri, Oct 8, 2010 at 06:11, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Oct 8, 2010 at 1:34 AM, Hossein mamerka...@csc.com wrote: Using file instead of classpath worked-out great and I can just refresh the bundle so that it will reload the new property file. Great. Follow-up to that, we have a camel route (bundle) that is that invokes a camel cxf andd is completely in spring dsl and I can't really change that to java dsl. I would also like to have that use properties so that information such as address or aFolderName [1] can be specified in property file. Any recommendation on how to use placeholders in a spring dsl? e.g. route from uri=file:/tmp/aFolderName?delete=true / [1] to uri=someUri/ to uri=cxf:bean:someservice/ to uri=anotherUri/ /route Yeah check this FAQ http://camel.apache.org/how-do-i-use-spring-property-placeholder-with-camel-xml.html -- View this message in context: http://camel.465427.n5.nabble.com/property-placeholder-and-classpath-tp3202843p3203866.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel Component for the OFTP2 protocol
I suppose the sources are those ones: http://websvn.ow2.org/listing.php?repname=accordpath=/odetteftp/trunk/camel-oftp/ Haven't found any binaries though, even on the sonatype snapshot repo. On Wed, Sep 22, 2010 at 07:16, Hadrian Zbarcea hzbar...@gmail.com wrote: Bruno, I couldn't find the code/jar/doc for the camel-oftp component. Odds are interested users won't either (easily). Your blog post does not show what jars are needed and where to find them either. Did I miss it? Could you please provide directed links? Thanks Hadrian On Sep 21, 2010, at 3:02 PM, Bruno Borges wrote: Hi all! Some of you might know the Odette File Transfer Protocol, also know as OFTP. My work @Neociclo aims to present it to the community and as part of that, I'm introducing now the Camel Component for the Accord Odette, a OFTP2 Java library. If you want to know more, please follow this link: http://bit.ly/aLSitv Also, the project is hosted at http://accord.ow2.org/odetteftp The component is a Maven module of the Accord Odette project. Thank you, Bruno Borges www.brunoborges.com.br +55 21 76727099 The glory of great men should always be measured by the means they have used to acquire it. - Francois de La Rochefoucauld -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Using blueprint
Yeah, I'm aware of those issues. You should really wait for the next release of FUSE ESB, or just deploy camel in a karaf snapshot (2.0 will be released soon) 2010/7/16 Guillaume Nodet gno...@gmail.com: Have a look at http://camel.apache.org/using-osgi-blueprint-with-camel.html Let me know if you need more informations. On Fri, Jul 16, 2010 at 13:53, Muhammad Ichsan ich...@gmail.com wrote: Is Camel Blueprint ready for FUSE ESB 4.2.0 container? I want to deploy my Camel-enabled app in blueprint way inside the container. If it's not, I will use Spring way instead. If it is, how to make it work? What features or bundles should be inactive or uninstalled. Thanks -- ~The best men are men who benefit to others http://michsan.web.id 一緒に勉強しましょう！ Yang berkualitas memang beda rasanya! http://rizqi-cookies.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Using blueprint
Have a look at http://camel.apache.org/using-osgi-blueprint-with-camel.html Let me know if you need more informations. On Fri, Jul 16, 2010 at 13:53, Muhammad Ichsan ich...@gmail.com wrote: Is Camel Blueprint ready for FUSE ESB 4.2.0 container? I want to deploy my Camel-enabled app in blueprint way inside the container. If it's not, I will use Spring way instead. If it is, how to make it work? What features or bundles should be inactive or uninstalled. Thanks -- ~The best men are men who benefit to others http://michsan.web.id 一緒に勉強しましょう！ Yang berkualitas memang beda rasanya! http://rizqi-cookies.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: FTP Component That Consumes On Demand
I think Carlo wants to be able to *not* always poll for new files, which is what the polling consumer does. Instead, he's looking for something like an HTTP GET method, which is not really a consumer but a provider with no input. The idea (iiuc) would be to send an exchange to the ftp provider which would cause the retrieval of the given file. I don't think this is possible yet. On Fri, Jun 4, 2010 at 09:20, Claus Ibsen claus.ib...@gmail.com wrote: Hi You are looking at the polling consumer EIP http://camel.apache.org/polling-consumer.html However Content Enricher EIP is also doable http://camel.apache.org/content-enricher.html as there is a pollEnrich DSL for that. However passing in the filename on the URI is a bit hard to do. There is a JIRA ticket to enhance this in the future On Fri, Jun 4, 2010 at 5:29 AM, Carlo Camerino carlo.camer...@gmail.com wrote: Hi, Is there an ftp component that consumes a file on edemand? and not a polling. for example i have the file name already and want to fetch this file coming from an ftp server, how would i route it? from(direct:getfile).to(ftp://someurl?file-name=sd?;) would this fetch a file or would this create a file on that server? thanks carlo -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: FTP Component That Consumes On Demand
Right, this use case is even exactly described at http://camel.apache.org/ftp.html#FTP-ConsumingaremoteFTPservertriggeredbyaroute On Fri, Jun 4, 2010 at 09:43, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Jun 4, 2010 at 9:29 AM, Guillaume Nodet gno...@gmail.com wrote: I think Carlo wants to be able to *not* always poll for new files, which is what the polling consumer does. Instead, he's looking for something like an HTTP GET method, which is not really a consumer but a provider with no input. The idea (iiuc) would be to send an exchange to the ftp provider which would cause the retrieval of the given file. I don't think this is possible yet. This is possible using the polling consumer EIP. It will poll for a remote file on the FTP server. And from the routing DSL you can use pollEnrich also. However one caveat is that setting the endpoint uri in a dynamic fashion is not easy. And we know this and there is a JIRA ticket for that. So yes its possible. On Fri, Jun 4, 2010 at 09:20, Claus Ibsen claus.ib...@gmail.com wrote: Hi You are looking at the polling consumer EIP http://camel.apache.org/polling-consumer.html However Content Enricher EIP is also doable http://camel.apache.org/content-enricher.html as there is a pollEnrich DSL for that. However passing in the filename on the URI is a bit hard to do. There is a JIRA ticket to enhance this in the future On Fri, Jun 4, 2010 at 5:29 AM, Carlo Camerino carlo.camer...@gmail.com wrote: Hi, Is there an ftp component that consumes a file on edemand? and not a polling. for example i have the file name already and want to fetch this file coming from an ftp server, how would i route it? from(direct:getfile).to(ftp://someurl?file-name=sd?;) would this fetch a file or would this create a file on that server? thanks carlo -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Direct-route not shared across contexts?
I think Andreas is looking for exactly the opposite. I don't think the goal of the direct: component was that endpoints would be shared across camel context (as that's what vm: has been written for). So i'm kinda tempted to consider that a bug. On Thu, Jun 3, 2010 at 13:27, Adrian Trenaman trena...@progress.com wrote: Fraid not! If you want to cross camel contexts in the same JVM, you could use the Camel VM (http://camel.apache.org/vm.html) component to do this. Or, you can take a look at using the NMR in SMX4 to achieve something similar. Hope that helps, Ade. On 03/06/2010 12:19, ankelee wrote: Hi Is it possible to have direct endpoints that will not be shared across different camelcontexts in the same JVM? So that each camel context has its own instance of a direct route? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Problem using camel in osgi
You may want to try using the osgi specific camel context instead,
else you need to have all the components and converters available in
your bundle classloader using imported package.
On Saturday, May 22, 2010, Christian Schneider ch...@die-schneider.net wrote:
Hi all,
I am trying to get camel working in osgi. I wrote a simple bundle that starts
up a camel context in it´s activator. I also created a target platform with
hopefully all necessary bundles.
In my context exchanges are created in a file endpoint and should be
converted to string. There I get the exception:
---
No type converter available to convert from type:
org.apache.camel.component.file.GenericFile to the required type:
java.lang.String
An idea what I did wrong?
Greetings
Christian
---
My Activator start method:
public void start(BundleContext context) throws Exception {
DefaultCamelContext ccontext = new DefaultCamelContext();
ccontext.addRoutes(new RouteBuilder() {
public void configure() throws Exception {
from(file://d:/test).convertBodyTo(String.class).process(new Processor() {
public void process(Exchange exchange) throws Exception {
System.out.println(exchange);
}
});
}
});
ccontext.start();
}
-
My Manifest:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Cameltest
Bundle-SymbolicName: cameltest
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: cameltest.Activator
Bundle-ActivationPolicy: lazy
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.osgi.framework;version=1.3.0
Require-Bundle: org.apache.camel.camel-core;bundle-version=2.3.0,
org.apache.camel.camel-spring-osgi;bundle-version=2.3.0
--
My bundles in Equinox:
ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.6.0.v20100422-1745
1 ACTIVE org.springframework.core_2.5.6.A
4 ACTIVE org.springframework.osgi.io_1.2.1
6 ACTIVE org.springframework.transaction_2.5.6.A
7 ACTIVE com.springsource.org.aopalliance_1.0.0
9 ACTIVE org.apache.camel.camel-spring-osgi_2.3.0.SNAPSHOT
12 ACTIVE org.springframework.context_2.5.6.A
13 ACTIVE org.springframework.beans_2.5.6.A
14 ACTIVE org.springframework.osgi.core_1.2.1
17 ACTIVE org.apache.camel.camel-core_2.3.0.SNAPSHOT
19 ACTIVE commons-management_1.0.0
20 ACTIVE org.springframework.aop_2.5.6.A
22 ACTIVE com.springsource.org.apache.commons.logging_1.1.1
23 ACTIVE cameltest_1.0.0.qualifier
--
http://www.liquid-reality.de
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Camel startup dependencies in OSGI/Karaf
We don't have to add anything to the component jars I think. It should be possible to extend camel-osgi bundle in the following way: * when a bundle containing a component is started, register a service in the osgi registry for the component. I think it should be a new interface which will allow the creation of components (a component factory) registered with an asssociated property to identify the type of component (file, jms, etc...) * modify the osgi component resolver or camel context go to the registry and wait for some time until all the components are available The last part might be a bit more tricky, as we need to find a good strategy for that. It could also be configurable on the osgi component context to some degree. On Thu, Apr 29, 2010 at 04:30, Willem Jiang willem.ji...@gmail.com wrote: Bengt Rodehav wrote: Thanks for your reply Willem, I will try to the bundle dependency of camel-core to my route bundle as you suggested - sounds like good advice. I wasn't sure what you mean by your last paragraph: If you need to dependent on some specify component interface will introduce the OSGi related dependency to the camel components. We need to find another way to do it. I assume that there was a problem with my suggestion but I didn't quite understand what. Oh, that is if you want to publish the camel components into a OSGi service, you can do it in the BundleActivator, or write some XML configuration to leverage Spring DM or Blue Print to do it. If you are using BundleActivator, you will introduce some kind of compile time dependency of OSGi jar. As we also want camel components work well as a stand alone Java application, we should avoid introduce this kind of dependency. Maybe the xml configuration is a choice for us. This solution need to your start the Spring-DM or BluePrint container before your camel route bundle to let the container lookup the bundle context for the xml configuration. It seems we are back to your original question. And if you start the camel components bundles before you start up your camel route bundle, you will not hit this kind of issue. Willem /Bengt 2010/4/28 Willem Jiang willem.ji...@gmail.com: Hi Please see my comments in the mail. Bengt Rodehav wrote: I'm using Karaf to deploy my Camel routes. However, I run into problems during startup due to dependency ordering. Some of these ordering problems are OSGI/Karaf specific and have nothing to do with Camel. I've discussed them on the Felix user mailing list and I have workarounds for that. The Camel problems remain though. When trying to deploy both my routes and the camel bundles in Karaf, my routes fail to iniitialize because the referenced camel component (file: in this case) is not registered in Camel yet. I've tried to solve this with workarounds in Karaf. It is possible but not very elegant at all. Can you add the bundle dependency of camel-core to your route bundle? Guillaume Nodet (via us...@felix.apache.org) suggested to me that this is more of a Camel problem than a Karaf problem. In his opinion (and mine), it would be much better if Camel published components using OSGI services. That way my services could have a service dependency on the Camel services so that my service would start when the Camel service was available. As I understand it, today Camel just scans bundles as they are started and updates its component registry. This makes it impossible for dependent bundles (like my routes) to know whether all the required prerequisites are in place before starting the route. That could be a solution of your issue. If components were published using a component specific interface, I could add a service dependency to that service and wait until it becomes available before trying to start my routes. If you need to dependent on some specify component interface will introduce the OSGi related dependency to the camel components. We need to find another way to do it. Has anyone else had similar issues?What is the recommended workaround? Are there any plans for improvement? /Bengt Willem -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel startup dependencies in OSGI/Karaf
On Wed, Apr 28, 2010 at 17:30, Bengt Rodehav be...@rodehav.com wrote: Thanks for your reply Willem, I will try to the bundle dependency of camel-core to my route bundle as you suggested - sounds like good advice. This won't work I think. The reason is that a camel component will only be used if the bundle containing the component is started. However, there is no way to express such a dependency on a started bundle in OSGi. Adding a bundle dependency will only ensure the bundle is resolved. I wasn't sure what you mean by your last paragraph: If you need to dependent on some specify component interface will introduce the OSGi related dependency to the camel components. We need to find another way to do it. I assume that there was a problem with my suggestion but I didn't quite understand what. /Bengt 2010/4/28 Willem Jiang willem.ji...@gmail.com: Hi Please see my comments in the mail. Bengt Rodehav wrote: I'm using Karaf to deploy my Camel routes. However, I run into problems during startup due to dependency ordering. Some of these ordering problems are OSGI/Karaf specific and have nothing to do with Camel. I've discussed them on the Felix user mailing list and I have workarounds for that. The Camel problems remain though. When trying to deploy both my routes and the camel bundles in Karaf, my routes fail to iniitialize because the referenced camel component (file: in this case) is not registered in Camel yet. I've tried to solve this with workarounds in Karaf. It is possible but not very elegant at all. Can you add the bundle dependency of camel-core to your route bundle? Guillaume Nodet (via us...@felix.apache.org) suggested to me that this is more of a Camel problem than a Karaf problem. In his opinion (and mine), it would be much better if Camel published components using OSGI services. That way my services could have a service dependency on the Camel services so that my service would start when the Camel service was available. As I understand it, today Camel just scans bundles as they are started and updates its component registry. This makes it impossible for dependent bundles (like my routes) to know whether all the required prerequisites are in place before starting the route. That could be a solution of your issue. If components were published using a component specific interface, I could add a service dependency to that service and wait until it becomes available before trying to start my routes. If you need to dependent on some specify component interface will introduce the OSGi related dependency to the camel components. We need to find another way to do it. Has anyone else had similar issues?What is the recommended workaround? Are there any plans for improvement? /Bengt Willem -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [Discuss] - Camel Properties Component - Change tokens to avoid clash with Spring 3.0
Could those be parameters on the camel context ?
On Fri, Apr 2, 2010 at 13:30, Willem Jiang willem.ji...@gmail.com wrote:
+1 for #[], or #p{}.
The other options still make the Spring EL confused.
Willem
Claus Ibsen wrote:
Hi
See ticket
https://issues.apache.org/activemq/browse/CAMEL-2599
The problem is that Spring 3.0 includes a EL by default which is
automatic in use in the Spring XML files.
It uses the same tokens as we do with Camel Properties component and
therefore Spring EL fails with an exception.
The easiest and also least problematic resolution is to use a
different tokens in Camel to avoid the clash.
It will also be least surprise by Camel end users if they mix and
match between Spring EL and Camel Properties.
So what tokens do you want to use? Currently we did use
- prefix = #{
- suffix = }
For example:
from(#{cool.start})
.to(log:#{cool.start}?showBodyType=falseshowExchangeId=#{cool.showid})
.to(mock:#{cool.result});
A)
===
I am thinking of changing to:
- prefix = #[
- suffix = ]
For example:
from(#[cool.start])
.to(log:#[cool.start]?showBodyType=falseshowExchangeId=#[cool.showid])
.to(mock:#[cool.result]);
B)
===
Or maybe?
- prefix = #p{
- suffix = }
For example:
from(#p{cool.start})
.to(log:#p{cool.start}?showBodyType=falseshowExchangeId=#p{cool.showid})
.to(mock:#p{cool.result});
C)
We cannot do this one
- prefix = ${
- suffix = }
As it will clash with Camel Simple language (would take more work to
let them co-exist in peace :)
However we could most likely use a longer preifx such as
- prefix = ${p:
- suffix = }
For example:
from(${p:cool.start})
.to(log:${p:cool.start}?showBodyType=falseshowExchangeId=$p{p:cool.showid})
.to(mock:${p:cool.result});
Do you have any thoughts and preference what tokens to use?
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: Camel 2.0 + OSGi
:595) Caused by: javax.xml.bind.JAXBException: Provider com.sun.xml.bind.v2.ContextFactory not found - with linked exception: [java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory] at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:152) at javax.xml.bind.ContextFinder.find(ContextFinder.java:299) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337) at org.apache.camel.spring.handler.CamelNamespaceHandler.createJaxbContext(CamelNamespaceHandler.java:166) at org.apache.camel.spring.handler.CamelNamespaceHandler.getJaxbContext(CamelNamespaceHandler.java:153) at org.apache.camel.spring.handler.CamelNamespaceHandler.parseUsingJaxb(CamelNamespaceHandler.java:144) ... 28 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:117) ... 34 more I have installed the JAXB implementation bundle form springsource which should work fine. The creation of the JAXB context fails, because the spring-camel bundle is missing the required import-package statements (I know no better way even if there is) so the com.sun.xml.bind.v2 resources/classes could be resolved. I know its not fine to import the implementation but the JAXB factory lookup is not that good for OSGi. Any idea how to resolve this in a graceful manner? Thanks for any help Markus Wolf - -- NMMN - New Media Markets Networks GmbH Langbehnstrasse 6, 22761 Hamburg Geschäftsführung: Kfm. Michael Schütt Finanzamt HH-Altona - UStID DE 812 699 852 - HRB 71102 Hamburg HypoVereinsbank - BLZ 200 300 00 - Konto-Nr. 156 29 82 http://www.nmmn.com Tel.: +49 40 284 118-0 - Fax: +49 40 284118-999 Softwareentwicklung LLynch: -720 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksE/K8ACgkQDBHISU1oEKHkrQCfaj575EdYqrWMY40BF/T+tOjt ENMAnA+g4t07MpomVBCe3gQxrryWjGiN =OXeZ -END PGP SIGNATURE- -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel 2.0 + OSGi
(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:117) ... 34 more I have installed the JAXB implementation bundle form springsource which should work fine. The creation of the JAXB context fails, because the spring-camel bundle is missing the required import-package statements (I know no better way even if there is) so the com.sun.xml.bind.v2 resources/classes could be resolved. I know its not fine to import the implementation but the JAXB factory lookup is not that good for OSGi. Any idea how to resolve this in a graceful manner? Thanks for any help Markus Wolf - -- NMMN - New Media Markets Networks GmbH Langbehnstrasse 6, 22761 Hamburg Geschäftsführung: Kfm. Michael Schütt Finanzamt HH-Altona - UStID DE 812 699 852 - HRB 71102 Hamburg HypoVereinsbank - BLZ 200 300 00 - Konto-Nr. 156 29 82 http://www.nmmn.com Tel.: +49 40 284 118-0 - Fax: +49 40 284118-999 Softwareentwicklung LLynch: -720 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksChJ0ACgkQDBHISU1oEKGEWQCdHfqxQPoqBZ0QTlL9ioIhJtAf dlEAn14WQCevi/pE7Mh+qfVTT9ZeySsY =F1Pt -END PGP SIGNATURE- -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel 2.0 + OSGi
:144) ... 28 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:117) ... 34 more I have installed the JAXB implementation bundle form springsource which should work fine. The creation of the JAXB context fails, because the spring-camel bundle is missing the required import-package statements (I know no better way even if there is) so the com.sun.xml.bind.v2 resources/classes could be resolved. I know its not fine to import the implementation but the JAXB factory lookup is not that good for OSGi. Any idea how to resolve this in a graceful manner? Thanks for any help Markus Wolf - -- NMMN - New Media Markets Networks GmbH Langbehnstrasse 6, 22761 Hamburg Geschäftsführung: Kfm. Michael Schütt Finanzamt HH-Altona - UStID DE 812 699 852 - HRB 71102 Hamburg HypoVereinsbank - BLZ 200 300 00 - Konto-Nr. 156 29 82 http://www.nmmn.com Tel.: +49 40 284 118-0 - Fax: +49 40 284118-999 Softwareentwicklung LLynch: -720 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksCmVsACgkQDBHISU1oEKFULACgjJ+O74SbqaEeEg8+TFBfPpEf JdsAn0QX+fXGjMaLHZykIeVsVDlFE3rr =+g+Q -END PGP SIGNATURE- -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel 2.0 + OSGi
) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372) at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337) at org.apache.camel.spring.handler.CamelNamespaceHandler.createJaxbContext(CamelNamespaceHandler.java:166) at org.apache.camel.spring.handler.CamelNamespaceHandler.getJaxbContext(CamelNamespaceHandler.java:153) at org.apache.camel.spring.handler.CamelNamespaceHandler.parseUsingJaxb(CamelNamespaceHandler.java:144) ... 28 more Caused by: java.lang.ClassNotFoundException: com.sun.xml.bind.v2.ContextFactory at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:117) ... 34 more I have installed the JAXB implementation bundle form springsource which should work fine. The creation of the JAXB context fails, because the spring-camel bundle is missing the required import-package statements (I know no better way even if there is) so the com.sun.xml.bind.v2 resources/classes could be resolved. I know its not fine to import the implementation but the JAXB factory lookup is not that good for OSGi. Any idea how to resolve this in a graceful manner? Thanks for any help Markus Wolf - -- NMMN - New Media Markets Networks GmbH Langbehnstrasse 6, 22761 Hamburg Geschäftsführung: Kfm. Michael Schütt Finanzamt HH-Altona - UStID DE 812 699 852 - HRB 71102 Hamburg HypoVereinsbank - BLZ 200 300 00 - Konto-Nr. 156 29 82 http://www.nmmn.com Tel.: +49 40 284 118-0 - Fax: +49 40 284118-999 Softwareentwicklung LLynch: -720 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksC0oIACgkQDBHISU1oEKGmNQCgx2WfUxSP9OW72qHUb+fAR9Ex cvEAnjJlOiK30oWz1aSZDN/Z+v1FuH0i =2b1P -END PGP SIGNATURE- -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Camel 2.0 + OSGi
Willem, it seems you have made this change a long time ago: http://fisheye6.atlassian.com/changelog/camel/?cs=731844 Do you recall the reason ? On Tue, Nov 17, 2009 at 18:03, Guillaume Nodet gno...@gmail.com wrote: If you look at the pom, this package is explicitely *not* imported: http://fisheye6.atlassian.com/browse/camel/trunk/camel-core/pom.xml?r=HEAD Not sure what the reason is though ... On Tue, Nov 17, 2009 at 17:42, Markus Wolf markus.w...@nmmn.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The longer I think about this it seems like a bug in the camel-core bundle to me. The package 'javax.xml.bind.annotation.adapters' is missing in the import headers. The other JAXB packages (javax.xml.bind, javax.xml.bind.annotation) are imported into the bundle. Is my assumption correct? Then I would open a ticket for this. Markus I've traced that this exception (below) is caused by the camel-core bundle. Is there a specific order in which the camel bundles should be loaded by the runtime? Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1459) Markus No other idea? I already tried to import the 'javax.xml.bind.annotation.adapters' package into my bundle it it does not seem to be related to my bundle in any case. Regrads Markus thanks for your responses. I already tried this bundles because the guys at the felix user-list also told me so but the them I get another exception. For reference I do post it here also (below). The ContextFactory is found then, but the classloader issues are still not resolved... Any more ideas? Thank you :) The exception: 2:08:10,777 | ERROR | ExtenderThread-6 | ContextLoaderListener | BundleApplicationContextListener 50 | Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=de.llynch.esb.llynch-sender, config=osgibundle:/META-INF/spring/*.xml)) org.springframework.beans.factory.BeanDefinitionStoreException: Failed to parse JAXB element: javax.xml.bind.JAXBException: Unable to create context - with linked exception: [java.lang.reflect.InvocationTargetException]; nested exception is javax.xml.bind.JAXBException: Unable to create context - with linked exception: [java.lang.reflect.InvocationTargetException] at org.apache.camel.spring.handler.CamelNamespaceHandler.parseUsingJaxb(CamelNamespaceHandler.java:147) at org.apache.camel.spring.handler.CamelNamespaceHandler$CamelContextBeanDefinitionParser.doParse(CamelNamespaceHandler.java:199) at org.springframework.beans.factory.xml.AbstractSingleBeanDefinitionParser.parseInternal(AbstractSingleBeanDefinitionParser.java:84) at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:56) at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:69) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1297) at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1287) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:92) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:507) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:398) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:342) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:310) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149
Re: Camel on Google App Engine
Isn't the activemq uuid generator a lot faster ? On Fri, Oct 16, 2009 at 13:37, James Strachan james.strac...@gmail.com wrote: 2009/10/16 Martin Krasser d...@martin-krasser.de: I'm trying to get camel-core running on Google App Engine. It doesn't run out-of-the-box mainly because Camel's UUID generator. It uses InetAddress that is not on the JRE class whitelist. Replacing the implementation using Java's UUID class, I got a simple route running. Is there any special reason why Camel doesn't use Java's UUID class for generating IDs? Do you see any issues replacing the current implementation? No, it should work with the UUID class AFAIK. Our own UUID generator is mostly a hang-over from JDK 1.4 and ActiveMQ - I don't see any issues yet with using java.util.UUID. If we hit any we could make it pluggable - but for simplicity maybe we should just switch? I'll summarize other issues with Camel on GAE in a separate post. Great! -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Error using Transacted with Camel 2.0
(DependencyWaiterApplicationContextExecutor.java:136) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: policy must be specified on: Transacted[ref: null] at org.apache.camel.util.ObjectHelper.notNull(ObjectHelper.java:258) at org.apache.camel.model.TransactedDefinition.createProcessor(TransactedDefinition.java:129) at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:226) at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:111) at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:294) at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:120) at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:552) at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:969) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:946) at org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:863) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:99) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:119) Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Error using Transacted with Camel 2.0
) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.finishRefresh(AbstractOsgiBundleApplicationContext.java:235) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:358) at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320) at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:136) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: policy must be specified on: Transacted[ref: null] at org.apache.camel.util.ObjectHelper.notNull(ObjectHelper.java:258) at org.apache.camel.model.TransactedDefinition.createProcessor(TransactedDefinition.java:129) at org.apache.camel.model.ProcessorDefinition.makeProcessor(ProcessorDefinition.java:226) at org.apache.camel.model.ProcessorDefinition.addRoutes(ProcessorDefinition.java:111) at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:294) at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:120) at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:552) at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:969) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:946) at org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:52) at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:863) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:99) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:119) Charles Moulliard Senior Enterprise Architect Apache Camel Committer * blog : http://cmoulliard.blogspot.com -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com
Re: camel-cxf AXIS2 on SMX4
If you create your bundle using maven and the maven bundle plugin, add the following to the plugin configuraiton: plugin groupIdorg.apache.felix/groupId artifactIdmaven-bundle-plugin/artifactId configuration instructions ... Require-Bundleorg.apache.cxf.cxf-bundle/Require-Bundle /instructions It will ensure that your bundle is not started before the cxf one is installed. Hopefully it will solve the problem. On Thu, Mar 5, 2009 at 10:30, cmoulliard cmoulli...@gmail.com wrote: Guillaume, Can you explain please what you propose that I do ? Could you try adding a Require-Bundle to the cxf bundle on your own bundle that fail ? gnodet wrote: Got an idea. It may happen that your bundle has been started before the CXF bundle was started. Could you try adding a Require-Bundle to the cxf bundle on your own bundle that fail ? On Wed, Mar 4, 2009 at 18:00, Guillaume Nodet gno...@gmail.com wrote: The JAX-WS spec should have picked up the CXF bundle as a provider. Could you rerun your example after setting the following system property (in etc/system.properties for example) org.apache.servicemix.specs.debug=true This should give infos about the specs. Can you paste those log statements please ? On Wed, Mar 4, 2009 at 17:40, cmoulliard cmoulli...@gmail.com wrote: Here is the list guillaume START LEVEL 100 ID State Spring Level Name [ 0] [Active ] [ ] [0] System Bundle (1.5.0.SNAPSHOT) [ 1] [Active ] [ ] [ 10] Apache Felix Prefrences Service (1.0.2) [ 2] [Active ] [ ] [ 10] geronimo-annotation_1.0_spec (1.1.1) [ 3] [Active ] [ ] [ 10] OSGi R4 Compendium Bundle (4.1.0) [ 4] [Active ] [ ] [ 10] Apache ServiceMix Bundles: jaxp-ri-1.4.2 (1.4.2.1) [ 5] [Active ] [ ] [ 10] Apache Felix Configuration Admin Service (1.0.4) [ 6] [Active ] [ ] [ 10] geronimo-servlet_2.5_spec (1.1.2) [ 7] [Active ] [ ] [ 10] Apache ServiceMix Specs :: JAXP API 1.4 (1.2.0) [ 8] [Active ] [Started] [ 40] Apache ServiceMix Kernel :: GShell Core (1.1.0.SNAPSHOT) [ 9] [Active ] [ ] [8] OPS4J Pax Logging - API (1.3.0) [ 10] [Active ] [ ] [8] OPS4J Pax Logging - Service (1.3.0) [ 11] [Active ] [ ] [5] OPS4J Pax Url - wrap: (0.3.3) [ 12] [Active ] [ ] [5] OPS4J Pax Url - mvn: (0.3.3) [ 13] [Active ] [ ] [ 30] Apache ServiceMix Kernel :: JAAS Modules (1.1.0.SNAPSHOT) [ 14] [Active ] [ ] [ 30] Apache ServiceMix Kernel :: GShell Features (1.1.0.SNAPSHOT) [ 15] [Active ] [ ] [ 30] Apache ServiceMix Kernel :: GShell Admin (1.1.0.SNAPSHOT) [ 16] [Active ] [ ] [ 30] spring-osgi-io (1.2.0.m2) [ 17] [Active ] [ ] [ 30] Apache ServiceMix Bundles: mina-1.1.7 (1.1.7.1) [ 18] [Active ] [ ] [ 30] Apache ServiceMix Kernel :: GShell PackageAdmin Commands (1.1.0.SNAPSHOT) [ 19] [Active ] [ ] [ 30] Apache ServiceMix Kernel :: GShell ConfigAdmin Commands (1.1.0.SNAPSHOT) [ 20] [Active ] [Started] [ 30] Apache ServiceMix Kernel :: GShell OSGi Commands (1.1.0.SNAPSHOT) [ 21] [Active ] [ ] [ 30] Spring Context (2.5.6) [ 22] [Active ] [ ] [ 30] Apache ServiceMix Bundles: commons-jexl-1.1 (1.1.0.1) [ 23] [Active ] [Started] [ 30] Apache ServiceMix Kernel :: JAAS Config (1.1.0.SNAPSHOT) [ 24] [Active ] [ ] [ 30] Apache ServiceMix Bundles: commons-httpclient-3.1 (3.1.0.1) [ 25] [Active ] [ ] [ 30] Spring Core (2.5.6) [ 26] [Active ] [ ] [ 30] jmx-impl (1.0.0.r6125-patched) [ 27] [Active ] [ ] [ 30] jmx (1.0.0.r6125-patched) [ 28] [Active ] [Started] [ 30] Apache ServiceMix Kernel :: GShell Log Commands (1.1.0.SNAPSHOT) [ 29] [Active ] [ ] [ 30] Apache ServiceMix Bundles: commons-vfs-1.0 (1.0.0.1) [ 30] [Active ] [ ] [ 30] Spring Beans (2.5.6) [ 31] [Active ] [ ] [ 30] Unnamed - com.google.code.sshd:sshd:bundle:0.1 (0.1) [ 32] [Active ] [Started] [ 30] Apache ServiceMix Kernel :: Management Core (1.1.0.SNAPSHOT) [ 33] [Active ] [ ] [ 30] Apache ServiceMix Bundles: commons-codec-1.2 (1.2.0.1) [ 34] [Active ] [ ] [ 30] spring-osgi-extender (1.2.0.m2) [ 35] [Active ] [ ] [ 30] Apache ServiceMix Bundles: cglib-2.1_3 (2.1.0.3_1) [ 36] [Active ] [ ] [ 30] Apache ServiceMix Bundles: jline-0.9.94 (0.9.94.1) [ 37] [Active ] [ ] [ 30] Apache ServiceMix Bundles: aopalliance-1.0 (1.0.0.1) [ 38] [Active ] [ ] [ 30] Spring AOP (2.5.6) [ 39] [Active
