Thread: RE: [Springframework-developer] Creating reusable component packages with Spring

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

I see three levels of packaging here:

1. What you can already do is specify a config location like =
"classpath*:META-INF/beans.xml", which will load all beans.xml files =
from META-INF directories in all jar files found. Note that those will =
get loaded into the *same* context, though, i.e. into a single =
namespace. This is just a special way of loading bean definition files: =
The jar files are plain and simple, no custom class loaders involved, no =
special detection going on other than looking for certain resources in =
the existing class loader (for example, a web application's class =
loader). And this can be handled within an application (for example a =
WAR file): It does not need special support by the server.

2. For EJB-style deployment with naming references, things become =
harder. It might be appropriate to offer hooks for JNDI exposure here: A =
server like Geronimo could detect special jar files (maybe through the =
file extension), loading a local Spring application context for each jar =
and exposing certain facade beans from there in JNDI. The actual JNDI =
names could be specified at deployment time, like with EJB, putting the =
onus of namespace management on the deployer. Spring bean names are just =
used internally for the local context of each jar file; they do not =
share a common namespace. A web application can then have its own Spring =
root context with its own namespace, linking in the modules as JNDI =
objects. This should still be possible with plain jars, in principle, =
containing special descriptor files in the META-INF directory.

3. If additional libraries (that just apply to a specific module) can be =
contained in the deployment unit, we're crossing into different =
territory again. Essentially, this means having a separate class loader =
per deployment unit. We're beyond a plain jar file and simple namespace =
management here, coming close to an EJB jar or even an EAR file. This =
means we're also incurring the risk of issues like conflicts between =
different library versions etc, and the deployment hassle of respecting =
the different class loaders involved.

Option 1 is rather trivial, as it is essentially just a different flavor =
of loading bean definition files in an application - in all other =
respects, it's still typical Spring usage (in the current sense), for =
example using the existing class loader of a WAR. This will seamlessly =
work in any server.

If the namespace problem arises, option 2 becomes interesting: =
Individual jar files could then get deployed with special deployment =
descriptors (inside or outside the jar), mapping local bean names in the =
jar to global JNDI names - usually for facades of the module in that =
jar. This would already need special support by the server, though, but =
could still work as part of a WAR file. The web application could simply =
expect specific facades at specific JNDI names; the deployer is =
responsible for deploying the module jars accordingly.

Option 3 is essentially the equivalent of local stateless session bean =
deployment, requiring the modules to run in a different class loader =
than the WAR file. It seems to me that this is not typically needed in =
Spring scenarios: It might be sufficient to resort to local EJB =
deployment in such a case, with a Spring context backing the stateless =
sessions beans involved (through Spring's existing EJB support classes). =
Of course, it might still be worthwhile to offer such a full-blown =
deployment unit for plain Spring too. If not requiring module-specific =
library deployment, option 2 is available as a simpler alternative.

An interesting question is whether a variation of option 2 could be =
provided without JNDI: i.e. auto-loading one context per jar file, with =
the root application context directly linking in specific facades from =
there. However, how would one identify a specific facade in a specific =
jar file? In option 2 as outlined above, the deployer would do this for =
each jar file - for example, through including a special descriptor in =
the jar, mapping local bean names to global JNDI names.

For option 2 without JNDI, we'd need to have unique bean definition file =
names in the jar files, which can be clearly identified via the class =
loader. In that case, the root context could load the jar-specific =
contexts as beans, allowing to expose specific facades in those contexts =
as beans in the root context. Each jar-specific context would still have =
its own namespace; just specific beans would get linked into the root =
context under appropriate names. There would be no further relationship =
between the root context and the jar-specific contexts.

A remaining problem for option 2 is how to make specific beans from the =
root context visible to jar-specific contexts - linking in beans the =
other way round. I don't think that it is generally appropriate to load =
the jar-specific contexts as children of the root context; they should =
rather be considered as independent. In the case of a JDBC DataSource, =
one could resort to a shared JNDI location. But in the case of a =
Hibernate SessionFactory, there should be a way to make a local instance =
defined in the root context available to jar-specific contexts - with =
the option to link it in under a specific bean name.

Thoughts? Opinions?

Juergen

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jas...@ma...
Sent: Wednesday, November 10, 2004 9:43 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Creating reusable component
packages with Spring

Its an interesting question. Just one immediate thought; I can see=20
there being a need for a Spring deployment unit of some kind; e.g. a=20
jar containing an applicationContext.xml file in APP-INF/ or something=20
- maybe having any additional jars required inside the jar in=20
APP-INF/lib.

One there's a deployment unit we can add native support to Geronimo=20
(and other containers could support it too) plus we could support hot=20
deployment of units inside Spring natively rather than relying on the=20
J2EE deployment units (WAR / EAR / RAR)

If there was a deployment unit; the only real issue is how to handle=20
cross-deployment unit references; but we could always use JNDI / JMX=20
for that or use a hierarchy of BeanFactory instances.

On 9 Nov 2004, at 22:51, James Cook wrote:
> We have been developing a large enterprise application using Spring=20
> and it
> has proven to be a very effective framework. We use the Data access
> abstractions heavily, along with transaction management and Hibernate
> support.
>
> Now that we have most of the concepts down, some coworkers and myself=20
> are
> now considering the challenges inherent in packaging our business=20
> objects,
> service layers, spring configuration files, etc. into reusable=20
> component
> packages. We want to be able to give other developers in the company a =

> jar
> file that contains all of this content and simply drop it into their
> project.
>
> There are a lot of similarities (and differences) between what we face =

> and
> what EJB components deal with. EJB has solutions for mapping=20
> dependencies in
> a component package to the primary application (ejb-ref, etc.) and we=20
> are
> beginning to talk about how to accomplish similar behavior using=20
> Spring.
>
> Ultimately, there are probably many nuances to this process that we=20
> won't
> know until we actual do it, but I was wondering if the development=20
> team has
> some insight into some of the Spring features that already exist that=20
> can
> assist in some of these challenges? Perhaps also there are some=20
> features
> that are on the drawing board to assist in this matter also?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

James
-------
http://radio.weblogs.com/0112098/

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id=12065&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer