8:21 p.m.
There is a problem with deploying a BIRT web project when using
Hibernate. Hibernate classes can't be loaded from within the OSGi
framework because they have already been loaded with web classloader.
It is possible to solve this issue in several ways:
1) Using JNDI JDBC datasource.
It is necessary to create a separate session factory within OSGi; the
ODA plugin has to contain Hibernate libraries. In my opinion, this is
the worst solution and I skipped it.
2) Using JNDI SessionFactory and reflection.
The server has to bind the SessionFactory in JNDI, using
<property name="hibernate.session_factory_name"
value="java:/[ODA_DATASOURCE_NAME]"/>
in the persistence.xml file, for instance.
I have implemented this solution.
3) Creating a Session Facade Bean that would execute and analyze a query
for clients (BIRT OSGi engine)
This solution can be easily implemented, but requires an EJB environment.
4) Injecting web classloader into OSGi bundles using Adaptor Hooks
(http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
this method yet, but think that the problem can be solved this way. I
will try it ASAP.
I have committed the org.jboss.tools.birt.core plugin that fixes the
BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
implement solution #2.
Tested using Ganymede RC2.
Snjeza
3:51 a.m.
There is a problem with deploying a BIRT web project when using
Hibernate. Hibernate classes can't be loaded from within the OSGi
framework because they have already been loaded with web classloader.
...this just sounds like a really broken design in BIRT...I can't beleive
they don't support using classes from the sourrounding webapp.
It is possible to solve this issue in several ways:
1) Using JNDI JDBC datasource.
It is necessary to create a separate session factory within OSGi; the
ODA plugin has to contain Hibernate libraries. In my opinion, this is
the worst solution and I skipped it.
Yes.
2) Using JNDI SessionFactory and reflection.
The server has to bind the SessionFactory in JNDI, using
<property name="hibernate.session_factory_name"
value="java:/[ODA_DATASOURCE_NAME]"/>
in the persistence.xml file, for instance.
I have implemented this solution.
hmm...not sure how many binds it to jndi...not sure even if Seam does that?
3) Creating a Session Facade Bean that would execute and analyze a
query
for clients (BIRT OSGi engine)
This solution can be easily implemented, but requires an EJB environment.
hmm...why ? I don't follow this ?
4) Injecting web classloader into OSGi bundles using Adaptor Hooks
(http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
this method yet, but think that the problem can be solved this way. I
will try it ASAP.
Ok - sounds interesting.
I have committed the org.jboss.tools.birt.core plugin that fixes the
BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
implement solution #2.
Tested using Ganymede RC2.
Ok, when I get my ganymede updated ill try.
Do we need our Birt facet going forward ? Birt it self accepted the patch, right?
-max
10:21 a.m.
Max Rydahl Andersen wrote:
> There is a problem with deploying a BIRT web project when using
> Hibernate. Hibernate classes can't be loaded from within the OSGi
> framework because they have already been loaded with web classloader.
>
...this just sounds like a really broken design in BIRT...I can't beleive
they don't support using classes from the sourrounding webapp.
BIRT is executed within OSGi; it adds a web application loader as a
context classloader.
The rest of the problem is related to OSGi (and Hibernate), not to BIRT.
> It is possible to solve this issue in several ways:
>
> 1) Using JNDI JDBC datasource.
> It is necessary to create a separate session factory within OSGi; the
> ODA plugin has to contain Hibernate libraries. In my opinion, this is
> the worst solution and I skipped it.
>
Yes.
> 2) Using JNDI SessionFactory and reflection.
> The server has to bind the SessionFactory in JNDI, using
> <property name="hibernate.session_factory_name"
> value="java:/[ODA_DATASOURCE_NAME]"/>
> in the persistence.xml file, for instance.
> I have implemented this solution.
>
hmm...not sure how many binds it to jndi...not sure even if Seam does that?
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.
> 3) Creating a Session Facade Bean that would execute and analyze
a query
> for clients (BIRT OSGi engine)
> This solution can be easily implemented, but requires an EJB environment.
>
hmm...why ? I don't follow this ?
We could enable a user to choose a type of deployment (by adding a
property to the Hibernate datasource, for instance). Then we would
create a stateful session bean that would implement the
IOdaSessionFactory interface (it is defined in the
org.jboss.tools.birt.oda plugin). The client (HibernateConnection) would
use this bean in a similar way as it uses
ConsoleConfigurationOdaSessionFactory in the design mode or
ServerOdaSessionFactory in the deploy mode.
> 4) Injecting web classloader into OSGi bundles using Adaptor
Hooks
> (http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
> this method yet, but think that the problem can be solved this way. I
> will try it ASAP.
>
Ok - sounds interesting.
> I have committed the org.jboss.tools.birt.core plugin that fixes the
> BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
> and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
> implement solution #2.
> Tested using Ganymede RC2.
>
Ok, when I get my ganymede updated ill try.
Do we need our Birt facet going forward ? Birt it self accepted the patch, right?
The BIRT facet will be available in BIRT RC4, I assume.
I will refactor org.jboss.tools.birt.core after that and probably use
post-install delegate instead the facet.
Snjeza
7:32 a.m.
>> There is a problem with deploying a BIRT web project when
using
>> Hibernate. Hibernate classes can't be loaded from within the OSGi
>> framework because they have already been loaded with web classloader.
>>
>
> ...this just sounds like a really broken design in BIRT...I can't beleive
> they don't support using classes from the sourrounding webapp.
>
>
BIRT is executed within OSGi; it adds a web application loader as a
context classloader.
The rest of the problem is related to OSGi (and Hibernate), not to BIRT.
But if Birt has the web app as a context classloader how come hibernate can't be
loaded
when it exists in there ?
>> 2) Using JNDI SessionFactory and reflection.
>> The server has to bind the SessionFactory in JNDI, using
>> <property name="hibernate.session_factory_name"
>> value="java:/[ODA_DATASOURCE_NAME]"/>
>> in the persistence.xml file, for instance.
>> I have implemented this solution.
>>
>
> hmm...not sure how many binds it to jndi...not sure even if Seam does that?
>
>
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.
>> 3) Creating a Session Facade Bean that would execute and
analyze a query
>> for clients (BIRT OSGi engine)
>> This solution can be easily implemented, but requires an EJB environment.
>>
>
> hmm...why ? I don't follow this ?
>
>
We could enable a user to choose a type of deployment (by adding a
property to the Hibernate datasource, for instance). Then we would
create a stateful session bean that would implement the
IOdaSessionFactory interface (it is defined in the
org.jboss.tools.birt.oda plugin). The client (HibernateConnection) would
use this bean in a similar way as it uses
ConsoleConfigurationOdaSessionFactory in the design mode or
ServerOdaSessionFactory in the deploy mode.
Ok, but why does it require a stateful session bean ? Why not just a normal java class ?
>> 4) Injecting web classloader into OSGi bundles using Adaptor
Hooks
>> (http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
>> this method yet, but think that the problem can be solved this way. I
>> will try it ASAP.
>>
>
> Ok - sounds interesting.
>
>
>> I have committed the org.jboss.tools.birt.core plugin that fixes the
>> BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
>> and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
>> implement solution #2.
>> Tested using Ganymede RC2.
>>
>
> Ok, when I get my ganymede updated ill try.
> Do we need our Birt facet going forward ? Birt it self accepted the patch, right?
>
>
The BIRT facet will be available in BIRT RC4, I assume.
I will refactor org.jboss.tools.birt.core after that and probably use
post-install delegate instead the facet.
ok.
/max
8:24 a.m.
Max Rydahl Andersen wrote:
>>> There is a problem with deploying a BIRT web project when
using
>>> Hibernate. Hibernate classes can't be loaded from within the OSGi
>>> framework because they have already been loaded with web classloader.
>>>
>>>
>> ...this just sounds like a really broken design in BIRT...I can't beleive
>> they don't support using classes from the sourrounding webapp.
>>
>>
>>
> BIRT is executed within OSGi; it adds a web application loader as a
> context classloader.
> The rest of the problem is related to OSGi (and Hibernate), not to BIRT.
>
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.
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)
>>> 2) Using JNDI SessionFactory and reflection.
>>> The server has to bind the SessionFactory in JNDI, using
>>> <property name="hibernate.session_factory_name"
>>> value="java:/[ODA_DATASOURCE_NAME]"/>
>>> in the persistence.xml file, for instance.
>>> I have implemented this solution.
>>>
>>>
>> hmm...not sure how many binds it to jndi...not sure even if Seam does that?
>>
>>
>>
> 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)
- Seam component name - if it exists, we would use a Seam component as a
session factory helper
- JNDI name - if Seam component name doesn't exist, we would use it as a
session factory helper (solved)
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).
Snjeza
>>> 3) Creating a Session Facade Bean that would execute and
analyze a query
>>> for clients (BIRT OSGi engine)
>>> This solution can be easily implemented, but requires an EJB environment.
>>>
>>>
>> hmm...why ? I don't follow this ?
>>
>>
>>
> We could enable a user to choose a type of deployment (by adding a
> property to the Hibernate datasource, for instance). Then we would
> create a stateful session bean that would implement the
> IOdaSessionFactory interface (it is defined in the
> org.jboss.tools.birt.oda plugin). The client (HibernateConnection) would
> use this bean in a similar way as it uses
> ConsoleConfigurationOdaSessionFactory in the design mode or
> ServerOdaSessionFactory in the deploy mode.
>
Ok, but why does it require a stateful session bean ? Why not just a normal java class ?
>>> 4) Injecting web classloader into OSGi bundles using Adaptor Hooks
>>> (http://wiki.eclipse.org/index.php/Adaptor_Hooks). I haven't implemented
>>> this method yet, but think that the problem can be solved this way. I
>>> will try it ASAP.
>>>
>>>
>> Ok - sounds interesting.
>>
>>
>>
>>> I have committed the org.jboss.tools.birt.core plugin that fixes the
>>> BIRT facet (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=235206)
>>> and changed the o.j.t.b.oda and o.j.t.b.oda.ui plugins in order to
>>> implement solution #2.
>>> Tested using Ganymede RC2.
>>>
>>>
>> Ok, when I get my ganymede updated ill try.
>> Do we need our Birt facet going forward ? Birt it self accepted the patch,
right?
>>
>>
>>
> The BIRT facet will be available in BIRT RC4, I assume.
> I will refactor org.jboss.tools.birt.core after that and probably use
> post-install delegate instead the facet.
>
ok.
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
9:47 a.m.
> 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
10:14 a.m.
Max Rydahl Andersen wrote:
>> 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.
No, BIRT doesn't require users to bundle their jars and configuration
twice. However, OSGi doesn't use the app. classloader or system
classpath by default.
> 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
;(
It is an OSGi feature.
>>> 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...
This is used in the design time within an Eclipse application and
hibernate jars from hibernate tools plugins are used by the Hibernate
ODA driver.
The user creates BIRT reports in this mode. This isn't related to a web
application.
> - 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.
The BIRT ODA driver requires a component to implement IOdaSessionFactory
interface that will execute and analyze a hibernate query. The component
can do it in any way.
> - 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 ?
jars from the web app loader. The Hibernate ODA driver doesn't contain
any jars.
> 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 ?
The user would add the hibernate.cfg.xml (or hibernate.properties) file.
However, this is just my suggestion. We don't have to implement it.
Snjeza
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
10:23 a.m.
>> 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.
>
>
No, BIRT doesn't require users to bundle their jars and configuration
twice. However, OSGi doesn't use the app. classloader or system
classpath by default.
Ok, so if it cannot use our classes nor jars how does Birt avoid rebundling of jars and
configuration twice ?
>> 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 ;(
>
It is an OSGi feature.
Yes ? Does not change the fact that it is a hack caused by Birt requiring us to start an
osgi app
inside our web app to just freaking render a pdf/html report.
>>>> 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...
>
>
This is used in the design time within an Eclipse application and
hibernate jars from hibernate tools plugins are used by the Hibernate
ODA driver.
The user creates BIRT reports in this mode. This isn't related to a web
application.
k.
>> - 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.
>
>
The BIRT ODA driver requires a component to implement IOdaSessionFactory
interface that will execute and analyze a hibernate query. The component
can do it in any way.
A sessionfactory cannot execute and analyze a hibernate query - I assume you create a
Session to get it.
>> - 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 ?
>
jars from the web app loader. The Hibernate ODA driver doesn't contain
any jars.
And that works without messing with the classloader or does it still require the
classloader/osgi tweaks ?
/max
8:31 a.m.
BIRT RC4 is released. I will refactor org.jboss.tools.birt.core
Snjeza
> The BIRT facet will be available in BIRT RC4, I assume.
> I will refactor org.jboss.tools.birt.core after that and probably use
> post-install delegate instead the facet.
>
ok.
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
6419
days inactive
6420
days old
jbosstools-dev@lists.jboss.org
8 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
Snjezana Peco -
Snjezana Peco