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


Reply via email to