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: [core] why org.apache.geronimo.enterprise.deploy.provider package?
Date Tue, 19 Aug 2003 14:24:29 GMT
	I'm not convinced that all of JSR-88 should be hardcoded into
Geronimo core.  I'm not unwilling to consider it, I just don't see the
advantages.  Let me try to outline my thoughts on the matter.

 - I don't see why we must have only one application deployment system.  
That seems as modular as many other parts of the system to me.  
Personally, I think it would be a little odd to offer more than one CMP
engine, but that doesn't mean it shouldn't be modular.  In OpenEJB, we
actually had two (going on three) alternate deployment systems, and it
worked just as well as any other modular options.  It certainly make it
easy to work on a new one without crippling everyone else who needs a
working one.  It wasn't always clear to the layman why to pick one or the
other, but that's a documentation problem.

 - We do need some common notion of a deployment service, so that we can
ensure that the server always has one running.  I think the core could
define a required interface -- with methods like "deployPreconfiguredApps"  
and "startDirectoryScanner" and "deployThis(URL xAR)" or whatever we
decide is "core".  Then we can provide a default implementation, and leave
room for others.  That being the case, I don't see any advantage to
putting the default implementation in the "core" module (it would just
tempt us to hardwire things rather than touching them only through the
interface).

 - JSR-88 and deployment have a number of aspects.  Some of them need to
be packaged in separate JARs.  Some of them are GUI-related.  Many of them
will be completely hidden behind javax interfaces.  I disagree with
putting all of this in one Java package, and I thing some of it belongs 
in core and some of it doesn't.  Let me try to elaborate on the sections I 
see:

1) The set of Java objects that represent J2EE and Geronimo deployment
descriptors.  Probably generated off a schema/DTD by some XML tool.  
Currently I use Castor for the Geronimo EJB schema, but this can easily be
changed.  I think this is "core" to Geronimo.  I think it should have no
XML or GUI/events or other gobbledygook in the core objects.  Castor, as
configured, generated POJOs with separate descriptor classes to hold the
XML stuff and I'm fine with that, but if XMLBeans (or xmlbeans) does the
same, that's fine too.  I think anything involved in deployment should use
this same set of objects (the verifier, the deployer, JSR-88, etc.).

2) The things that actually deploys applications, that is, reads the DDs,
configures class loaders and containers, and generally turns something
from "file on disk" into "deployed application".  I waffle a bit on
whether this is "core", but I ultimately favor defining some interface
(MBean or whatever) in "core" and letting the implementation be elsewhere
(a deployer module or something, just like we'd have web modules and so
on).

