> But if Birt has the web app as a context classloader how come
hibernate can't be loaded
> when it exists in there ?
>
>
If hibernate classes aren't in the plugin's classloader, they can be
loaded only using reflection.
This way you loads the Ejb3Configuration to the
ConsoleConfiguration.buildJPAConfiguration method. Ejb3Configuration is
available in the context classloader, but not in the plugin classloader.
I only do that to avoid having to bundle the JPA specific binaries with our plugin.
And I understand this, but I cannot believe Birt find it Ok to require users to
bundle their jars and configuration *twice* to use Birt - even for jdbc drivers and
setup.
Fortunatelly, I have succeeded to solve this issue using OSGi
Equinox
properties. Now, I can control which classes to load from the web
classloader (for ODA BIRT driver, only hibernate classes are necessary)
Yes, this will probably work but again weird hacky flags needs to be set to enable this
;(
>> I am not sure that I understand your question. Seam
doesn't bind a
>> session factory. Binding the session factory can be done by adding the
>> above mentioned Hibernate property.
>> This can be made within the BIRT facet.
>>
>
> Yes, but I would much rather prefer that we had a way to inject a hibernate session
to birt
> via a Seam component than tying a dependency to JNDI.
>
>
Now, since we can load classes from the web app classloader, I need to
find out a way how to grab a session factory.
One way is JNDI (I solved it). I think that adding a Seam component is a
good way, but, in that case, Seam will be required.
I propose to add new properties to the Hibernate ODA datasource like the
following:
- configuration name - it already exists and is used in the design time
as the name of a console configuration (solved)
But this requires/usages whatever random hibernate jar our plugin has, correct ?
It would not be using the same hibernate version as done by the user...
- Seam component name - if it exists, we would use a Seam component
as a
session factory helper
Well, we would probably want to hand in the actual session to be able to utilize
the existing loaded data in the session ? Maybe something to look into later.
- JNDI name - if Seam component name doesn't exist, we would use
it as a
session factory helper (solved)
Which jars would be used in this case ?
We can even add a JDBC datasource if some users are interested in
creating a session factory that way (they don't have Seam and don't want
to bind a session factory to JNDI, for instance).
How can a JDBC datasource be enough for a Hibernate query to work ?
/max