Re: GERONIMO-1526

[Sachin Patel]

Right, I understand the concerns about using URLs.  The point I was trying to make was there isn't a nice clean way to do this.  Or at least I couldn't think of a way.  The builders won't be able to purely rely on the DeployableModule interface for resolving and processing a module wether its a JarFile or an exploded IDE specific filestructure. So since URLs are not an option we can't represent paths inside jars or paths in a directory in a common way.  So inside our builders, taking a more simpler ConnectorBuilder for example... the following piece of code cannot be pushed out into a call in the DeployableModule interface...  Enumeration entries = moduleFile.entries();             while (entries.hasMoreElements()) {                 ZipEntry entry = (ZipEntry) entries.nextElement();                 URI target = targetURI.resolve(entry.getName());                 if (entry.getName().endsWith(".jar")) {                     earContext.addInclude(target, moduleFile, entry);                 } else {                     earContext.addFile(target, moduleFile, entry);                 }             } and in all the module builders where this type of traversing is done, we will have to have something like... if(deployableModule.isArchived()) { JarFile moduleFile = new JarFile(deployableModule.getRoot()); //then do code above } else { File[] = deployableModule.getResources() //moduleFile being an impl of DeployableModule //traverse through each file entry and do similar to above to add to earContext. } rather then be able to use getResources() on the deployableModule regardless of wether its an archive or something else.  Hope that helps. So if this is acceptable, I can proceed.     On Aug 23, 2006, at 3:39 PM, Jacek Laskowski wrote: On 8/23/06, Sachin Patel <[EMAIL PROTECTED]> wrote: 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. I like your proposal especially after a few days looking at OpenEJB code and wire an annotation support in. I'm wondering how OpenEJB could use it once it's introduced in Geronimo? Besides, I don't understand the above comment of yours above. Since Dain has already stated his concerns about File vs URL why do you need more to come? I think I didn't fully follow the note about zip files handling. Would you mind to elaborate a bit? Jacek --  Jacek Laskowski http://www.laskowski.net.pl -sachin