felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: iPOJO and CamelContext problems (was "Problems triggering a camel route in OSGi")
Date Mon, 30 May 2011 20:06:06 GMT
I solved the problem.

I had misunderstood the iPOJO annotations and exposed my service as follows:

@Provides(specifications = { IService.class }, strategy = "SERVICE")

The problem is that I used the "SERVICE" strategy when I should have used
"SINGLETON" - which is also the default. When using "SERVICE", each invoker
gets its own instance which is why the value of my member variable didn't
stick. When I changed this, the instance is the same in the start() method
and the trigger() mehtod and everything works as it should.

Stupid mistake on my part. Thanks for all your help.

/Bengt


2011/5/30 Bengt Rodehav <bengt@rodehav.com>

> Thanks for your reply Cédric.
>
> I took a look at the URL's but I think that Camel's OSGi support has
> evolved since then. I have also used Camel from within OSGi (from
> Karaf/Felix) for quite some time now with no real problems. I think this is
> more an iPOJO problem but then again I'm not at all sure.
>
> It seems like when I'm initializing my iPOJO member variable, it doesn't
> stick. I then got very suspicious when I found out that "this" refers to
> different instances depending on if I check it from the start() method or
> from the trigger() method (callled from the web service bundle via a
> published OSGi service). Perhaps this is according to the design of iPOJO
> but maybe somone knowledgeable in iPOJO can explain why this is happening.
>
> Thanks,
>
> /Bengt
>
>
> 2011/5/30 Cédric TRAN-XUAN <cedric.tran-xuan@bull.net>
>
>> Hi Bengt,
>> I know some work has been done to use Camel with iPOJO. It has been done
>> to integrate it within JOnAS but seems to be useable outside (see 1st link
>> below). Here are few links.
>>
>>
>> http://mail-archives.apache.org/mod_mbox/camel-users/200902.mbox/%3C4995A2E5.4020507@bull.net%3E
>>
>> http://jonas.ow2.org/camel-jonas5-doc-1.5.12/userguide.html
>>
>> I hope this help...
>>
>> Regards.
>>
>> Le 30/05/2011 15:53, Bengt Rodehav a écrit :
>>
>>  I added a system.out to see what "this" is in the two methods start() and
>>> trigger() respectively. It turns out that "this" is different in those
>>> two
>>> methods which I guess means that iPOJO has created two instances of my
>>> class
>>> and in one of them I initialised the mCamelContext but in the other I
>>> didn't. I now assume that this is an iPOJO problem (or a lack of
>>> understanding on my part).
>>>
>>> Does anyone know how this can happen? Shouldn't "this" be the same in
>>> both
>>> of these methods?
>>>
>>> The start() (@Validate) and stop() (@Invalidate) are only called once.
>>>
>>> /Bengt
>>>
>>> 2011/5/30 Bengt Rodehav<bengt@rodehav.com>
>>>
>>>  I sent the mail below to the Camel mailing list but I'm beginning to
>>>> think
>>>> that it is more of an iPOJO problem than a Camel problem. I would really
>>>> appreciate any help since this is extremely confusing to me.
>>>>
>>>> /Bengt
>>>>
>>>>
>>>> I have a very strange problem that is probably related to classloading.
>>>> I
>>>> use Camel 2.7.1 in Karaf 2.2.0 together with iPOJO.
>>>>
>>>> I create my camel context like this:
>>>>
>>>>   @Validate
>>>>   public void start() {
>>>>     CamelContextFactory factory = new CamelContextFactory();
>>>>     factory.setBundleContext(getBundleContext());
>>>>     mCamelContext = factory.createContext();
>>>>      RouteBuilder builder = createRouteBuilder();
>>>>     try {
>>>>       mCamelContext.addRoutes(builder);
>>>>     } catch (Exception e) {
>>>>       e.printStackTrace();
>>>>     }
>>>>     try {
>>>>       mCamelContext.start();
>>>>     } catch (Exception e) {
>>>>       e.printStackTrace();
>>>>     }
>>>>     System.out.println("start, mCamelContext: " + mCamelContext);
>>>>   }
>>>>
>>>>
>>>> It is created when the iPOJO component becomes valid. I get the bundle
>>>> context in my constructor from iPOJO. The actual routes are created like
>>>> this:
>>>>
>>>>   private RouteBuilder createRouteBuilder() {
>>>>     RouteBuilder builder = new RouteBuilder() {
>>>>
>>>>       from("file:localdir").process(new Processor() {
>>>>         public void process(Exchange theExchange) throws Exception {
>>>>           trigger();
>>>>         }
>>>>       });
>>>>
>>>>       from("direct:start").process()....to("ftp:....);
>>>>     }
>>>>   }
>>>>
>>>> Both routes works fine. When dropping a file in the "localdir", the
>>>> trigger() method is called that in turn will send an exchange to the
>>>> "direct:start" endpoint that will do the real work. The trigger method
>>>> looks
>>>> like this:
>>>>
>>>> *  public void trigger() {    *
>>>> *
>>>>     System.out.println("trigger, mCamelContext: " + mCamelContext);
>>>>     ProducerTemplate producer = mCamelContext.createProducerTemplate();*
>>>> *    Map<String, Object>  headers = new HashMap<String, Object>();*
>>>> *    // ...populate headers*
>>>> *    String body;*
>>>> *    // ... initialize body*
>>>> *    producer.sendBodyAndHeaders("direct:start", body, headers);*
>>>> *  }*
>>>> *
>>>> *
>>>> Dropping the file in "localdir" is just for testing purposes. In real
>>>> life,
>>>> the "direct:start" route is meant to be triggered via a published  OSGi
>>>> service (actually through a web service call). However, this does not
>>>> work
>>>> at all.
>>>>
>>>> Whenever I try to call the trigger() method from somewhere else, the
>>>> mCamelContext member is null and I get a NPE when trying to create the
>>>> producer template. Why is that?
>>>>
>>>> I realize that this might not be a Camel problem but a OSGi/iPOJO
>>>> problem
>>>> but it's definitely related to Camel. I checked what class loader is
>>>> being
>>>> used to for the mCamelContext instance and it turns out to be the
>>>> camel-spring bundle's class loader. Could that be related to my
>>>> problems?
>>>>
>>>> I am very confused about this and would appreciate any help,
>>>>
>>>> /Bengt
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message