fragments, jdbc driver manager, bundle cache, help

[jchurch <Ji...@segmint.com>]

Hello,

Using SMX 4.5, we run into the DriverManager.getDriver problem that has been
discussed over the past few years.  We inject our own DataSource using c3p0
into Hibernate.   Since c3p0 is managing connections, we have created a
fragment that exports the jdbc driver into c3p0.  This works fine normally. 
However, after several times of restarting SMX, we find that the fragment is
no longer hooked to the c3p0 bundle, and so we get a No Suitable Driver in a
stack trace at the point where c3p0 asks the DriverManager to lookup the
driver.  We clean the cache, and all is well again.  We do not wish to clean
the cache every start up.

We have read that perhaps karaf 2.3 will change fragment dependency
management in a way that will correct this problem.  Can anybody confirm
this?

Is there another idea not based on fragments for using c3p0 in osgi?  Or
would some client thread pool (bone?) fall back to using TCCL and maybe we
could leverage that for a fix?

Or if there is no good way to manage our situation, should we just go ahead
and add our jdbc driver to the extensions directory?

Thanks in advance,
Jim






--
View this message in context: http://servicemix.396122.n5.nabble.com/fragments-jdbc-driver-manager-bundle-cache-help-tp5716040.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: fragments, jdbc driver manager, bundle cache, help

[jchurch <Ji...@segmint.com>]

For anybody trying to make heads or tails of this post, I have since found
that I have just one fragment that will not resolve (usually) after a
container restart on Felix only.  Equinox does not break.  Some day I hope
to find the time to identify the root cause.



--
View this message in context: http://servicemix.396122.n5.nabble.com/fragments-jdbc-driver-manager-bundle-cache-help-tp5716040p5716575.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: fragments, jdbc driver manager, bundle cache, help

[jchurch <Ji...@segmint.com>]

Thanks for the reply, Freeman.  Perhaps I was not sufficiently clear in
referring to potential fixes in 2.3 Karaf.  What I based that comment upon
was that 2.3 Karaf will subsume OSGi 4.3 which specifies Provide-Capability
and Requires-Capability bundle headers that I suspect might solve my
problem.

I have seen Refresh work one time in my tests.  More often when I try it, I
wind up with a corrupt gogo shell and I might see a nasty stack trace on the
gogo shell (below).  At any event, I do not see benefit from coding some
activator code to look up another bundle and refresh it just to hack around
this problem, particularly when my tests with gogo using refresh does not
work well.  (For what it's worth, a fairly complex jpa-hibernate feature
seems to be a necessary catalyst in causing my problem.  I can't reproduce
my problem when it is not installed.)

Has anybody experienced issues with fragments (in Felix) becoming corrupt
somehow and no longer attaching to their hosts?  Does anybody have a better
work around then just not depending on the fragment to inject the
export-package, but instead to install the jar file in the extensions
directory.

Stack trace from a gogo refresh is as follows:
admin@root>ERROR: Bundle org.springframework.osgi.extender [80] Error
stopping bundle. (java.lang.NoClassDefFoundError:
org/osgi/framework/ServiceRegistration)
java.lang.NoClassDefFoundError: org/osgi/framework/ServiceRegistration
	at
org.springframework.osgi.util.OsgiServiceUtils.unregisterService(OsgiServiceUtils.java:41)
	at
org.springframework.osgi.extender.internal.support.NamespaceManager.unregisterResolverService(NamespaceManager.java:195)
	at
org.springframework.osgi.extender.internal.support.NamespaceManager.destroy(NamespaceManager.java:223)
	at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener.shutdown(ContextLoaderListener.java:547)
	at
org.springframework.osgi.extender.internal.activator.ContextLoaderListener.stop(ContextLoaderListener.java:431)
	at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:651)
	at org.apache.felix.framework.Felix.stopBundle(Felix.java:2278)
	at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4668)




--
View this message in context: http://servicemix.396122.n5.nabble.com/fragments-jdbc-driver-manager-bundle-cache-help-tp5716040p5716058.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Re: fragments, jdbc driver manager, bundle cache, help

[Freeman Fang <fr...@gmail.com>]

Hi,

As SMX4.5 still use Karaf 2.2.x, so this is not  possible to be Karaf 2.3 issue.

And if the fragment bundle somehow not get picked up by the host bundle, refresh the host bundle normally works. And I suggest you put the fragment and host bundle into same feature, this should be helpful 
－－－－－－－－－－－－－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋

On 2013-3-6, at 下午11:38, jchurch wrote:

> Hello,
> 
> Using SMX 4.5, we run into the DriverManager.getDriver problem that has been
> discussed over the past few years.  We inject our own DataSource using c3p0
> into Hibernate.   Since c3p0 is managing connections, we have created a
> fragment that exports the jdbc driver into c3p0.  This works fine normally. 
> However, after several times of restarting SMX, we find that the fragment is
> no longer hooked to the c3p0 bundle, and so we get a No Suitable Driver in a
> stack trace at the point where c3p0 asks the DriverManager to lookup the
> driver.  We clean the cache, and all is well again.  We do not wish to clean
> the cache every start up.
> 
> We have read that perhaps karaf 2.3 will change fragment dependency
> management in a way that will correct this problem.  Can anybody confirm
> this?
> 
> Is there another idea not based on fragments for using c3p0 in osgi?  Or
> would some client thread pool (bone?) fall back to using TCCL and maybe we
> could leverage that for a fix?
> 
> Or if there is no good way to manage our situation, should we just go ahead
> and add our jdbc driver to the extensions directory?
> 
> Thanks in advance,
> Jim
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://servicemix.396122.n5.nabble.com/fragments-jdbc-driver-manager-bundle-cache-help-tp5716040.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.