geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: svn commit: r494291 - in /geronimo/server/branches/1.2: assemblies/geronimo-boilerplate-minimal/ modules/geronimo-client-builder/src/main/java/org/apache/geronimo/client/builder/jsr88/ modules/geronimo-connector-builder/src/main/java/org/apache/geronim...
Date Wed, 10 Jan 2007 09:14:18 GMT
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, kevan@apache.org 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
>>>>
>>>>
>>>>
>>>
>>
>


Mime
View raw message