|
| Re: Programmatically add BuddyClass-Loading to a Bundle [message #116582 is a reply to message #116575] |
Wed, 27 August 2008 10:18   |
|
Tom Schindl schrieb:
> The only plugin in the system I control is datasource.teneo. Any ideas?
Can you do the following in datasource.teneo?
Bundle dbDriverBundle = getBundle("bla");
java.sql.Driver driver = (java.sql.Driver) dbDriverBundle.loadClass("blah");
// user driver in Hibernate by specifying correct URL
AFAIK, a driver registers itself with the DriverManager. Does Hibernate
really want a driver instance or does it use the DriverManager?
Note, a DataSource might work too.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
| Re: Programmatically add BuddyClass-Loading to a Bundle [message #116901 is a reply to message #116589] |
Mon, 01 September 2008 12:36 |
Eclipse User |
|
|
|
Originally posted by: amottadelli_NO_SPAM.it.ibm.com
I'm curious about the reasons that make the people use "BuddyClass-Loading".
Please correct me if I'm wrong:
- usually frameworks and libraries designed to work in a J2EE
environment rely on thread context class loader to load "user" classes
- Equinox (or OSGi in general) cannot guarantee what is in the tccl
because this is out of its scope.
- Buddy class loading is an hack to work around this limitation
"forcing" the tccl looking up for the "correct" class loader in the call
stack.
In the (limited) scope of OSGi, buddy class loading is an elegant
solution to the problem, but the solution is outside the (current) scope
of OSGi.
Every application needs a thread or process model, so each application
environment is (or should) perfectly able to know and control what is in
the thread context class loader.
Regards,
Sandro
|
|
|
| Re: Programmatically add BuddyClass-Loading to a Bundle [message #116940 is a reply to message #116901] |
Mon, 01 September 2008 17:13 |
|
Alessandro Mottadelli schrieb:
> - usually frameworks and libraries designed to work in a J2EE
> environment rely on thread context class loader to load "user" classes
Yes. That's the problem. Designing a Java library just with a very
specific thread/execution model in mind is a poor design choice.
> - Equinox (or OSGi in general) cannot guarantee what is in the tccl
> because this is out of its scope.
Well, nobody can, not even the JVM or any other container.
> In the (limited) scope of OSGi, buddy class loading is an elegant
> solution to the problem, but the solution is outside the (current) scope
> of OSGi.
IMHO buddy class loading is neither elegant nor a solution to class
loading problem. Same is true for the TCCL. If you design *any* Java
code correctly, you don't need either one (whether the code runs in a
JavaEE container, inside a mobile phone or on the desktop).
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
| Re: Programmatically add BuddyClass-Loading to a Bundle [message #116979 is a reply to message #116940] |
Tue, 02 September 2008 19:12 |
| Eclipse User |
|
|
|
Originally posted by: amottadelli_NO_SPAM.it.ibm.com
Gunnar Wagenknecht ha scritto:
> Alessandro Mottadelli schrieb:
>
>> - Equinox (or OSGi in general) cannot guarantee what is in the tccl
>> because this is out of its scope.
>
> Well, nobody can, not even the JVM or any other container.
>
Don't J2EE containers do that?
>> In the (limited) scope of OSGi, buddy class loading is an elegant
>> solution to the problem, but the solution is outside the (current) scope
>> of OSGi.
>
> IMHO buddy class loading is neither elegant nor a solution to class
> loading problem. Same is true for the TCCL. If you design *any* Java
> code correctly, you don't need either one (whether the code runs in a
> JavaEE container, inside a mobile phone or on the desktop).
>
Could you elaborate? What is in your opinion the best solution to have
custom code loaded by a java library?
> -Gunnar
>
Sandro
|
|
|
|
Powered by
FUDForum. Page generated in 0.03338 seconds
] 
Search
Help
Register
Login
Home
