I am pretty busy this week (sorry for not yet having posted
information about how to trial Jetty clustering). However, I am happy
to give a shot at option #1 next week.
Thanks,
Gianny
On 10/01/2007, at 3:17 PM, David Jencks wrote:
I reversed this change and made it so the console can do jsr88, the
online deployer works ok, and there are no apparent tck problems,
and we don't need geronimo-deploy-config in lib. I think trunk and
1.2 are in sync with this code.
Does anyone think getting remote jsr88 working is a high priority
or want to work on it themselves?
thanks
david jencks
On Jan 9, 2007, at 6:16 PM, David Jencks wrote:
I'm going to start by disabling all the module configurers outside
the running server. If we support jsr88 dconfigbeans outside the
server, they need to be enabled in quite a different way than in
the server.
I agree that the jsr88 stuff should be in different jars than the
builder stuff, we've known this for a while but there hasn't been
much urgency.
If we're going to support jsr88 out of the server, we need to find
a way of registering the module configurers with the
DeploymentManager outside the server. Some possibilities, I don't
have a strong opinion on which is best. I'm very clear that all
the classes needed for this support need to be loaded out of the
g. repository, not lib.
- start up a kernel with a list of modules to start, and use that
to make the moduleConfigurers register.
- have a bunch of stuff in a manifest that says what jars are
needed and what moduleConfigurers to register
- have some other configuration file for this purpose.
I lean towards the first option, and think perhaps we should wait
until kernel bootstrapping is less reliant on lib. IIRC dain and
possibly other people have prototypes of how to have some kind of
bootstrap repository that needs only one or two jars in lib, the
rest coming from the repo.
Anyone think remote dconfigbeans are a pressing issue?
thanks
david jencks
On Jan 9, 2007, at 2:57 PM, Gianny Damour wrote:
Hi, this is the content of the email that I sent with the title
jsr88 - ModuleConfigurer - still some classpath problems.
The online deployer, e.g. deployer.jar, needs to have geronimo-
deploy-config along with all the modules providing an
implementation of this interface added as MANIFEST ClassPath
entries. It seems to me that to have the relevant geonimo-*-
builder is not so great: builders are executed server side and
actually install something on the server. It seems to me that
ModuleConfigurers are intended to be used disconnected from the
server during the configuration stage of modules. So, perhaps
that ModuleConfigurers should be move to their own module in
order to make that a little bit clearer. As you are working on
this David J., I would like to know if this makes sense or if you
have a better idea.
Thanks,
Gianny
On 09/01/2007, at 3:00 PM, David Jencks wrote:
On Jan 8, 2007, at 8:21 PM, [EMAIL PROTECTED] wrote:
Author: kevan
Date: Mon Jan 8 17:21:35 2007
New Revision: 494291
URL: http://svn.apache.org/viewvc?view=rev&rev=494291
Log:
Fix some deploy problems. geronimo-deploy-config needs to be in
lib.
What goes wrong if it isn't? I wondered if this would be a
problem.
New Configurers needed to be serializable...
what happens if they aren't? If we can't get away from this we
should make ModuleConfigurer extend Serializable...
I don't like adding more and more to lib..... if this is only
needed for jsr88 stuff I think we should consider starting up
something on request to load the configurer gbeas and register
them, using the repo.
thanks
david jencks
