[
http://issues.apache.org/jira/browse/GERONIMO-2324?page=comments#action_12432637
]
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: http://issues.apache.org/jira/browse/GERONIMO-2324
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
