[jira] [Issue Comment Deleted] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brad Johnson updated CAMEL-9570:

Comment: was deleted

(was: I don't have access to computer or code right now but ran into these
problems earlier and reported them.  When I looked at the code there is a
spot in the camel code that was making a choice about how to handle the
bean.

When I get back to a computer next week I'll take another look.  But I was
getting the same set of problems.  The bean was not getting proxied and
uninstalling the bundle didn't result in the service going away. when I
strayed to actually log the instance what I saw was the concrete type of
the bean and not a proxy.

The only solution I found was to stop using the camel DSL altogether.  That
actually worked out well.  I now use one connector class in my bundles and
inject camel routes into it and then inject that connector into other
beans.  it is
sort of an inversion of control.  The beans now invoke routes through the
connector. The connector in turn invokes other beans. It makes tearing a
snap.

It also means everything is set up in blueprint and I haven't experienced
the problem since.

)

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15339856#comment-15339856
 ] 

Brad Johnson commented on CAMEL-9570:
-

Quinn,

Just got back in the country and to a computer so wanted to look at this again. 
 I did a search to look for an issue I'd reported previously.  I don't know if 
this bears on the same issue you are seeing here.  

https://issues.apache.org/jira/browse/CAMEL-9562

Perhaps if it is then 9562 should be raised to the level of a bug with a 
proposed fix or closed and incorporated into this one since you have captured a 
lot of information. Since you've delved into this a lot deeper do you think 
these are related issues?

In any case, if a route builder or camel context are in the context of 
Blueprint I don't think they should fall back to using the global classloader 
if it can't find a class.  The problem is that means if I've misconfigured my 
bundle(s) somehow the code can still work but it breaks the classloader 
mechanics.  However, just globally changing it at this time might break things 
that are "accidentally" working because they are using the global classloader.

But I'd certainly like to be able to specify a strict mode for blueprint so 
that if the OSGi proxy mechanism and classloader can't find the class I'm 
specifying it shouldn't just fall back on using a global classloader reach 
around.


> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302924#comment-15302924
 ] 

Brad Johnson commented on CAMEL-9570:
-

I'm going to have to go back and recheck this.  At the time I ran into the
problem I'd started working with the Java route builder and the
annotations.  Usually I did everything in beans and XML.  After I ran into
the problem I started looking at the classloaders in Camel and posted a
concern that I had about the order and way classloaders were working.  It's
been awhile and I've been so focused on other technical issues the details
escape recall.

I switched back to using XML for routes and Java beans for all logic and
stopped using the route builder altogether.  I haven't seen the problem
since.  To make my code a bit more Java centric I started using a number of
smaller Camel routes inside the bundles and use @EndpointInject to inject
them into a connector class that I could use in my other Java classes.  But
I've avoided the Java DSL and route builder with blueprint since then.
Well, the other reason I stopped using the route builder is that I didn't
find it helped me interoperate with the Java classes themselves in any
really improved way and when I ran into some bean invocation errors on top
of it it started to feel a bit of a mess.

The hybrid approach of injecting endpoints into a small helper/wrapper
class that I use in my Java classes has worked well.  At least it limits
the casting to and from calls to routes to that one location.  And then I
can inject that into my other Java classes and they can simply call out to
whatever camel routes make sense in the context.  I use an interface on
that connector class so I can even mock it for testing of my Java classes
(though I haven't done that as much as I should ).

I took a quick look at your code and if I get time later tonight I'll look
again.  Did the other bundle you have in their use Camel blueprint XML for
the routes.  In essence doing the same thing as the Java RouteBuilder but
only in blueprint XML?  I'll also have to see if I can find some of the
posts from back when I was wrestling with this same problem some time after
the first of the year.

Brad

On Thu, May 26, 2016 at 3:13 PM, Quinn Stevenson (JIRA) 



> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302684#comment-15302684
 ] 

Brad Johnson commented on CAMEL-9570:
-

