geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Commented: (GERONIMO-2324) Allow in-place and exploded jar support for sharedlib
Date Tue, 05 Sep 2006 17:30:26 GMT
    [ ] 
David Jencks commented on GERONIMO-2324:

[ Show » ]
Sachin Patel [16/Aug/06 07:32 PM] Actually we need to re-open this for discussion. The dummy
jar won't solve the classes dir and modifying the config will require a server restart. I
don't think is reasonable.

- Can't we put a directory entry in manifest classpath in addition to actual jars?  This would
make modifying the classes attribute unnecessary
- If that doesn't work, the classes attribute can be changed while the server is running using
the kernel reflection methods, e.g. kernel.setAttribute(sharedLibGBeanName, "classes", newValue);
 This can be called remotely: see the jmx deployment stuff for an example of how.  When you
change an attribute through the kernel like this the new value gets saved in config.xml

Therefore I think that using a dummy jar is still quite workable.

[ Show » ]
Oleg Gusakov [01/Sep/06 03:53 PM] SharedLib might not be an ideal solution as David quite
reasonably indicated, but here is the use case:

    * I develop a WAR project under Eclipse
    * this project depends on 15 Eclipse JAR projects (just java code) I need to debug
    * this project depends on 500 JAR artifacts that are attached (in Eclipse) via either
Eclipse external jar or Maven plugin dependency
    * I need to debug my WAR under Geronimo
          o all my dependencies, both Eclipse project references and external JARs should
be available
          o if I change a java file in one of the referenced projects - it should be re-published
into Geronimo on the fly by the plugin
          o I may choose to convert one of those 500 dependency JARs into a full blown Eclipse
project so
                + plugin may have to drop that jar from Geronimo
                + redeploy it as an Eclipse project

Controlling all those jars and classes via Maven-like repository migh be a stretch - by definition
Maven repository hosts finalized artifacts that have passed unit tests.

(dj) -  Are you really planning to work with code outside an open eclipse project that doesn't
pass _unit_ tests? Maven repositories can certainly contain SNAPSHOT -versioned jars which
I think of as being typically the compiled version of whatever code is on your machine currently.
 Maybe the impedance mismatch we're having is that I have a hard time remembering developing
without maven and you don't use it :-)

 I, on the contrary, am trying to quickly manupulate half-baked code that really belongs to
IDE, not even a JAR file. So SharedLib seems to be a logical candidate. Or some other GBean
that would allow easy classloading changes, especially given the fact that all manipulations
originate not from a user but from a plugin that is fairly well tested Another consideration
- visibility of the published classes. It does not matter that much for development deployments.
But even here - I can envision rather complex applications desiring to limit the visibility
of their artifacts. This leads to another idea - there should a way to specify where this
"SharedDevLib" classloaders attaches - server-wide, particular EAR or, even WAR.

First, you can already attach shared-lib classloaders wherever you want.  We just provide
one that acts sort of like the tomcat shared/lib but you are free to create as many configurations
containing one or more shared-lib gbeans and include these configurations as parents/dependencies
of whatever app you want.

However, if you are wanting to create complicated classloader structures I think that shared
lib is an inappropriate tool and you should think harder about putting the jars into the maven
repo structure (they can all be under e.g. com.myco.bigproject or you can separate them more)
and using explicit dependencies in your geronimo plans.  This might be painful in the short
term but I suspect it would clarify and document the exact dependencies between the jars.

At this point I think we are trying to cram too much into the existing repository and shared
lib implementations.  I think its becoming clearer that the needs of a development environment
may not be appropriate to support in a production server.  However, there are a lot of possible
solutions: here are a couple of suggestions:

1. Geronimo can support any number of simultaneous repository gbeans.  If you were willing
to use explicit dependencies instead of shared-lib, we could write a repository implementation
that pointed into the eclipse workspace(s) and used the eclipse-compiled classes in situ.
 Presumably it would be possible to make it look first in eclipse for "opened" projects and
then in some other location for jars that are not currently opened as eclipse projects.  I
think this is the cleanest solution: when a jar or project changes, you just need to restart
the configuration that actually uses it, and the new version will be picked up from this repository
without having to restart some shared-lib configuration that contains it.  When you're ready
to move to production, you just put the final jars in the normal g repo and leave out the
configuration with the eclipse-aware repo gbean.

2. We can write an eclipse-aware shared lib gbean that includes all projects open in eclipse
(loaded first) and then all jars in some directory.  We put this gbean in a suitably-versioned
configuration that replaces the shared-lib configuration.  When this config is installed,
the server will basically run off of eclipse: when the normal shared-lib config is installed
it will run off of the normal shared/lib dir.

> Allow in-place and exploded jar support for sharedlib
> -----------------------------------------------------
>                 Key: GERONIMO-2324
>                 URL:
>             Project: Geronimo
>          Issue Type: RTC
>      Security Level: public(Regular issues) 
>          Components: deployment
>    Affects Versions: 1.1
>            Reporter: Sachin Patel
>         Assigned To: Sachin Patel
>             Fix For: 1.x
>         Attachments: GERONIMO-2324.patch, GERONIMO-2324.patch
> The shared library support should allow in-place support to allow and load jars (exploded
as well) that are located externally on the filesystem.  This is needed to improve developer
experience and allow better integration within tooling and the runtime.
> Perhaps we can have a properties file insie the shared lib that have external entries
in them.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message