Re: servicemix integration with ActiveBPEL
Bruce Snyder wrote: > On 6/6/06, Alex Boisvert <[EMAIL PROTECTED]> wrote: >> >> Yes, you can use the ServiceMix BPEL example as a starting point. >> >> Assuming you use a Spring context to initialize your webapp, it becomes >> mostly a question of declaring the BPEL engine as a component in the >> context and wiring components with it.And don't forget to add all >> jar dependencies into your webapp ;) > > For a while, the PXE JBI implementation was broken and it was unusable > from within ServiceMix. Is the PXE JBI integration working again? > As far as I know, yes. We don't run nightly integration tests with JBI yet, but I've hooked up some examples together with ServiceMix 2.0.2 not too long ago. As I said, you need to wire things directly between the Spring context and the pxe-system.xml so there's a few places where endpoints need to match in order to have messages flowing nicely. No rocket science, just the usual configuration drudgery... We'll have a revamped JBI integration layer in less than a week or two, so it will be worth resynchronizing at that point. I can give you a heads-up when things are ready if you're interested. cheers, alex
Re: servicemix integration with ActiveBPEL
On 6/6/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Yes, you can use the ServiceMix BPEL example as a starting point.
Assuming you use a Spring context to initialize your webapp, it becomes
mostly a question of declaring the BPEL engine as a component in the
context and wiring components with it.And don't forget to add all
jar dependencies into your webapp ;)
For a while, the PXE JBI implementation was broken and it was unusable
from within ServiceMix. Is the PXE JBI integration working again?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
SPAM Re: ServiceMix integration
Thanks Dain.
As Aaron just pointed in its previous mail, the component may have its
own JNDI context, but Service Units may need some too. And the problem
is that a service unit may not contain any code, just some data: the
components will handle the data and perform the necessary tasks. So the
use of JNDI references can only work for components, not for service units.
I really think that a global JNDI context would be the most appropriate
thing, though the problem is to determine which resources will be in it
i guess.
I had in mind to create a context and binding resources dynamically with
a gbean query by querying JCAManagedConnectionFactory with
J2EEApplication=null. I have looked at the code for geronimo-naming
and related context creation upon deployment, and I do not really see
how resources can be bind in a JNDI context without knowing their main
interface. This information is provided when referencing such a
resource from a web-app deployment descriptor, but in my case, I do not
have such information. If you have any hints on that it would be cool ...
Cheers,
Guillaume Nodet
Dain Sundstrom wrote:
It appears that the JBI spec didn't provide any way to normalize the
JNDI environment between different app servers (JBI 1.0 page 241):
getNamingContext()
public javax.naming.InitialContext getNamingContext()
Get the JNDI naming context for this component. This context is a
standard JNDI InitialContext but
its content will vary based based on the environment in which the
JBI implementation is running.
Returns: the JNDI naming context; must be non-null.
Rather than try to shoehorn ServiceMix into a Geronimo paradigm,
Guillaume how do you want this to work in Geronimo?
Based on the number of requests for a global JNDI, I think we need to
finally implement it regardless of how distasteful some may find it.
Of course, I'd schedule it for Geronimo 1.2 :)
-dain
On Apr 4, 2006, at 9:46 AM, Aaron Mulder wrote:
I guess I'm wondering how this will work with other app servers, and
how portable the code will be. Let's say you're trying to deploy the
same EJB+JBI configuration in ServiceMix+Geronimo and also
ServiceMix+App Server X where that product supports a global JNDI
space.
Will the code look like this?
SomeEJBHome home = null;
if(amIinGeronimo()) {
// Geronimo uses local JNDI space with mapping file
home = new InitialContext().lookup("java:comp/env/ejb/SomeEJB");
} else if(amIinAppServerX()) {
// App Server X uses global JNDI space
home = new InitialContext().lookup("ejb/SomeEJB");
} else ...
Or would you plan to have geronimo-jbi.xml and also appserverx-jbi.xml
so that the code could be the same for both
("java:comp/env/ejb/SomeEJB") and it would just be the mapping
strategy that was different depending on which product you were
deploying in?
I think it would be "more portable" to have the code always use the
local JNDI space and assume that each app server will have their own
way to write a mapping file (product-jbi.xml or whatever) to force
something into a local JNDI space accessible to the JBI components.
This way the code wouldn't be different for different servers, only
the config files. However, 1) that requires you always write a
mapping file and 2) we have no proof that any other app server would
allow a local JNDI space for JBI components...
It seems like a bit of a dilemma. I'm comfortable going with a
geronimo-jbi.xml strategy if you are.
If we wanted to minimize mapping requirements, we could try to do
something like map all EJBs in the same EAR into the local JNDI space
of the JBI component by default, though the auto-generated names might
be a bit ugly (java:comp/env/name-of-ejb-jar-in-ear/name-of-ejb-in-
ejb-jar).
Then you'd only need to provide manual mapping for any EJBs in a
different EAR. I'm not sure how easy this would be to implement (in
particular, I think it would be hard if we couldn't force the EJB
deployer to run before the JBI deployer), but we might as well think
about what we'd like to see and then we can figure out how easy it is
to do it. :)
Another related question I have is, will you be able to deploy both
JBI components (containers, such as a BPEL engine) and also JBI
service units (things to deploy into those JBI components, such as a
specific BPEL process) using the Geronimo deployer infrastructure? I
think I understand deploying Service Units (in a Service Assembly zip)
but I don't understand what a JBI component deployment looks like
(other than it's a JAR). Will both of these require resource mapping,
or will it only be the service units that need specific resources?
That is, will it be the case that you give the BPEL Engine a database
to save its state to for all its processes, or will you only give each
BPEL Business Process a database that the engine should save its state
to?
Thanks,
Aaron
P.S. I'd also like to have a way to automatically connect Session EJBs
to the
Re: ServiceMix integration
Thanks Dain.
As Aaron just pointed in its previous mail, the component may have its
own JNDI context, but Service Units may need some too. And the problem
is that a service unit may not contain any code, just some data: the
components will handle the data and perform the necessary tasks. So the
use of JNDI references can only work for components, not for service units.
I really think that a global JNDI context would be the most appropriate
thing, though the problem is to determine which resources will be in it
i guess. I had in mind to create a context and binding resources
dynamically with a gbean query by querying JCAManagedConnectionFactory
with J2EEApplication=null. I have looked at the code for
geronimo-naming and related context creation upon deployment, and I do
not really see how resources can be bind in a JNDI context without
knowing their main interface. This information is provided when
referencing such a resource from a web-app deployment descriptor, but in
my case, I do not have such information. If you have any hints on that
it would be cool ...
Cheers,
Guillaume Nodet
Dain Sundstrom wrote:
It appears that the JBI spec didn't provide any way to normalize the
JNDI environment between different app servers (JBI 1.0 page 241):
getNamingContext()
public javax.naming.InitialContext getNamingContext()
Get the JNDI naming context for this component. This context is a
standard JNDI InitialContext but
its content will vary based based on the environment in which the
JBI implementation is running.
Returns: the JNDI naming context; must be non-null.
Rather than try to shoehorn ServiceMix into a Geronimo paradigm,
Guillaume how do you want this to work in Geronimo?
Based on the number of requests for a global JNDI, I think we need to
finally implement it regardless of how distasteful some may find it.
Of course, I'd schedule it for Geronimo 1.2 :)
-dain
On Apr 4, 2006, at 9:46 AM, Aaron Mulder wrote:
I guess I'm wondering how this will work with other app servers, and
how portable the code will be. Let's say you're trying to deploy the
same EJB+JBI configuration in ServiceMix+Geronimo and also
ServiceMix+App Server X where that product supports a global JNDI
space.
Will the code look like this?
SomeEJBHome home = null;
if(amIinGeronimo()) {
// Geronimo uses local JNDI space with mapping file
home = new InitialContext().lookup("java:comp/env/ejb/SomeEJB");
} else if(amIinAppServerX()) {
// App Server X uses global JNDI space
home = new InitialContext().lookup("ejb/SomeEJB");
} else ...
Or would you plan to have geronimo-jbi.xml and also appserverx-jbi.xml
so that the code could be the same for both
("java:comp/env/ejb/SomeEJB") and it would just be the mapping
strategy that was different depending on which product you were
deploying in?
I think it would be "more portable" to have the code always use the
local JNDI space and assume that each app server will have their own
way to write a mapping file (product-jbi.xml or whatever) to force
something into a local JNDI space accessible to the JBI components.
This way the code wouldn't be different for different servers, only
the config files. However, 1) that requires you always write a
mapping file and 2) we have no proof that any other app server would
allow a local JNDI space for JBI components...
It seems like a bit of a dilemma. I'm comfortable going with a
geronimo-jbi.xml strategy if you are.
If we wanted to minimize mapping requirements, we could try to do
something like map all EJBs in the same EAR into the local JNDI space
of the JBI component by default, though the auto-generated names might
be a bit ugly (java:comp/env/name-of-ejb-jar-in-ear/name-of-ejb-in-
ejb-jar).
Then you'd only need to provide manual mapping for any EJBs in a
different EAR. I'm not sure how easy this would be to implement (in
particular, I think it would be hard if we couldn't force the EJB
deployer to run before the JBI deployer), but we might as well think
about what we'd like to see and then we can figure out how easy it is
to do it. :)
Another related question I have is, will you be able to deploy both
JBI components (containers, such as a BPEL engine) and also JBI
service units (things to deploy into those JBI components, such as a
specific BPEL process) using the Geronimo deployer infrastructure? I
think I understand deploying Service Units (in a Service Assembly zip)
but I don't understand what a JBI component deployment looks like
(other than it's a JAR). Will both of these require resource mapping,
or will it only be the service units that need specific resources?
That is, will it be the case that you give the BPEL Engine a database
to save its state to for all its processes, or will you only give each
BPEL Business Process a database that the engine should save its state
to?
Thanks,
Aaron
P.S. I'd also like to have a way to automatically connect Session EJBs
to the
Re: ServiceMix integration
It appears that the JBI spec didn't provide any way to normalize the
JNDI environment between different app servers (JBI 1.0 page 241):
getNamingContext()
public javax.naming.InitialContext getNamingContext()
Get the JNDI naming context for this component. This context is a
standard JNDI InitialContext but
its content will vary based based on the environment in which the
JBI implementation is running.
Returns: the JNDI naming context; must be non-null.
Rather than try to shoehorn ServiceMix into a Geronimo paradigm,
Guillaume how do you want this to work in Geronimo?
Based on the number of requests for a global JNDI, I think we need to
finally implement it regardless of how distasteful some may find it.
Of course, I'd schedule it for Geronimo 1.2 :)
-dain
On Apr 4, 2006, at 9:46 AM, Aaron Mulder wrote:
I guess I'm wondering how this will work with other app servers, and
how portable the code will be. Let's say you're trying to deploy the
same EJB+JBI configuration in ServiceMix+Geronimo and also
ServiceMix+App Server X where that product supports a global JNDI
space.
Will the code look like this?
SomeEJBHome home = null;
if(amIinGeronimo()) {
// Geronimo uses local JNDI space with mapping file
home = new InitialContext().lookup("java:comp/env/ejb/SomeEJB");
} else if(amIinAppServerX()) {
// App Server X uses global JNDI space
home = new InitialContext().lookup("ejb/SomeEJB");
} else ...
Or would you plan to have geronimo-jbi.xml and also appserverx-jbi.xml
so that the code could be the same for both
("java:comp/env/ejb/SomeEJB") and it would just be the mapping
strategy that was different depending on which product you were
deploying in?
I think it would be "more portable" to have the code always use the
local JNDI space and assume that each app server will have their own
way to write a mapping file (product-jbi.xml or whatever) to force
something into a local JNDI space accessible to the JBI components.
This way the code wouldn't be different for different servers, only
the config files. However, 1) that requires you always write a
mapping file and 2) we have no proof that any other app server would
allow a local JNDI space for JBI components...
It seems like a bit of a dilemma. I'm comfortable going with a
geronimo-jbi.xml strategy if you are.
If we wanted to minimize mapping requirements, we could try to do
something like map all EJBs in the same EAR into the local JNDI space
of the JBI component by default, though the auto-generated names might
be a bit ugly (java:comp/env/name-of-ejb-jar-in-ear/name-of-ejb-in-
ejb-jar).
Then you'd only need to provide manual mapping for any EJBs in a
different EAR. I'm not sure how easy this would be to implement (in
particular, I think it would be hard if we couldn't force the EJB
deployer to run before the JBI deployer), but we might as well think
about what we'd like to see and then we can figure out how easy it is
to do it. :)
Another related question I have is, will you be able to deploy both
JBI components (containers, such as a BPEL engine) and also JBI
service units (things to deploy into those JBI components, such as a
specific BPEL process) using the Geronimo deployer infrastructure? I
think I understand deploying Service Units (in a Service Assembly zip)
but I don't understand what a JBI component deployment looks like
(other than it's a JAR). Will both of these require resource mapping,
or will it only be the service units that need specific resources?
That is, will it be the case that you give the BPEL Engine a database
to save its state to for all its processes, or will you only give each
BPEL Business Process a database that the engine should save its state
to?
Thanks,
Aaron
P.S. I'd also like to have a way to automatically connect Session EJBs
to the JBI bus if they define a WSDL interface. But this is a
different issue. :)
On 4/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Thanks Aaron, see comments inline...
Aaron Mulder wrote:
Guillaume,
You're right that there's generally no server-wide JNDI context.
It's
possible to look up any resource in the server at runtime using
Geronimo-specific APIs (such as Kernel.listGBeans, or using the
JSR-77
management APIs). For J2EE apps, the standard practice leans
towards
binding everything at deployment time, so we have a deployment
descriptor that maps the declared resources to actual resources
in the
server during deployment. Then we create the component-specific
JNDI
space during deployment containing the resources to be made
avaliable
to the component, because that's what J2EE dictates. But it's
not the
only possible way things could work.
Thanks for these precisions. It confirms what i was thinking by
looking
at the code.
I'm having trouble wrapping my head around how resources should
normally work in ServiceMix. Is there some place in jbi.xml or
other
standard JBI deployment information for,
Re: ServiceMix integration
I guess I'm wondering how this will work with other app servers, and
how portable the code will be. Let's say you're trying to deploy the
same EJB+JBI configuration in ServiceMix+Geronimo and also
ServiceMix+App Server X where that product supports a global JNDI
space.
Will the code look like this?
SomeEJBHome home = null;
if(amIinGeronimo()) {
// Geronimo uses local JNDI space with mapping file
home = new InitialContext().lookup("java:comp/env/ejb/SomeEJB");
} else if(amIinAppServerX()) {
// App Server X uses global JNDI space
home = new InitialContext().lookup("ejb/SomeEJB");
} else ...
Or would you plan to have geronimo-jbi.xml and also appserverx-jbi.xml
so that the code could be the same for both
("java:comp/env/ejb/SomeEJB") and it would just be the mapping
strategy that was different depending on which product you were
deploying in?
I think it would be "more portable" to have the code always use the
local JNDI space and assume that each app server will have their own
way to write a mapping file (product-jbi.xml or whatever) to force
something into a local JNDI space accessible to the JBI components.
This way the code wouldn't be different for different servers, only
the config files. However, 1) that requires you always write a
mapping file and 2) we have no proof that any other app server would
allow a local JNDI space for JBI components...
It seems like a bit of a dilemma. I'm comfortable going with a
geronimo-jbi.xml strategy if you are.
If we wanted to minimize mapping requirements, we could try to do
something like map all EJBs in the same EAR into the local JNDI space
of the JBI component by default, though the auto-generated names might
be a bit ugly (java:comp/env/name-of-ejb-jar-in-ear/name-of-ejb-in-ejb-jar).
Then you'd only need to provide manual mapping for any EJBs in a
different EAR. I'm not sure how easy this would be to implement (in
particular, I think it would be hard if we couldn't force the EJB
deployer to run before the JBI deployer), but we might as well think
about what we'd like to see and then we can figure out how easy it is
to do it. :)
Another related question I have is, will you be able to deploy both
JBI components (containers, such as a BPEL engine) and also JBI
service units (things to deploy into those JBI components, such as a
specific BPEL process) using the Geronimo deployer infrastructure? I
think I understand deploying Service Units (in a Service Assembly zip)
but I don't understand what a JBI component deployment looks like
(other than it's a JAR). Will both of these require resource mapping,
or will it only be the service units that need specific resources?
That is, will it be the case that you give the BPEL Engine a database
to save its state to for all its processes, or will you only give each
BPEL Business Process a database that the engine should save its state
to?
Thanks,
Aaron
P.S. I'd also like to have a way to automatically connect Session EJBs
to the JBI bus if they define a WSDL interface. But this is a
different issue. :)
On 4/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> Thanks Aaron, see comments inline...
>
> Aaron Mulder wrote:
>
> >Guillaume,
> >
> >You're right that there's generally no server-wide JNDI context. It's
> >possible to look up any resource in the server at runtime using
> >Geronimo-specific APIs (such as Kernel.listGBeans, or using the JSR-77
> >management APIs). For J2EE apps, the standard practice leans towards
> >binding everything at deployment time, so we have a deployment
> >descriptor that maps the declared resources to actual resources in the
> >server during deployment. Then we create the component-specific JNDI
> >space during deployment containing the resources to be made avaliable
> >to the component, because that's what J2EE dictates. But it's not the
> >only possible way things could work.
> >
> >
> Thanks for these precisions. It confirms what i was thinking by looking
> at the code.
>
> >I'm having trouble wrapping my head around how resources should
> >normally work in ServiceMix. Is there some place in jbi.xml or other
> >standard JBI deployment information for, say, a service unit to
> >declare that it needs resources like a JMS connection factory and
> >destination? If not, how is ServiceMix/Geronimo supposed to know what
> >resources to provide? Is there just an assumption that a global JNDI
> >namespace will be present containing every resource in the server and
> >each component can look up whatever it wants to?
> >
> >
> The only relationship between JBI and JNDI is that the JBI container
> should provide an InitialContext for a JBI component.
> See
> http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/component/ComponentContext.html
> In addition to the JNDI context, a MBeanServer and a TransactionManager
> should be provided. These are really the only links between JBI and J2EE.
> However, the purpose of JBI is to integrate things, so I
Re: ServiceMix integration
Thanks Aaron, see comments inline... Aaron Mulder wrote: Guillaume, You're right that there's generally no server-wide JNDI context. It's possible to look up any resource in the server at runtime using Geronimo-specific APIs (such as Kernel.listGBeans, or using the JSR-77 management APIs). For J2EE apps, the standard practice leans towards binding everything at deployment time, so we have a deployment descriptor that maps the declared resources to actual resources in the server during deployment. Then we create the component-specific JNDI space during deployment containing the resources to be made avaliable to the component, because that's what J2EE dictates. But it's not the only possible way things could work. Thanks for these precisions. It confirms what i was thinking by looking at the code. I'm having trouble wrapping my head around how resources should normally work in ServiceMix. Is there some place in jbi.xml or other standard JBI deployment information for, say, a service unit to declare that it needs resources like a JMS connection factory and destination? If not, how is ServiceMix/Geronimo supposed to know what resources to provide? Is there just an assumption that a global JNDI namespace will be present containing every resource in the server and each component can look up whatever it wants to? The only relationship between JBI and JNDI is that the JBI container should provide an InitialContext for a JBI component. See http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/component/ComponentContext.html In addition to the JNDI context, a MBeanServer and a TransactionManager should be provided. These are really the only links between JBI and J2EE. However, the purpose of JBI is to integrate things, so I guess accessing JMS resources, EJBs or JDBC datasources ia a must. Let's take a real example: the BPE BPEL engine (in incubating ODE apache project) uses EJB as a persistence mechanism (the current JBI component for BPE only uses memory persistence), so the BPEL engine itself has to be deployed in Geronimo. Then the JBI component would need to lookup and call these EJB to actually perform the work. The questions you are asking are really the ones for which i look answers. I have no real idea what is the best way. The only thing I know is that the JBI spec does not define anything on that. I was thinking of creating a geronimo-jbi.xml deployment plan where JNDI resources would be specified and where gbeans could be added. I guess this is the only solution to work around the problem that there is no global JNDI context. In addition, if we take the ODE-BPE engine, I think that the EJB jar and the JBI component could be deployed inside the same EAR. This means that the J2EE deployer should be enhanced to support JBI modules. Obviously, this is not supported by the J2EE specs, and as djencks said, this need to be tuned off if needed. (Though if the JBI container configuration is stopped, I think this will be automatic). I 'm really looking for feedback on this as I am not not a J2EE expert, nor a Geronimo expert ... Cheers, Guillaume Nodet Thanks, Aaron On 4/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Thanks to dain and djencks advises, I have began to write a real ServiceMix integration for Geronimo. However I am facing a number of problems. The problem is that the JBI spec needs some things to be done when undeploying jbi artifacts so I will be in need of an event fired before undeployment (and not after as this is the current case). Let me explain the use case for this. The JBI container is a server (like a web server or EJB server): it accepts three kind of deployment artifacts: component, shared libraries and service assemblies. A shared library is a collection of jars to be added to the classpath of a component. A component is also a container, like a BPEL engine for example. A service assembly is a package containing service units. These service units are given to a target component upon deployment. A service unit could a BPEL process. When deploying a BPEL process onto a BPEL engine, the engine may have to store the process in a database at deployment time and remove the clean the database when undeploying the service unit. The JBI spec has all the needed interfaces to perform these deployment / undeployment steps. The only problem is that I have not found any way to know when a configuration is being undeployed. Looking at the kernel, it seems it should be quite easy to do, so I think I will raise a JIRA for that and attach a patch at a later time. The next problem, which is IMHO more important, is how to access managed resources. In the previous BPEL engine example, the component has to access a database. A JMS component would access a JMS connection factory. These resources should be accessed via JNDI. I have browsed the naming / deployer code these past days and AFAIK, there is no server-wide JNDI
Re: ServiceMix integration
Guillaume, You're right that there's generally no server-wide JNDI context. It's possible to look up any resource in the server at runtime using Geronimo-specific APIs (such as Kernel.listGBeans, or using the JSR-77 management APIs). For J2EE apps, the standard practice leans towards binding everything at deployment time, so we have a deployment descriptor that maps the declared resources to actual resources in the server during deployment. Then we create the component-specific JNDI space during deployment containing the resources to be made avaliable to the component, because that's what J2EE dictates. But it's not the only possible way things could work. I'm having trouble wrapping my head around how resources should normally work in ServiceMix. Is there some place in jbi.xml or other standard JBI deployment information for, say, a service unit to declare that it needs resources like a JMS connection factory and destination? If not, how is ServiceMix/Geronimo supposed to know what resources to provide? Is there just an assumption that a global JNDI namespace will be present containing every resource in the server and each component can look up whatever it wants to? Thanks, Aaron On 4/4/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Thanks to dain and djencks advises, I have began to write a real > ServiceMix integration for Geronimo. > However I am facing a number of problems. > > The problem is that the JBI spec needs some things to be done when > undeploying jbi artifacts so I will be in need of an event fired before > undeployment (and not after as this is the current case). Let me > explain the use case for this. > The JBI container is a server (like a web server or EJB server): it > accepts three kind of deployment artifacts: component, shared libraries > and service assemblies. A shared library is a collection of jars to be > added to the classpath of a component. A component is also a container, > like a BPEL engine for example. A service assembly is a package > containing service units. These service units are given to a target > component upon deployment. A service unit could a BPEL process. > When deploying a BPEL process onto a BPEL engine, the engine may have to > store the process in a database at deployment time and remove the clean > the database when undeploying the service unit. The JBI spec has all > the needed interfaces to perform these deployment / undeployment steps. > The only problem is that I have not found any way to know when a > configuration is being undeployed. > Looking at the kernel, it seems it should be quite easy to do, so I > think I will raise a JIRA for that and attach a patch at a later time. > > The next problem, which is IMHO more important, is how to access managed > resources. In the previous BPEL engine example, the component has to > access a database. A JMS component would access a JMS connection > factory. These resources should be accessed via JNDI. I have browsed > the naming / deployer code these past days and AFAIK, there is no > server-wide JNDI context. When a web app is deployed, a specific JNDI > context is created (and bound to the thread with interceptors), that > includes all the bindings referenced in the web deployment descriptor. > This leads me to think that I have to create a geronimo-jbi.xml > deployment descriptor which will contain resource references and / or > additional gbeans for the configuration. > I fear this will lead to another problem, which is the fact that these > resources are usually deployed inside an EAR and JBI artifacts can not... > So the main questions is: did I miss something ? Is there any easier way > to access server-wide resources or do I really have to create a specific > deployment plan of some kind ? > > Cheers, > Guillaume Nodet > > >