Interesting.  I guess you can't post any of the XML?  Did this just start
happening with a newer version of Camel or is this older?  This sort of
news makes me get nervous.   When I expect the behavior to be one way and
something else happens it can be a bit disconcerting.  You mentioned that
you have two blueprint files.  Are you exporting the service from one
bundle and then pulling it by reference in another bundle or are they in
the same bundle/classloader.  When I ran into the problem before what was
especially disconcerting is that the class that implemented the service
interface was explicitly private it in its own bundle.  If something were
wired wrong what I'd expect is a class not found exception but the loader
was actually finding the explicitly private class in that other bundle and
using a reference to it.  So like you I didn't see the timeout happen when
I uninstalled the service provider bundle. Instead the reference to the
concrete implementation was being held onto by the consumer.

At that point you're in classloader hell.

On Thu, May 26, 2016 at 1:04 PM, Quinn Stevenson (JIRA) 



> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302593#comment-15302593
 ] 

Brad Johnson commented on CAMEL-9570:
-

Quinn,

Are you using any of the injection annotations?  I ran into that same
problem when I was using annotations for injection instead of plain ol'
getter/setter.  I think I posted something about it sometime back.  I was
pretty puzzled by it at the time because my service was coming from another
bundle but when I would print out the bean being injected it clearly showed
that it was of the concrete type and not the proxied interface.  That
alarmed me a bit since I wasn't sure what was happening and obviously some
classloader shenanigans were happening that I was unaware of.  When I get
rid of the annotations and used the getter/setter explicitly the problem
went away.  That still left me a bit nervous so I try to check for that
regularly now.

Brad

On Thu, May 26, 2016 at 12:44 PM, Quinn Stevenson (JIRA) 



> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153288#comment-15153288
 ] 

Brad Johnson commented on CAMEL-9570:
-

https://issues.apache.org/jira/browse/CAMEL-3271

Seems that it was around before at least with the package scanner.  I only 
mention it as they are suspiciously alike in that the route builders 
bootstrapped inside the CamelContext appear to have the classloader issue.

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15153279#comment-15153279
 ] 

Brad Johnson commented on CAMEL-9570:
-

I'd be curious what class you see when you inject the reference.  In certain 
configurations with the route builders and annotations I'd see it inject 
non-proxied elements.  When I'd do the blueprintReference.getClass().getName() 
I'd see the concrete type of implementing class.  If I injected it it in a 
different fashion I'd see the com.sun.Proxy which is what I'd expect.  So what 
appears to be happening is that some other mechanic is loading that class and 
injecting in a non-proxied fashion.  When the other bundle is stopped it 
doesn't care because it isn't coming through that classloading mechanism.  

You are seeing the issue when  you do this which is similar to what I was doing 
with the package scanning when I saw that behavior.  I've been sick  for a few 
days and completely modified my design to skirt the issue so I don't recall it 
all right now. 

http://camel.apache.org/schema/blueprint;>



I was doing this:

http://camel.apache.org/schema/blueprint;>
  com.foo.bar


At least I think that was the syntax but it's been awhile.  

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15147772#comment-15147772
 ] 

Brad Johnson commented on CAMEL-9570:
-

Richard,

When you say you can replicate using a routebuilder are you using an annotation 
for the injection?  If I recall that's how I ran into the problem.  That's when 
I started looking at the package scanners. That may be an unrelated problem.  
But as you say, if one manually injects the reference it works fine. 

If I use the @BeanInject annotation I'll get a concrete implementation of the 
interface I'm specifying.  If I manually inject it via blueprint XML the class 
will instead be shown as com.sun.proxy.$Proxy40

I was getting similar unexpected behaviors if I used @Produce or @Consume 
annotations. So there appears to be a fundamental difference in the way the 
references are being handled in annotation processing versus straight XML.


> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9562) OSGi classloader problem

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139370#comment-15139370
 ] 

Brad Johnson commented on CAMEL-9562:
-

I'd like to add that I probably had something misconfigured in one of the 
bundles.  But I'd want that to fail hard.

