Jim-- On this specific issue, I'd prefer a constructor that takes an InputStream as it's a more generalized solution than taking a URL. But, generally, why can't this just be captured in a specific assembler that knows the work that it needs to do? Why does it have to be driven by something that requires the caller to know the files to open and about InputStreams directly?
Eddie On 10/14/05, Jim Cummings <[EMAIL PROTECTED]> wrote: > I am doing some IDE-driven assembly work that requires reading the control > client manifest files (*.controls.properties) from various places, including > from the classpath. > > I then need to read these files and build the control/client mappings to > send to the standard Beehive assembly process. > > I'd like to use the ControlClientManifest class to do the simple parsing of > these files, but it does not have a constructor that takes an InputStream or > URL, which are my two choices when loading these files from a class loader. > > Anyone opposed to me adding an additional constructor to this that takes say > a URL? I'd be glad to open a JIRA issue and submit a patch if there are no > objections. > > Thanks - Jim. > >
