Done re-factoring specs...

[Jason Dillon <ja...@coredevelopers.net>]

I am finished with the re-factor of specifications.  After running into 
a problem with the reactor with a specs module under modules/ (and lots 
of thought about where to put these babies... and a few beers) I 
decided to create a peer to modules.

The motivation behind this was to keep the build system simple, with a 
flat (okay mostly flat) module structure, but also to allow the specs 
to have separate maven project directories and not muck up the 
namespace under modules.

I really wanted to keep these separate, and not just drop them into a 
single catch-all module, so we can release these puppies separately, 
provide separate site docs and so on.  Basically I was thinking along 
the lines that specs is like commons for enterprise specifications, and 
such they are meta-modules and can and should be kept in a separate 
module structure.

Note however that the build system will aggregate modules/* and specs/* 
and it just thinks of them all as modules, not spec-modules and 
modules, blah, blah, blah.

The site documentation generation still needs to be hooked up to 
include specs.  I think we should make sure that we group the docs for 
modules and specifications in the resulting site for geronimo.  I will 
have a look to see how todo this, but I am not really that familiar 
with mavens xdocs... so I may need some help.

* * *

I have also fixed the run target to function correctly with the reactor 
build.

I would like to eventually have the top-level project collect module 
outputs into target/* such that it will create the directory structure 
of a release.  Once that works the run target will just work off of the 
aggregated module results.

Okay, enough from me for now, have a beer to finish.

--jason

Re: [JNDI] un-volunteering

[Robert Stupp <sn...@gmx.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I'd like to join the JNDI subproject.

But I think, an LDAP server isn't the right place to store the JNDI
environment in. Application servers have a global namespace and
namespaces for each J2EE container (web, ejb, client app, etc.). A JNDI
implementation for an application server has to be fast and fail-safe.

Fail-safe means: It must not be closed after being used - LDAP
javax.naming.Context objects have to be closed. Just consider code
samples found in the net like this:
javax.transaction.UserTransaction userTx =
~    (javax.transaction.UserTransaction) new InitialContext().
~    lookup("java:comp/UserTransaction");

Fast means: Lookups on the InitialContext are performed very often in a
J2EE application and even inside the application server.

Objects stored in an application server's namespace are either static
(environment specified during deployment) or dynamic (EJB home objects,
JDBC data source, JMS factories, etc.).

These "dynamic" objects are the complicated part, which cannot be easily
stored in an LDAP server - they are "functional" objects, which must be
serializable, manageable and they have to be notified upon deployment,
undeployment, container startup/shutdown.

When you think about a J2EE client application, it becomes very
complicated, because you have to "wrap" for example the JDBC data source
in the application server using a "shadow" data source object in the
J2EE client application's VM.

Considering the clustering/load-balancing/fail-over stuff, it would be
much easier to have a single clustered/fail-safe repository for
information, which has to be persistent.

Richard Monson-Haefel wrote:
| I removed myself from the list of volunteers for the JNDI subproject. I'm
| really interested in this and the LDAPd integration, but I don't want to
| spread myself too thin. I'm going to focus on Web Services support and MDB
| container system -- those subprojects should keep me pretty busy.
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/PJsFKk+yu2LQ72QRAu3LAKCdcQ9+joB+sGLVcqsBmYKI3QXGswCfYFYS
rHJMs493J81SzQ8UMITNaAs=
=9geN
-----END PGP SIGNATURE-----

[JNDI] un-volunteering

[Richard Monson-Haefel <Ri...@Monson-Haefel.com>]

I removed myself from the list of volunteers for the JNDI subproject. I'm
really interested in this and the LDAPd integration, but I don't want to
spread myself too thin. I'm going to focus on Web Services support and MDB
container system -- those subprojects should keep me pretty busy.


-- 
Richard Monson-Haefel
Co-Founder\Developer, Apache Geronimo
Author of:
  J2EE Web Services (AW 2003)
  Enterprise JavaBeans, 4ed (O'Reilly 2004)
  Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com