> OSGi classloader problem
> 
>
> Key: CAMEL-9562
> URL: https://issues.apache.org/jira/browse/CAMEL-9562
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-osgi
>Affects Versions: 2.16.2
>Reporter: Brad Johnson
>Priority: Minor
>
> At least: OSGiClassResolver and OSGiPackageScanner but probably others.  A 
> strict mode flag should be added to enforce using the OSGi classloader.  By 
> default it could be false to be backwardly compatible but when it set to true 
> then the secondary attempt at using the application context classloader would 
> be circumvented.  This should really be the default behavior in an OSGi 
> environment but because of backward compatibility issues that might not be 
> possible. 
> This fix should be relatively easy and unnoticeable by most.  But for those 
> working OSGi environments we usually want the strict mode in order to be in 
> compliance with OSGi.  Without it the current design reflects a classloader 
> leak that shouldn't be allowed.  If a class can't be found then it isn't 
> being exported correctly or a bundle is hiding a class it shouldn't or Camel 
> blueprint isn't being set up correctly or  But in all cases it should 
> fail.
> The OSGi classloader mechanics includes a fall back mechanism that uses the 
> global classloader to find classes if it can't find them in OSGi registry it 
> cheats with SU.
> OSGiClassResolver:
>  if (clazz == null && camelContext != null) {
> // fallback and load class using the application context 
> classloader
> clazz = super.loadClass(name, 
> camelContext.getApplicationContextClassLoader());
> if (LOG.isTraceEnabled()) {
> LOG.trace("Loading class {} using CamelContext {} -> {}", new 
> Object[]{name, camelContext, clazz});
> }
> }
> OSGiPackageScanClassResolver.
>  // if we did not find any new, then fallback to use regular non bundle class 
> loading
> if (classes.size() == classesSize) {
> // Using the non-OSGi classloaders as a fallback
> // this is necessary when use JBI packaging for servicemix-camel 
> SU
> // so that we get chance to use SU classloader to scan packages 
> in the SU
> log.trace("Cannot find any classes in bundles, not trying regular 
> classloaders scanning: {}", packageName);
> for (ClassLoader classLoader : super.getClassLoaders()) {
> if (!isOsgiClassloader(classLoader)) {
> find(test, packageName, classLoader, classes);
> }
> }  
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CAMEL-9562) OSGi classloader problem

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139277#comment-15139277
 ] 

Brad Johnson commented on CAMEL-9562:
-

I doubt that it could be removed at this point.  I found the issue as I was 
moving between blueprint and the package scanner for route builders and found 
that when I ran it it was not proxying the private implementation of a service 
from another bundle.  The actual class was being used.  That means there are 
likely folks out there who have functioning code in place that functions due to 
a classloader leak.  The only reason I noticed it was some flakiness I was 
seeing when I would swap bundles.  I'd get exceptions due to the missing 
implementation.  After running a restart on the bundle it worked.

So a Boolean strictMode setting that could be set in the configuration file for 
future projects would likely be required so that already deployed code would 
not break.  By default the strictMode would be set to false and checked as 
follows.  The default would be Boolean.FALSE so all mechanics would work as 
expected.  For new projects that could be set to TRUE and breaks could be dealt 
with.

OSGiPackageScanClassResolver.
// if we did not find any new, then fallback to use regular non bundle class 
loading
if(strictMode.equals(Boolean.TRUE) throw new 
ClassNotFoundInOSGiRegistryException(clazz);
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel SU
// so that we get chance to use SU classloader to scan packages in the SU
log.trace("Cannot find any classes in bundles, not trying regular classloaders 
scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader))
{ find(test, packageName, classLoader, classes); }

} 


> OSGi classloader problem
> 
>
> Key: CAMEL-9562
> URL: https://issues.apache.org/jira/browse/CAMEL-9562
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-osgi
>Affects Versions: 2.16.2
>Reporter: Brad Johnson
>Priority: Minor
>
> At least: OSGiClassResolver and OSGiPackageScanner but probably others.  A 
> strict mode flag should be added to enforce using the OSGi classloader.  By 
> default it could be false to be backwardly compatible but when it set to true 
> then the secondary attempt at using the application context classloader would 
> be circumvented.  This should really be the default behavior in an OSGi 
> environment but because of backward compatibility issues that might not be 
> possible. 
> This fix should be relatively easy and unnoticeable by most.  But for those 
> working OSGi environments we usually want the strict mode in order to be in 
> compliance with OSGi.  Without it the current design reflects a classloader 
> leak that shouldn't be allowed.  If a class can't be found then it isn't 
> being exported correctly or a bundle is hiding a class it shouldn't or Camel 
> blueprint isn't being set up correctly or  But in all cases it should 
> fail.
> The OSGi classloader mechanics includes a fall back mechanism that uses the 
> global classloader to find classes if it can't find them in OSGi registry it 
> cheats with SU.
> OSGiClassResolver:
>  if (clazz == null && camelContext != null) {
> // fallback and load class using the application context 
> classloader
> clazz = super.loadClass(name, 
> camelContext.getApplicationContextClassLoader());
> if (LOG.isTraceEnabled()) {
> LOG.trace("Loading class {} using CamelContext {} -> {}", new 
> Object[]{name, camelContext, clazz});
> }
> }
> OSGiPackageScanClassResolver.
>  // if we did not find any new, then fallback to use regular non bundle class 
> loading
> if (classes.size() == classesSize) {
> // Using the non-OSGi classloaders as a fallback
> // this is necessary when use JBI packaging for servicemix-camel 
> SU
> // so that we get chance to use SU classloader to scan packages 
> in the SU
> log.trace("Cannot find any classes in bundles, not trying regular 
> classloaders scanning: {}", packageName);
> for (ClassLoader classLoader : super.getClassLoaders()) {
> if (!isOsgiClassloader(classLoader)) {
> find(test, packageName, classLoader, classes);
> }
> }  
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CAMEL-9562) OSGi classloader problem

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139277#comment-15139277
 ] 

