geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: ServiceMix integration
Date Tue, 04 Apr 2006 14:08:21 GMT
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 <guillaume.nodet@worldonline.fr> 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
>
>
>

Mime
View raw message