Part of the issue with crafting good examples or good code for that matter
are the exigencies of testing with PojoSR and then using the same code in
development. I'll commonly work around PojoSR only to find code doesn't
work when deployed in Karaf or vice versa. Since tests can't work across
multiple camel contexts it means any test stub bundles have to work without
camel whereas the actual implementations will likely rely on it heavily. So
any classloader/proxy differences are going to rear their ugly heads.
A small example of some of the differences that arise are the use of
private packages in bundles with PojoSR. Note that I've commented the
private out because if that is in there PojoSR will not find the class to
bootstrap to the service.
<configuration>
<manifestLocation>target/META-INF</manifestLocation>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<!--
<Private-Package>${project.groupId}.${project.artifactId}.internal*</Private-Package>
-->
</instructions>
</configuration>
For example:
<service ref="myService" interface="org.foo.MyService" />
<bean id="myService" class="org.foo.internal.FooTestStubServiceImpl"/>
That will fail to load if is used in test scope in another project if the
FooTestStubServiceImpl is actually private. In Karaf, of course, it would
be correctly registered. Taking out the private statement will now
bootstrap the test correctly and the injected type will be of type
com.sun.proxy.$Proxy40.
But for that test to have worked we need to break the encapsulation of the
bundle and are not relying on correctly constructed bundle whose internals
are hidden from the world. Obviously our actual implementation bundle
would be structured differently. And that means it is going to be
fundamentally different in its construction.
That may seem a minor thing and in many cases it is but there are a lot of
these little gotchas around that mean that the way one tests is
fundamentally out of synch with the way one bundles as uses code. It also
starts to drive design decisions in awkward directions. One changes how
one makes POMs, bundles, and tests and end up with bundles that aren't
truly swappable or that have differences. I can't tell you how many times
I go to deploy and have to change blueprint, POMs, and write @Ignore on
tests to get things working. Then I have to go back and rewrite all tests
to make them work.
This becomes exacerbated by the multiple classloader mechanisms and proxy
mechanics that exist in Camel/Karaf/Blueprint. It becomes difficult to
think about design when questioning how an annotation is going to be dealt
with during classloading during CBTS testing versus how it is going to be
dealt with during actual deployment.
On Thu, Feb 11, 2016 at 2:06 PM, Tim Jones <t...@mccarthy.co.nz> wrote:
> Quinn,
>
> I will post something on Monday when back at work. However it shouldn't be
> hard to replicate if you uninstall the bundle providing the service and
> install a modified bundle offering the same service but with different
> functionality (e.g. perhaps just output something different to the
> console).
> Because the service from the original bundle has been cached it will be
> that
> service that is called, not the service from the newly installed modified
> bundle.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/OsgiServiceRegistry-caching-service-references-why-tp5777410p5777617.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