Brad Johnson edited comment on CAMEL-9562 at 2/9/16 5:43 PM:
-

I doubt that it could be removed at this point.  I found the issue as I was 
moving between blueprint and the package scanner for route builders and found 
that when I ran it it was not proxying the private implementation of a service 
from another bundle.  The actual class was being used.  That means there are 
likely folks out there who have functioning code in place that functions due to 
a classloader leak.  The only reason I noticed it was some flakiness I was 
seeing when I would swap bundles.  I'd get exceptions due to the missing 
implementation.  After running a restart on the bundle it worked.

So a Boolean strictMode setting that could be set in the configuration file for 
future projects would likely be required so that already deployed code would 
not break.  By default the strictMode would be set to false and checked as 
follows.  The default would be Boolean.FALSE so all mechanics would work as 
they currently do.  For new projects that could be set to TRUE and breaks could 
be dealt with.

OSGiPackageScanClassResolver.
// if we did not find any new, then fallback to use regular non bundle class 
loading
if(strictMode.equals(Boolean.TRUE) throw new 
ClassNotFoundInOSGiRegistryException(clazz);
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel SU
// so that we get chance to use SU classloader to scan packages in the SU
log.trace("Cannot find any classes in bundles, not trying regular classloaders 
scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader))
{ find(test, packageName, classLoader, classes); }

} 



was (Author: ranx):
I doubt that it could be removed at this point.  I found the issue as I was 
moving between blueprint and the package scanner for route builders and found 
that when I ran it it was not proxying the private implementation of a service 
from another bundle.  The actual class was being used.  That means there are 
likely folks out there who have functioning code in place that functions due to 
a classloader leak.  The only reason I noticed it was some flakiness I was 
seeing when I would swap bundles.  I'd get exceptions due to the missing 
implementation.  After running a restart on the bundle it worked.

So a Boolean strictMode setting that could be set in the configuration file for 
future projects would likely be required so that already deployed code would 
not break.  By default the strictMode would be set to false and checked as 
follows.  The default would be Boolean.FALSE so all mechanics would work as 
expected.  For new projects that could be set to TRUE and breaks could be dealt 
with.

OSGiPackageScanClassResolver.
// if we did not find any new, then fallback to use regular non bundle class 
loading
if(strictMode.equals(Boolean.TRUE) throw new 
ClassNotFoundInOSGiRegistryException(clazz);
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel SU
// so that we get chance to use SU classloader to scan packages in the SU
log.trace("Cannot find any classes in bundles, not trying regular classloaders 
scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader))
{ find(test, packageName, classLoader, classes); }

} 


> OSGi classloader problem
> 
>
> Key: CAMEL-9562
> URL: https://issues.apache.org/jira/browse/CAMEL-9562
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-osgi
>Affects Versions: 2.16.2
>Reporter: Brad Johnson
>Priority: Minor
>
> At least: OSGiClassResolver and OSGiPackageScanner but probably others.  A 
> strict mode flag should be added to enforce using the OSGi classloader.  By 
> default it could be false to be backwardly compatible but when it set to true 
> then the secondary attempt at using the application context classloader would 
> be circumvented.  This should really be the default behavior in an OSGi 
> environment but because of backward compatibility issues that might not be 
> possible. 
> This fix should be relatively easy and unnoticeable by most.  But for those 
> working OSGi environments we usually want the strict mode in order to be in 
> compliance with OSGi.  Without it the current design reflects a classloader 
> leak that shouldn't be allowed.  If a class can't be found then it isn't 
> being exported correctly or a bundle is hiding a class it shouldn't or Camel 
> blueprint isn't being set up 