3) The JSR-88 product provider hierarchy.  The product provider wraps the
Geronimo-specific deloyment descriptors in GUI-oriented JavaBeans for
configuration, as well as exposing actual deployment operations.  This is
code that runs within a tool (your IDE uses it to connect to the app
server just like a DB browser uses a JDBC driver to connect to a DB).  It
may or may not have some special server-side support -- the most basic
version could just invoke the deployer service through JMX or whatever,
but eventually we'll want more features (like the ability to load default
values for the user to select from when resolving security roles and
resource references and so on).  Unlike a JDBC driver, this implementation
has significant UI aspects.  Much of it is composed of JavaBeans, dealing
with property change events, providing custom AWT editors and customizers,
and so on.  Further, the tool will deal with it only indirectly -- by
instantiating a factory class (like the Class.forName step on a JDBC
driver), working with a bunch of JSR-88 interfaces, and introspecting
JavaBeans.  This code must be packaged in a JAR by itself (no JSR-88 API
classes, no server-side components, etc.), and the manifest for the JAR
requires special tags for the factory class and all the JavaBeans.  I feel
strongly that this is not "core" for Geronimo.  It does not have any
direct dependence on any other Geronimo classes except for the DD objects
(#1 -- it probably wants to read and write DDs) and the "remote interface"
for the deployer service (#2).  Nothing else depends on it, since it's
only used through interfaces and introspecting JavaBeans.  I don't see why
we wouldn't put this in a separate Java package, and probably in a module
other than "core".

4) The JSR-88 tool support hierarchy.  The product provider wraps the
Geronimo DDs in JavaBeans, and this package wraps the J2EE DDs in beans as
well.  The user interacts with the tool beans and product beans side by
side, and under the covers, they talk to each other via events.  So that
if you change an ejb-name, the Geronimo entry updates itself to use the
new ejb-name, and so on.  This is not required in order for 3rd party
tools to use Geronimo; it is required for Geronimo tools like an admin
console or command-line manager to use the JSR-88 configuration and
deployment interfaace.  It is not tied to any particular tool
implementation, though it will need to expose a number of hooks for
Geronimo tools to plug in to.  It does not have any direct dependent on
any other Geronimo classes except for the J2EE DD objects (#1).  It
accesses the #3 classes just like any other tool does, by providing a URL,
getting back a bunch of interfaces, and then introspecting JavaBeans.  
This must be be packaged in separate JARs from #3.  It doesn't seem like
it _needs_ to be in the "core", but since it's effectively a set of common
base classes for all deployment-related tools, it might make sense to put
it there.

5) The actual tools.  These can take advantage of the tool support classes
(#4) to save rewriting that code themselves.  However, they will probably
have custom code to deal with the introspected JavaBeans from #3.  For
example, a web tool would clearly need to generate a different UI than a
command-line tool.  AWT tools have some built-in support from JavaBeans,
but other tools use a text interface for editing the beans instead.  This
code should presumably be packaged with each tool.
	If we're ambitious, we can try to include more functionality in
#4, such as something that generates XML UIs with some sort of generator
that assembles a concrete UI of any particular style.  This seems like too
much work for the short term, but that's just me.

Aaron

On Mon, 18 Aug 2003, Dain Sundstrom wrote:
> On Monday, August 18, 2003, at 09:40 PM, Aaron Mulder wrote:
> I disagree.  We will only have one deployment system, and it will 
> support 88.  If what we have doesn't work with 88, we need to change it.
>
> > 	As for "provider", it's to distinguish it from the tool side,
> > which will be used for management consoles, etc. and from the objects
> > (generated by Castor into "common" in the pending patch) that represent
> > that actual J2EE component metadata (the object representation of the 
> > DDs,
> > in other words) and from the stuff (currently not implemented) that 
> > will
> > actually do the work of deployment on the server side.
> 
> I agree. We should have org.apache.geronimo.provider.  This all needs 
> to work like a seamless unit, and not a bolt on.  Having them in the 
> same package is just the first step.
> 
> > 	I think the provider stuff should remain separate from
> > "deployment"  because its only a JSR-88 implementation -- it's the GUI
> > logic (and potentially widgets) that a tool will use.  It's full of
> > JavaBeans (particularly if you look at the xxxBeanInfo classes in the
> > pending patch), and they all have to be packaged together and 
> > separately
> > from most everything else in order to be distributed to tools (the 
> > patch
> > also creates a JAR out of these classes, with a manifest full of bean
> > declarations and so on).
> 
> These are all fine to have in deployment.  For the actual tools, like a 
> deployment GUI, console or ant task those should go into a deployment 
> tools module. Now come to think of it, I think this stuff should go in 
> with the rest of our management tools.  Every type of management tool I 
> think of I also want a deployment tool.  I'm thinking of web, GUI, 
> console, and ant.
> 
> > 	Finally, if you repackage everything without looking at my patch
> > first, I'll...  I'll...  I'll send it a fourth time!  But if you are 
> > going
> > to repackage it, some of it probably ought to go in a different module,
> > not just a different package.
> 
> Agree.  I'm not going to repackage it without figuring out what works 
> best for all of us.  I'll look at you patch tomorrow morning.
> 
> -dain
> 
> /*************************
>   * Dain Sundstrom
>   * Partner
>   * Core Developers Network
>   *************************/
> 


Mime
View raw message