geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Adding new deployable module types
Date Sat, 10 Jun 2006 21:17:55 GMT

On Jun 10, 2006, at 1:16 PM, Stefan Arentz wrote:

> On 6/10/06, Aaron Mulder <> wrote:
>> Funny you should ask...  I'm writing a Wiki page on how to do this
>> with a plugin in Geronimo 1.1 as we speak.  The bottom line is that
>> you have to write a pretty hairy deployer class, but most of it is
>> relatively boilerplate code, just unpleasant boilerplate.  :)
> Interesting! Can you post a link to that page when it is available?
>> For purposes of the example I'm working on, this would be something
>> deployed separately from J2EE modules (e.g. you couldn't pack one in
>> an EAR).  I think we're still undecided as to whether you ought to be
>> able to pack non-J2EE modules into EARs, or whether we ought to have
>> some larger ZIP/JAR format that holds an EAR along with other modules
>> if you want to deploy them together, or something else entirely.   
>> What
>> do you think?
> Short term: simple deployable spring applications - I have a lot of
> applications that are just a bunch of Spring beans talking to JMS or
> Quartz for example. It would be really nice if I could just deploy
> those to Geronimo. These apps usually don't have a web interface and
> just turning them into a .war for bootstrapping the Spring context
> seems a bit lame.

You can do something  along these lines without a new deploy, just a  
new gbean that should be very easy to write.  The gbean will take the  
spring plan(s) and when the gbean starts deploy them to spring and  
when it stops undeploy them out of spring.  You have a choice of how  
to tell the gbean about the spring plan: either a reference to an  
external file or you can use an "xml-attribute" in which case you'd  
just insert the spring plan right into the geronimo plan.  I don't  
have a reasonable idea of which would be more convenient.

You then get to control your classloader using the geronimo  
environment element.

I think you'll want this gbean even if you write a whole deployer to  
accept custom plans of some kind.  So, I'd start with the gbean and  
see if the inconvenience of using it directly would be outweighed by  
the work of writing a deployer.

> Long term: What I'm interested in is building a 'Spring Application
> Server'. For me that would be a Geronimo instance that provides a
> certain base of functionality. For example: Spring 2.0, OpenJPA, a
> Transaction Manager, Quartz, ActiveMQ and Derby.
> Just making life easier for myself while building applications :-) It
> would be nice to be able to just pick the components that I like most
> and use them to build an app server environment for my own needs.
> I'm not very interested in following 'industry' specs/apis. I'm more
> interested in getting the job done with my favorite tools. Geronimo
> sounds like a good platform for that.
> I would even go so far as defining a new .ear style deployment unit to
> be able to bundle a bunch of web and spring apps. Oh and what I really
> like is to be able to deploy resources to automatically make database
> pools and JMS queues/topics.

There's the jencks project, but I don't think that's quite the right  
approach for running in geronimo :-).   I think what we need instead  
is more stuff like the spring transaction manager integration I wrote  
for what is now dead-1.2: I plan to migrate it to trunk/1.2 shortly.   
This exposes a geronimo resource (in this case the tm) in spring.   
Basically its a spring bean that contains gbean lookup info, so it  
can find the tm gbean, and it wraps that to fit the spring  
interfaces.  Are you looking for something that (roughly) does this  
for jdbc, jms, etc etc?  These should be easy to write.

Many of us are very interested in better Spring integration and would  
welcome any contributions and will try to help.

david jencks

> S.

View raw message