geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: context.xml gbeans
Date Mon, 23 Jan 2006 23:35:49 GMT

On Jan 23, 2006, at 2:49 PM, Sachin Patel wrote:

> Thanks for your input David.  So is there support today to plugin  
> additional config-stores and repositories? I didn't think there was.

I think Toby Cabot has geronimo running with multiple config stores  
and repositories.  The packaging and assembly plugins use local-maven- 
repo based repository and config store implmementations.

One thing I completely don't understand :-) is how you are going to  
get a  classloader in geronimo to reload a class.  At the moment this  
requires stopping and (re)starting the configuration involved.   
Although this certainly doesn't involve redeploying the app, it is  
still somewhat non-trivial.  Do you have a faster way?

thanks
david jencks

>
> - sachin
>
>
>
> On Jan 23, 2006, at 5:35 PM, David Jencks wrote:
>
>>
>> On Jan 23, 2006, at 2:13 PM, Sachin Patel wrote:
>>
>>> I think I have found my hook at least for (Tomcat) to load all  
>>> resources from Eclipse.  I will need to implement a classloader  
>>> that extends org.apache.catalina.loader.WebappLoader to handle  
>>> the WTP project structure.  From a pure tomcat perspective a  
>>> Loader entry for each web app can be provided in the context.xml  
>>> file.  Many of the attributes in server.xml are provided as  
>>> gbeans in the tomcat plan, but their doesn't seem to be anything  
>>> for elements in the context.xml.
>>>
>>> Is provding a gbean for the loader element the correct hook into  
>>> geronimo to provide this support?  If so, could someone advise me  
>>> on how best to continue from a geronimo perspective?  This would  
>>> be really cool we could get this working even if it were just for  
>>> web projects using the tomcat distro.
>>>
>> I'm afraid I haven't followed what you are proposing very closely,  
>> but I would expect the most portable way to do something like this  
>> would be to implement an eclipse-aware config-store and  
>> repository.    I thought we were preventing tomcat from building  
>> any classloaders by supplying our own.
>>
>> thanks
>> david jencks
>>
>>
>>> - sachin
>>>
>>>
>>>
>>
>


Mime
View raw message