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 Mon, 21 Aug 2006 23:11:37 GMT

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 using URLs instead of files, is going to be very  
> difficult.  We had tons of problems dealing with paths containing  
> spaces and urls.  IIRC we had to encode and decode URLs all the  
> time.  Also, some deployers need to scan the directories.  For  
> example, the RAR deployer needs to add all jar files in the archive/ 
> directory to the class path.  In Jee5 ear files we need to scan for  
> all nested modules.
>
> I find the method name isBinary confusing.  Can we use something  
> like isArchived instead?

Certainly.

>
> -dain
>
> On Aug 21, 2006, at 1:16 PM, Sachin Patel wrote:
>
>> Doh, sorry, guess some javadoc would help :)... So basically the  
>> idea is to be able to represent a deployable object, that can be  
>> either a jar, or some custom structure specific to a given IDE/ 
>> build environemnt.
>>
>> public interface DeployableModule {
>> 	
>> 	/**
>> 	 * uri of the module, foo.ear, if a nested module then foo.ear/ 
>> foo.war
>> 	 */
>> 	String getURI();
>> 	
>> 	/**
>> 	 * root url of the module, if isBinary then would return absolute  
>> URL of the archive, otherwise
>> 	 * the root folder of the module.
>> 	 * @return
>> 	 */
>> 	URL getRoot();
>> 	
>> 	/**
>> 	 * returns all the URLs that provide content to this module  
>> (non .class files) if isBinary then this would return
>> 	 * empty array
>> 	 * @return
>> 	 */
>> 	URL[] getResourceFolders();
>> 	
>> 	/**
>> 	 * returns all the URLs that contai, if isBinary then this would  
>> return an empty array
>> 	 * @return
>> 	 */
>> 	URL[] getClassesFolders();
>>
>> 	/**
>> 	 * Returns true if this is a binary module (JarFile)
>> 	 */
>> 	boolean isBinary();
>> 	
>> 	/**
>> 	 * returns nested modules, so for an ear file, would return all  
>> its contained modules, for a web module, entries web-inf/lib entries
>> 	 */
>> 	DeployableModule[] getModules();
>> }
>>
>> On Aug 21, 2006, at 3:57 PM, Dain Sundstrom wrote:
>>
>>> Some java docs would help me understand what these methods are  
>>> supposed to do.
>>>
>>> -dain
>>>
>>> On Aug 21, 2006, at 10:53 AM, Sachin Patel wrote:
>>>
>>>> For the following JIRA, where all the module builders assume a  
>>>> jar file, what if we change all methods that take a JarFile to  
>>>> something like the following?
>>>>
>>>> public interface IDeployableModule {
>>>> 	
>>>> 	public String getURI();
>>>> 	
>>>> 	public File getRoot();
>>>>
>>>> 	public File[] getResourceFolders();
>>>>
>>>> 	public File[] getClassesFolders();
>>>>
>>>> 	public boolean isBinary();
>>>> 	
>>>> 	public IDeployableModule[] getChildModules();
>>>> }
>>>>
>>>> -sachin
>>>>
>>>>
>>>
>>
>>
>> -sachin
>>
>>
>


-sachin



Mime
View raw message