geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: GERONIMO-1526
Date Wed, 23 Aug 2006 17:39:10 GMT
So I've started to make these changes, but it looks like we may have  
to use URL's in the interface, unless anyone else has any other  
suggestions due to the problems dain mentioned with using URLs.   
Taking the EARConfigBuilder for example... ideally I'd like to push  
out the code that traverses through the zip entries and let the  
DeployableModule.getResources() handle this so the builders only have  
do deal with the interface and not a specific implementation such as  
a jar/zip file.

Any alternative suggestions? Or for now would it be acceptable to  
keep in the builders the processing of ZipFiles and simply have if/ 
else statements all over the place?

On Aug 22, 2006, at 8:14 AM, Sachin Patel wrote:

> Ok thanks for the clarification.
>
> On Aug 21, 2006, at 8:13 PM, Dain Sundstrom wrote:
>
>> On Aug 21, 2006, at 4:11 PM, Sachin Patel wrote:
>>
>>>
>>> On Aug 21, 2006, at 4:31 PM, Dain Sundstrom wrote:
>>>
>>>> Thanks.  I have a few questions/issues...
>>>>
>>>> Why the separation between resources and classes.  Don't we need  
>>>> to add both to the class loader anyway?  I'm curious when this  
>>>> differentiation is important.
>>>
>>> Ok, This is where I value your input.  There could be definitely  
>>> a distinction from a tools perspective, as the java output folder  
>>> could only contain .class files and not resources and metadata.   
>>> From a server runtime perspective I wasn't 100% sure as Looking  
>>> at AbstractWebModuleBuilder.installModule(...), resources are  
>>> added to the module context either via addFile(), addInclude()  
>>> and addToClasspath().  So I assume addFile() and addInclude()  
>>> also adds these to the classloader?  If there does not need to be  
>>> a separation then yes, we can combine both methods.
>>
>> I think I see the disconnect.  When I hear the word resources, I  
>> think of additional non-class files available via the class  
>> loader, but they all end up in the class loader bucket.  In the  
>> case of a web application, we have two buckets: the class loader  
>> and the web app context.  The former is the same for all modules,  
>> and the latter contains files that are accessible via http.
>>
>> If that is the case, I think we need to keep the separation, but  
>> I'm not sure "resource" is the best name given the level of  
>> confusion we have already seen.
>>
>> -dain
>>
>>
>
>
> -sachin
>
>


-sachin



Mime
View raw message