[jira] [Commented] (CAMEL-9570) Blueprint Proxies are not used when injected into Java RouteBuilders

[Brad Johnson (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15137176#comment-15137176
 ] 

Brad Johnson commented on CAMEL-9570:
-

https://issues.apache.org/jira/browse/CAMEL-9562

This may be related. The OSGi classloader is fundamentally broken by fallback 
mechanisms that use a global classloader to grab files. 

> Blueprint Proxies are not used when injected into Java RouteBuilders
> 
>
> Key: CAMEL-9570
> URL: https://issues.apache.org/jira/browse/CAMEL-9570
> Project: Camel
>  Issue Type: Bug
>  Components: camel-blueprint, camel-core
>Affects Versions: 2.16.2
>Reporter: Quinn Stevenson
>Assignee: Christian Schneider
>
> Basic Conditions:
> - Java interface used for OSGi Services
> - Implementation of the Java interface registered as a OSGi service.  Note 
> that the package containing implementation is NOT exported
> - A Java RouteBuilder that uses the Java interface via bean(...) DSL calls, 
> with a setter for the bean implementing the interface
> - Wire everything together with Blueprint - create a  for the 
> service, a  for the RouteBuilder and inject the service reference, 
> and use the RouteBuilder in a CamelContext.
> After all this is deployed, stop the bundle implementing the service.  A 
> ServiceUnavailableException should be thrown after a timeout, but the object 
> that was injected into the RouteBuilder process the request - so the 
> Blueprint Proxy is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CAMEL-9562) OSGi classloader problem

[Brad Johnson (JIRA)]

Brad Johnson created CAMEL-9562:
---

 Summary: OSGi classloader problem
 Key: CAMEL-9562
 URL: https://issues.apache.org/jira/browse/CAMEL-9562
 Project: Camel
  Issue Type: Improvement
  Components: camel-osgi
Affects Versions: 2.16.2
Reporter: Brad Johnson
Priority: Minor


At least: OSGiClassResolver and OSGiPackageScanner but probably others.  A 
strict mode flag should be added to enforce using the OSGi classloader.  By 
default it could be false to be backwardly compatible but when it set to true 
then the secondary attempt at using the application context classloader would 
be circumvented.  This should really be the default behavior in an OSGi 
environment but because of backward compatibility issues that might not be 
possible. 

This fix should be relatively easy and unnoticeable by most.  But for those 
working OSGi environments we usually want the strict mode in order to be in 
compliance with OSGi.  Without it the current design reflects a classloader 
leak that shouldn't be allowed.  If a class can't be found then it isn't being 
exported correctly or a bundle is hiding a class it shouldn't or Camel 
blueprint isn't being set up correctly or  But in all cases it should fail.

The OSGi classloader mechanics includes a fall back mechanism that uses the 
global classloader to find classes if it can't find them in OSGi registry it 
cheats with SU.
OSGiClassResolver:
 if (clazz == null && camelContext != null) {
// fallback and load class using the application context classloader
clazz = super.loadClass(name, 
camelContext.getApplicationContextClassLoader());
if (LOG.isTraceEnabled()) {
LOG.trace("Loading class {} using CamelContext {} -> {}", new 
Object[]{name, camelContext, clazz});
}
}

OSGiPackageScanClassResolver.
 // if we did not find any new, then fallback to use regular non bundle class 
loading
if (classes.size() == classesSize) {
// Using the non-OSGi classloaders as a fallback
// this is necessary when use JBI packaging for servicemix-camel SU
// so that we get chance to use SU classloader to scan packages in 
the SU
log.trace("Cannot find any classes in bundles, not trying regular 
classloaders scanning: {}", packageName);
for (ClassLoader classLoader : super.getClassLoaders()) {
if (!isOsgiClassloader(classLoader)) {
find(test, packageName, classLoader, classes);
}
}  
}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)