You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Lyytinen Joonas <jo...@cons.sonera.com> on 2003/08/08 08:44:34 UTC
One True Way (TM) of handling configuration files
Hi,
One thing that has annoyed me in several app-servers (e.g. Weblogic and =
JBoss) is the
way the server specific configuration XML files located in the =
WARs/JARs/EARs of the
"pure" J2EE application. This hinders application portability and is =
generally messy.
My syggeestion is that in geronimo we should adopt a similar approach =
than the Orion
application server (http://www.orionserver.com), where the =
implementation specific=20
files with some default values are generated into a separate directory =
structure
by the application server when a application is deployed on the server.=20
IMHO this has several advantages.
everyone in favor say ay! :)
-joonas=20
RE: One True Way (TM) of handling configuration files
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 8 Aug 2003, Jeremy Boynes wrote:
> And all of this runs into issues with JSR88 (Deployment) which requires that
> the container exposes JavaBeans for manipulating the deployment config
> (including the vendor specific part) and uses an API for deployment (rather
> than the copy-the-archive-in model typically used today).
I think JSR-88 can be made to work in most any case. The API can
update the original EAR, write out a new DD (XML or otherwise) and send it
to the server, serialize a bunch of objects, call methods on the server,
etc. It's supposed to expose a "deployment plan" to the tool, but that
can be in any form.
Aaron
Re: One True Way (TM) of handling configuration files
Posted by Craig Wohlfeil <cr...@darklighter.com>.
I think this is a good idea. One thing that sys admin people that I work
with like about WebSphere 4 is the centralized config repository that
can be managed from any machine in the cluster. There is no need for a
special admin server. This could make clustering easier. No need to
replicate configuration. What happens if the config server is down?
> Ideally, the server should just be able to start w/o any forms of
> configuration, and then for the rest of the configuration to be managed
> dynamically. My preference, esp. for distributed clusters, would be to
> use some kind of central repository config that elements interacted
> with, and for that to be backed by some kind of DB. That way, the DB can
> be replicated across multiple machines, edited synchronously and minor
> changes won't need huge restarts.
Re: One True Way (TM) of handling configuration files
Posted by Alex Blewitt <Al...@ioshq.com>.
> I would rather see a parallel directory structure that would contain
> overrides for information in
> those descriptors, i.e.
>
> /overrides/myapp.ear/application.xml
>
> Would override the application.xml inside
>
> /deploy/myapp.ear
Why not make it part of the installation process? Does it really need
to be specified in an associated file? For example, deploy myapp.ear
with myapp.xml overrides.
I don't think that necessarily different directories may be the answer;
just write out the overriden state into the same place with a different
extension, such as myapp.geronimo.
> Or something along these lines. Perhaps that data is in a database,
> or comes from multiple sources,
> or is managed by a GUI. The point is, leave the original artifacts
> (EARs, WARs, JARs) alone, and
> augment them from the outside.
Totally agree with this one.
Alex.
RE: One True Way (TM) of handling configuration files
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I've never liked the vision of unpacking an EAR (and the WARs and EJBs within) to fiddle with
deployment descriptors. That's the kind of thing that mandates some kind of GUI tool to be
workable, since you'll tie your fingers in knots unpacking, editting and repacking all that.
I would rather see a parallel directory structure that would contain overrides for information in
those descriptors, i.e.
/overrides/myapp.ear/application.xml
Would override the application.xml inside
/deploy/myapp.ear
Or something along these lines. Perhaps that data is in a database, or comes from multiple sources,
or is managed by a GUI. The point is, leave the original artifacts (EARs, WARs, JARs) alone, and
augment them from the outside.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
> -----Original Message-----
> From: Erin Mulder [mailto:meara@alumni.princeton.edu]
> Sent: Friday, August 08, 2003 2:11 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: One True Way (TM) of handling configuration files
>
>
> Alex Blewitt wrote:
> > > From an administrator's PoV, it would be nicer if all
> configuration
> > > could be done via an admin console, and for the repository to be
> > > stored in a not-necessarily-human-readable form which was
> updated as
> > > the config was changed via the admin console (e.g. Web app)
>
> Robert Responded
> > While this may be a matter of some personal preference, I
> tend to like
> > config files over an admin cosole/webapp. Being able to
> > administer/maintain via a command line is imporant to me.
>
> I am all in favor of a good admin console, but everything
> should still be accessible through XML config files and the
> command line.
>
> One of the most common complaints about Websphere (4.x at
> least) is the way it obfuscates all the configuration files.
> GUI tools are great for
> administration of shared servers, but not for development.
> I want a good
> record of any configuration changes I make and an easy,
> legible way to share them with other developers (see the
> "User Friendliness" thread).
>
> Erin
>
Re: One True Way (TM) of handling configuration files
Posted by Pranni <pr...@hotmail.com>.
> > Alex Blewitt wrote:
> >>> From an administrator's PoV, it would be nicer if all configuration
> >>> could be done via an admin console, and for the repository to be
> >>> stored
> >>> in a not-necessarily-human-readable form which was updated as the
> >>> config
> >>> was changed via the admin console (e.g. Web app)
> >
> I think this makes an excellent point:
> o GUI tools are better for administrators
> o Developers like files
Its not that developers like files, sometimes, for developers, files are the
only way to change the configuration. In my company we have to deploy and
test our application on a remote weblogic server, for which we have only a
secure shell access(due to firewall reasons) . We do have the luxury of
accessing configuration thru the admin console and modifying the config.xml
is the only way we can change the server's configuration. So providing the
configurations in a human-readable form would definitly needed in similar
situations and a normal (xml?) text file will be a better option for that.
-Prakash
Re: One True Way (TM) of handling configuration files
Posted by Alex Blewitt <Al...@ioshq.com>.
On Friday, Aug 8, 2003, at 19:11 Europe/London, Erin Mulder wrote:
> Alex Blewitt wrote:
>>> From an administrator's PoV, it would be nicer if all configuration
>>> could be done via an admin console, and for the repository to be
>>> stored
>>> in a not-necessarily-human-readable form which was updated as the
>>> config
>>> was changed via the admin console (e.g. Web app)
>
> Robert Responded
>> While this may be a matter of some personal preference, I tend to like
>> config files over an admin cosole/webapp. Being able to
>> administer/maintain via a command line is imporant to me.
>
> I am all in favor of a good admin console, but everything should still
> be
> accessible through XML config files and the command line.
Why should everything be accessible through XML config files? You state
that it must be so without really saying why it would be good.
Certainly, being able to upload/download an XML representation of the
config may be desirable (for compatibility/backup/global changes) --
but that doesn't mean that everything needs to be stored as one single
(or multiple) XML documents.
Similarly, command line tools can still be used, regardless of what the
config is stored in. It's just a case of providing the necessary
interface to it.
But hey -- why not use GUI admin? You could even have an Admin plug-in
in Eclipse (for example).
> One of the most common complaints about Websphere (4.x at least) is
> the way
> it obfuscates all the configuration files. GUI tools are great for
> administration of shared servers, but not for development. I want a
> good
> record of any configuration changes I make and an easy, legible way to
> share
> them with other developers (see the "User Friendliness" thread).
I think this makes an excellent point:
o GUI tools are better for administrators
o Developers like files
Which are we developing ApacheJ2EE for? My notion was that a red-hot
J2EE server that would be easy to administrate.
Developers may be able to use a different viewpoint, esp. because
there's usually just one of them per machine. But let's also consider
the runtime management as well.
Note that the suggestion of using a JNDI server to store all config is
compatible with both, because the JNDI server could be backed by an XML
file (for example).
Alex.
Re: One True Way (TM) of handling configuration files
Posted by Erin Mulder <me...@alumni.princeton.edu>.
Alex Blewitt wrote:
> > From an administrator's PoV, it would be nicer if all configuration
> > could be done via an admin console, and for the repository to be stored
> > in a not-necessarily-human-readable form which was updated as the config
> > was changed via the admin console (e.g. Web app)
Robert Responded
> While this may be a matter of some personal preference, I tend to like
> config files over an admin cosole/webapp. Being able to
> administer/maintain via a command line is imporant to me.
I am all in favor of a good admin console, but everything should still be
accessible through XML config files and the command line.
One of the most common complaints about Websphere (4.x at least) is the way
it obfuscates all the configuration files. GUI tools are great for
administration of shared servers, but not for development. I want a good
record of any configuration changes I make and an easy, legible way to share
them with other developers (see the "User Friendliness" thread).
Erin
Re: One True Way (TM) of handling configuration files
Posted by "Robert \"kebernet\" Cooper" <ke...@kebernet.net>.
Alex Blewitt wrote:
> Yes, but what about simple changes? Would you have to bounce an app to
> update it to use a new DB/PW, for example? What would happen to users
> that were logged into that app (i.e. had HttpSession state) whilst you
> bounced it? I've had conversations with administrators who complained
> with some early J2EE servers that the only way of picking up some
> changes was to bounce the app, which logged all the users off. Not great
> for trivial changes.
>
> These are the sort of things I hope we can avoid, regardless of what
> kind of back-end-configuration-repository is used.
>
> Alex.
I guess the line there goes to what you consider to be the app. We did
have a breakpoint on some items that meant restarting the app, but most
things we just looked at changes between the current running config and
the new config submission and restarted those services (the DB
Connection Pools, in your example). However, all of those issues are
not really confined to an aguement about file-based config so much as
how you implement the ability to make changes to running services in the
code. Gracefully reconfiguring RDBMS pools within our configuration
service, for example, wasn't a trivial thing to implement.
I'm not sure I see the multiple administrators working on the same app
as being a huge issue, though. I can't say as I have ever encountered a
situation where that was a problem. I would be curious, though, what you
are calling trivial changes. In most environments I have been in,
anything that wasn't something like changing pool and cache sizes on a
live server would be something attached to a new build/deploy cycle
anyway, which would require at least application downtime or dropped
user sessions.
Re: One True Way (TM) of handling configuration files
Posted by Alex Blewitt <Al...@ioshq.com>.
>> From an administrator's PoV, it would be nicer if all configuration
>> could be done via an admin console, and for the repository to be
>> stored in a not-necessarily-human-readable form which was updated as
>> the config was changed via the admin console (e.g. Web app)
>
> While this may be a matter of some personal preference, I tend to like
> config files over an admin cosole/webapp. Being able to
> administer/maintain via a command line is imporant to me.
I'm not sure that the two are incompatible. You can configure a
repository-based system using command-line tools as well; just ones
that are provided for you rather than vi/sed/whatever.
>> The big problems with XML files as I see them are:
>> o How would an XML file be treated if the server had to re-generate
>> its config file (because administrator(s) made a remote change )?
>> o How would changes that a text editor made to an XML file be re-read
>> by a config file?
>
> When I was working on a wireless app server a couple of years ago, we
> always maintained application state via and XML file. Basically all
> our admin cosole was was a fancy way to retrieve the XML file the
> server/cluster was currently using, edit it, and push it back. We also
> had a command line utility that let you edit the XML files, then force
> the server to restart the application with the new config. It worked
> pretty well. We just persisted everything back to the filesystem on
> the servers when there was a change, and downed/re-inited the relevant
> systems in the application.
That's pretty much the problem with XML-based files; that's the /only/
way to do it, and it generates some ugliness. For one, it means that
you have to be very careful when multiple administrators are using the
file (and/or editing it on disk) at the same time. Not an issue for
small systems where there's only one administrator (or developer), but
across a system with multiple administrators these deficiencies may be
magnified.
Thus, I propose that you can make a much better admin console (and
command line tools to support batch changes) but without the
file-backed system.
>> o Would you need to restart the server and/or dump the new config
>> file to see the effect?
>
> I should hope not. :) The system should be able to down/restart an app
> without the whole server bouncing.
Yes, but what about simple changes? Would you have to bounce an app to
update it to use a new DB/PW, for example? What would happen to users
that were logged into that app (i.e. had HttpSession state) whilst you
bounced it? I've had conversations with administrators who complained
with some early J2EE servers that the only way of picking up some
changes was to bounce the app, which logged all the users off. Not
great for trivial changes.
These are the sort of things I hope we can avoid, regardless of what
kind of back-end-configuration-repository is used.
Alex.
Re: One True Way (TM) of handling configuration files
Posted by "Robert \"kebernet\" Cooper" <ke...@kebernet.net>.
Newbie poster...
Alex Blewitt wrote:
> From an administrator's PoV, it would be nicer if all configuration
> could be done via an admin console, and for the repository to be stored
> in a not-necessarily-human-readable form which was updated as the config
> was changed via the admin console (e.g. Web app)
While this may be a matter of some personal preference, I tend to like
config files over an admin cosole/webapp. Being able to
administer/maintain via a command line is imporant to me.
> The big problems with XML files as I see them are:
>
> o How would an XML file be treated if the server had to re-generate its
> config file (because administrator(s) made a remote change )?
> o How would changes that a text editor made to an XML file be re-read by
> a config file?
When I was working on a wireless app server a couple of years ago, we
always maintained application state via and XML file. Basically all our
admin cosole was was a fancy way to retrieve the XML file the
server/cluster was currently using, edit it, and push it back. We also
had a command line utility that let you edit the XML files, then force
the server to restart the application with the new config. It worked
pretty well. We just persisted everything back to the filesystem on the
servers when there was a change, and downed/re-inited the relevant
systems in the application.
> o Would you need to restart the server and/or dump the new config file
> to see the effect?
I should hope not. :) The system should be able to down/restart an app
without the whole server bouncing.
> Alex.
--c
Re: One True Way (TM) of handling configuration files
Posted by Alex Blewitt <Al...@ioshq.com>.
> On deployment, the running configuration would be determined by:
> 1) the configuration in the repository
> 2) the configuration in the deployment unit
> 3) per-server defaults[1]
> 4) per-domain defaults[1]
I think a big question which has to be answered before picking up these
changes is: how is the configuration repository going to work? IMHO
storing a single config file in an XML file may result in a file easier
for humans to read (and, for that matter, servers to process) but
/really/ breaks down when you've got to manage changes. Even simple
things like installing a new app can be a big headache when the config
file is a file.
From an administrator's PoV, it would be nicer if all configuration
could be done via an admin console, and for the repository to be stored
in a not-necessarily-human-readable form which was updated as the
config was changed via the admin console (e.g. Web app)
The big problems with XML files as I see them are:
o How would an XML file be treated if the server had to re-generate its
config file (because administrator(s) made a remote change )?
o How would changes that a text editor made to an XML file be re-read
by a config file?
o Would you need to restart the server and/or dump the new config file
to see the effect?
Ideally, the server should just be able to start w/o any forms of
configuration, and then for the rest of the configuration to be managed
dynamically. My preference, esp. for distributed clusters, would be to
use some kind of central repository config that elements interacted
with, and for that to be backed by some kind of DB. That way, the DB
can be replicated across multiple machines, edited synchronously and
minor changes won't need huge restarts.
Of course, the config may be seeded by/extracted as an XML document,
but I don't think that necessarily having the config stored as an XML
file is necessarily the right way to go.
Alex.
RE: One True Way (TM) of handling configuration files
Posted by Jeremy Boynes <je...@coredevelopers.net>.
None of these solutions seem to meet all the requirements.
In-archive files are a pita, triply so when the archive is packed.
Out-of-archive files are a pita when you are trying to move an application
through the release process (dev->integrate->test->stage->prod)
One-config-file (a la server.xml) is a pita when you have hundreds of
applications to deploy.
And all of this runs into issues with JSR88 (Deployment) which requires that
the container exposes JavaBeans for manipulating the deployment config
(including the vendor specific part) and uses an API for deployment (rather
than the copy-the-archive-in model typically used today).
JBoss took a two prong approach with its ServiceArchives (SARs) where you
could deploy a .sar archive with embedded metadata
(META-INF/jboss-service.xml) or a standalone metadata file (my-service.xml).
However, one problem not solved to date is of persisting changes to the
configuration so they survive server restarts.
One idea being thrown around was for an external config repository where
runtime changes could be stored - this could be XML files, or could be
plugged to be anything such as a config management system or database.
On deployment, the running configuration would be determined by:
1) the configuration in the repository
2) the configuration in the deployment unit
3) per-server defaults[1]
4) per-domain defaults[1]
Changes an admin made would be stored in the repository. If the deployment
unit was replaced whilst the system was offline, then conflicts would be
need to be resolved before the unit could be started.
Jeremy
[1] see JSR 77 for meaning of server and domain
> -----Original Message-----
> From: Igor Lobanov [mailto:cryozot@mail.ru]
> Sent: Friday, August 08, 2003 3:21 AM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: One True Way (TM) of handling configuration files
>
>
> Hi Christian and fellow geromimos,
>
> Friday, August 8, 2003, 2:02:38 PM, you wrote:
>
> > On Fri, Aug 08, 2003 at 09:44:34AM +0300, Lyytinen Joonas wrote:
> >> Hi,
> >>
> >> One thing that has annoyed me in several app-servers (e.g.
> Weblogic and JBoss) is the
> >> way the server specific configuration XML files located in the
> WARs/JARs/EARs of the
> >> "pure" J2EE application. This hinders application portability
> and is generally messy.
> >>
> >> My syggeestion is that in geronimo we should adopt a similar
> approach than the Orion
> >> application server (http://www.orionserver.com), where the
> implementation specific
> >> files with some default values are generated into a separate
> directory structure
> >> by the application server when a application is deployed on
> the server.
> >> IMHO this has several advantages.
> >>
> >> everyone in favor say ay! :)
>
> > hi Lyytinen,
>
> > 1+ for a separate config file, and i think it
> > shoult be only one file (something like Tomcats's server.xml)
>
> +1 for separate config files
> -1 for only one config file
>
> It will be pretty much complicated to deploy applications "on hot",
> because deployer component has to open that "applications.xml", add some
> elements and then save it back. On the other hand, if there is
> whole separate configuration directory structure, deployment becomes very
> simple process. You just need to extract your EAR/WAR/JAR to
> applications directory and add one file to corresponding configuration
> folder. Just like Tomcat 5.
>
> Igor Lobanov
>
>
Re: One True Way (TM) of handling configuration files
Posted by Igor Lobanov <cr...@mail.ru>.
Hi Christian and fellow geromimos,
Friday, August 8, 2003, 2:02:38 PM, you wrote:
> On Fri, Aug 08, 2003 at 09:44:34AM +0300, Lyytinen Joonas wrote:
>> Hi,
>>
>> One thing that has annoyed me in several app-servers (e.g. Weblogic and JBoss) is the
>> way the server specific configuration XML files located in the WARs/JARs/EARs of the
>> "pure" J2EE application. This hinders application portability and is generally messy.
>>
>> My syggeestion is that in geronimo we should adopt a similar approach than the Orion
>> application server (http://www.orionserver.com), where the implementation specific
>> files with some default values are generated into a separate directory structure
>> by the application server when a application is deployed on the server.
>> IMHO this has several advantages.
>>
>> everyone in favor say ay! :)
> hi Lyytinen,
> 1+ for a separate config file, and i think it
> shoult be only one file (something like Tomcats's server.xml)
+1 for separate config files
-1 for only one config file
It will be pretty much complicated to deploy applications "on hot",
because deployer component has to open that "applications.xml", add some
elements and then save it back. On the other hand, if there is
whole separate configuration directory structure, deployment becomes very
simple process. You just need to extract your EAR/WAR/JAR to
applications directory and add one file to corresponding configuration
folder. Just like Tomcat 5.
Igor Lobanov
Re: One True Way (TM) of handling configuration files
Posted by Emmanuel Bernard <ep...@yahoo.fr>.
How do you deploy your app in Orion ? In a 2-step way
:
* deploy ear
* deploy specific config file ?
Emmanuel
--- Christian Trutz <ch...@smilebase.org> a écrit : >
On Fri, Aug 08, 2003 at 09:44:34AM +0300, Lyytinen
> Joonas wrote:
> > Hi,
> >
> > One thing that has annoyed me in several
> app-servers (e.g. Weblogic and JBoss) is the
> > way the server specific configuration XML files
> located in the WARs/JARs/EARs of the
> > "pure" J2EE application. This hinders application
> portability and is generally messy.
> >
> > My syggeestion is that in geronimo we should adopt
> a similar approach than the Orion
> > application server (http://www.orionserver.com),
> where the implementation specific
> > files with some default values are generated into
> a separate directory structure
> > by the application server when a application is
> deployed on the server.
> > IMHO this has several advantages.
> >
> > everyone in favor say ay! :)
>
> hi Lyytinen,
>
> 1+ for a separate config file, and i think it
> shoult be only one file (something like Tomcats's
> server.xml)
>
> chris
>
> >
> > -joonas
> >
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: One True Way (TM) of handling configuration files
Posted by Christian Trutz <ch...@smilebase.org>.
On Fri, Aug 08, 2003 at 09:44:34AM +0300, Lyytinen Joonas wrote:
> Hi,
>
> One thing that has annoyed me in several app-servers (e.g. Weblogic and JBoss) is the
> way the server specific configuration XML files located in the WARs/JARs/EARs of the
> "pure" J2EE application. This hinders application portability and is generally messy.
>
> My syggeestion is that in geronimo we should adopt a similar approach than the Orion
> application server (http://www.orionserver.com), where the implementation specific
> files with some default values are generated into a separate directory structure
> by the application server when a application is deployed on the server.
> IMHO this has several advantages.
>
> everyone in favor say ay! :)
hi Lyytinen,
1+ for a separate config file, and i think it
shoult be only one file (something like Tomcats's server.xml)
chris
>
> -joonas
>
Re: One True Way (TM) of handling configuration files
Posted by Gareth Bryan <ga...@fastmail.fm>.
Definately a +1 on this.
Orion's model is an excellent one and I'm convinced it's one we should
follow.
Any deployment tools we build (web interface / swing gui) can prompt for
values to be stored in these "geronimo-web.xml etc files (if necessary)
On Fri, 8 Aug 2003 09:44:34 +0300, "Lyytinen Joonas"
<jo...@cons.sonera.com> said:
> Hi,
>
> One thing that has annoyed me in several app-servers (e.g. Weblogic and =
> JBoss) is the
> way the server specific configuration XML files located in the =
> WARs/JARs/EARs of the
> "pure" J2EE application. This hinders application portability and is =
> generally messy.
>
> My syggeestion is that in geronimo we should adopt a similar approach =
> than the Orion
> application server (http://www.orionserver.com), where the =
> implementation specific=20
> files with some default values are generated into a separate directory =
> structure
> by the application server when a application is deployed on the
> server.=20
> IMHO this has several advantages.
>
> everyone in favor say ay! :)
>
> -joonas=20
--
Gareth Bryan
garethbryan@fastmail.fm
--
http://www.fastmail.fm - Access all of your messages and folders
wherever you are
Re: Project Goals
Posted by Christian Trutz <ch...@smilebase.org>.
On Fri, Aug 08, 2003 at 08:53:32AM +0200, Emmanuel Bernard wrote:
> Way to do it
> ============
> Using Maven as developement process tool
1+
> Full Unit Testing coverage (JUnit)
1+
>
> Geronimo is JMX based vs Geronimo has a JMX interface
> (?)
> Solution proposed:
> * JMX core of the modular J2EE stack (initial
> contributors approch to stay focused)
> * Avalon core of the modular J2EE stack
> * HiveMind core of the modular J2EE stack
> * Home grown Micro kernel core of the modular J2EE
> stack
> * EJB central piece of Geronimo ??
i think the best solution is: begin from scratch! i mean
ideas (patterns) like IoC (Avalon) should be implemented
but the kernel should not depend on other piece of
software. I mean the kernel of course use things like
Digester and so on but it should not BE another
piece of software.
i think the problem is: if for exemple Avalon changed,
the geronimo kernel changed automaticaly or is a branch
of avalon, a avalon-geronimo-branch.
I am a fan of Avalon! But i think geronimo should be a
alternative to avalon! I think geronimo will be the
big brother of avalon, but also a alternative!
>
> Persistence layer use spec front end (EJB, JDO)
> delegating to a runtime chosen persistence manager
> coordinating plugins actions (caching, locking,
> versioning). Reuse approche for persistence manager
> impl : OJB, Hibernate, ...
>
> Geronimo has one and only one EJB Container, but the
> implementationof the EJB container should differ (?)
> Issue: relation between Geronimo core and EJB
> container.
>
> Think about classloading strategy, and think again.
>
> Use Aspect or not (?)
> Use Aspect or not for the first geronimo steps (?)
> Develop home grown aspect framework or use an existing
> one (?)
>
> Reflexion vs/and (bytecode) generate code discussion
>
> JNDI impl shared with Tomcat (jakarta commons) (?)
>
> Docs, docs, docs... especially on architecture vision
>
> Emmanuel
>
> ___________________________________________________________
> Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
> Yahoo! Mail : http://fr.mail.yahoo.com
Re: Project Goals
Posted by Emmanuel Bernard <ep...@yahoo.fr>.
Aaron and geronimos,
Here is a summarize that might help for #1 and #2
point. I did it from the geronimo-dev mailing list.
I put an (?) when no consensus or no real discussion
occurs on the subject. This *does not mean* othe
subject has been widely approved (formerly or not).
Feel to update. I choose not to add it on the Wiki but
putting this material on it seems to be a good idea
after some mail iterations on it.
Goals (from the proposal)
=====
Create a J2EE 1.4 (?) certified container available
under ASF license.
J2EE specs has been listed on the Wiki
Create a fully modular J2EE stack so that the Apache
community can use whichever parts of the J2EE stack
they require separate from the J2EE server project.
Reusing the best ASF/BSD licensed code available today
and adding new code to complete the J2EE stack.
Way to do it
============
Using Maven as developement process tool
Using Gump and Maven
Full Unit Testing coverage (JUnit)
Geronimo is JMX based vs Geronimo has a JMX interface
(?)
Solution proposed:
* JMX core of the modular J2EE stack (initial
contributors approch to stay focused)
* Avalon core of the modular J2EE stack
* HiveMind core of the modular J2EE stack
* Home grown Micro kernel core of the modular J2EE
stack
* EJB central piece of Geronimo ??
Persistence layer use spec front end (EJB, JDO)
delegating to a runtime chosen persistence manager
coordinating plugins actions (caching, locking,
versioning). Reuse approche for persistence manager
impl : OJB, Hibernate, ...
Geronimo has one and only one EJB Container, but the
implementationof the EJB container should differ (?)
Issue: relation between Geronimo core and EJB
container.
Think about classloading strategy, and think again.
Use Aspect or not (?)
Use Aspect or not for the first geronimo steps (?)
Develop home grown aspect framework or use an existing
one (?)
Reflexion vs/and (bytecode) generate code discussion
JNDI impl shared with Tomcat (jakarta commons) (?)
Docs, docs, docs... especially on architecture vision
Emmanuel
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com