RE: Barracuda: Request for Change: The Assembly Descriptor

Hi Kirk,

I've modified the DefaultApplicationAssembler and since you are the only 
one that I *know* uses multiple assembly files, I'd like it if you could 
test it.  I just re configured things a bit and I plan to do some 
more.  However, I'd like to check in this version before I move to 
implement the ServletContext#getResourcePaths() implementation, but I want 
to make sure that my changes don't break your apps.  I'm attaching the 
latest version in a zip file.

Jake

At 11:55 AM 11/1/2002 +0200, you wrote:
>Hi Jake,
>
>Nope.... Haven't had a chance... :(
>I thought I had a 'mini break' here at work... but then... I ended up 
>being even more swamped with work than usual.
>It's heading towards deadline time..... so hopefully I'll take a look at 
>this when it's all over.
>
>The cool thing about the Application Assembly is that it's pluggable...
>In otherwords we can create a 'loader' for both the 2.2 and 2.3 spec.
>
>Hmmm.......
>
>Regards
>KD
>-----Original Message-----
>From: Jacob Kjome [mailto:[email protected]]
>Sent: 01/November/2002 08:09
>To: [email protected]
>Subject: RE: Barracuda: Request for Change: The Assembly Descriptor
>
>
>Hi Kirk,
>
>Have you gotten any further on this?  Have you found a way to load 
>resources based on a partial match?
>
>I may have found a solution, but I haven't investigated it much.  You 
>might be able to use:
>
>ServletContext#getResourcePaths(String)
>
>http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletContext.html#getResourcePaths(java.lang.String)
>
>It seems like that ought to be able to return a list of files matching a 
>partial name.  So, if you name your files in a standard way, this should 
>be able to return the list of filenames that are to be used for 
>configuration in the assembly descriptor.
>
>I'll let you investigate this, but It looks promising.
>
>One thing to note.  This method didn't exist until servlet-2.3.  So, if we 
>do use this method, we truly make Barracuda require a servlet-2.3 
>compatible container such as Tomcat-4.x.x.  I have no problem with this, 
>but it should be discussed.  I already added a servlet-2.3 specific piece 
>of functionality when I created the Log4jApplicationWatch class which is a 
>servlet context listener.  However, that is only enabled if it is defined 
>with a <listener> element in the web.xml.  So, that didn't really marry us 
>to servlet-2.3.  Using this new method definitely would.  Just wanted to 
>make that clear.
>
>later,
>
>Jake
>
>At 03:54 PM 10/14/2002 +0200, you wrote:
>>Thanx Jacob,
>>
>>A much 'cleaner' solution....
>>Will definately get around to this sometime today or tommorrow morning.
>>
>>KD
>>-----Original Message-----
>>From: Jacob Kjome [mailto:[email protected]]
>>Sent: 14/October/2002 03:43
>>To: [email protected]
>>Subject: RE: Barracuda: Request for Change: The Assembly Descriptor
>>
>>Hi Kirk,
>>All you need to do is something like this....
>>String newConfigPath = configPath.replace('\', File.separatorChar);
>>newConfigPath = configPath.replace('/', File.separatorChar);
>>This will guarantee on both systems that the path separator will 
>>appropriate.  I think I actually skipped the first check in Log4jInit and 
>>only did the second one.  That guarantees it to work properly on Windows, 
>>but not necessarily UNIX if someone used "\" in the Log4jInit 
>>configuration.  Doing the above will work for both cases.  Then, if you 
>>ever need to use a file separator again, just when concatenating strings, 
>>just use "File.separator".
>>Either way, File IO is just not portable in a servlet app.  These files 
>>need to be loaded via streams.  I haven't put a lot of thought yet into 
>>the problem at hand, but if I get time today, I'll try to take a stab at 
>>a portable solution.  In the meantime, if you can do some research on 
>>this, that would be great.
>>
>>Jake
>>
>>
>>
>>
>>At 12:14 PM 10/14/2002 +0200, you wrote:
>>>Hi Jacob,
>>>Yes... this is the one niggle I wasn't too particularly pleased with...
>>>I will take a look at Log4jInit.java during the course of the day....
>>>I certainly hope I can get around all that messy code dealing the either 
>>>the "\" or "/"...
>>>Sheesh!! %)
>>>Makes me dizzy just thinking about it...
>>>Regards
>>>KD
>>>-----Original Message-----
>>>From: Jacob Kjome [mailto:[email protected]]
>>>Sent: 14/October/2002 08:04
>>>To: [email protected]
>>>Subject: RE: Barracuda: Request for Change: The Assembly Descriptor
>>>
>>>PROBLEMS:
>>> > The one little niggle I don't particularly like is the fact that I 
>>> had to
>>> > resort to
>>> > looking for a file seperator when dealing with the path to the physical
>>> > file.
>>> > If anyone can think of a better way......please let me know.
>>>Are physical file paths being used here?  Bad, bad, bad!!!!  Use the 
>>>classloader to find resources and load the file in as a stream.  You 
>>>can't guarantee that your webapp will be deployed from a directory.  It 
>>>*can* be run directly out of a .war file.  If so, there will be no 
>>>physical file paths to the files at all.
>>>Look at Log4jInit.java to see how I dealt with this.
>>>I don't have time tonight to look at the code, but if we are counting on 
>>>the fact that we are able to get to a file within a webapp (or anywhere 
>>>else, for that matter) via a physical file path then we need to change 
>>>that pronto.
>>>Jake
>>>At 05:47 PM 10/13/2002 -0400, you wrote:
>>>>Ok Kirk,
>>>>I've gone through your patch and applied it (see attached). I'd like 
>>>>you to
>>>>try it on your local system and make sure it still works for you. Note 
>>>>that
>>>>I made some fairly sweeping code rearrangements, by taking
>>>>AssemblerXmlReader and moving it back into DefaultApplicationAssembler 
>>>>as an
>>>>inner class (since its not used anywhere outside the application 
>>>>assembler).
>>>>Also note that I reformatted things a bit - specifically, I removed all 
>>>>tabs
>>>>(replacing them with 4 spaces), I indented on 4 spaces, rather than 2, 
>>>>and I
>>>>initialized all variables (you had some uninitialized vars, and this is
>>>>generally bad practice).
>>>>SO...please test this out. It appears to be working on my box, but I'd 
>>>>like
>>>>to get your verification before I actually check it back in.
>>>>Thanks very much for contributing this code! You've done a great job. 
>>>>Sorry
>>>>its taken me so long to actually get around to putting it into place.
>>>>Christian
>>>>----------------------------------------------
>>>>Christian Cryder [[email protected]]
>>>>Internet Architect, ATMReports.com
>>>>Barracuda - http://barracuda.enhydra.org
>>>>----------------------------------------------
>>>>"Coffee? I could quit anytime, just not today"
>>>>
>>>>
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: [email protected] 
>>>> [mailto:[email protected]]On
>>>> > Behalf Of Kirk Daries
>>>> > Sent: Friday, September 06, 2002 11:43 AM
>>>> > To: [email protected]
>>>> > Subject: RE: Barracuda: Request for Change: The Assembly Descriptor
>>>> >
>>>> >
>>>> > Hi,
>>>> >
>>>> > OK... I've managed to get it working here at work.
>>>> > I'm definately not a java guru.... so there's bound to be things
>>>> > I could have done better.
>>>> >
>>>> > This is the first time I'm actually submiting code back..
>>>> > sooooo..
>>>> > If I crash your machine...
>>>> > "It wasn't me!" [Thanx Shaggy!] :D
>>>> > -==-==--==-==--==-==--==-==--==-==-
>>>> > GETTING STARTED:
>>>> > To test it out... just compile and plonk the classes down in your
>>>> > WEB-INF/classes/org/enhydra/barracuda/core/event directory.
>>>> >
>>>> > Edit your web.xml and change the 'ApplicationAssebler' to
>>>> > org.enhydra.barracuda.core.event.MyDefaultApplicationAssembler
>>>> >
>>>> > You can then change the 'AssemblyDescriptor' and specify wildcard file
>>>> > names.
>>>> > E.g 'assembly_descriptor*.xml'
>>>> >
>>>> > The Assembler SHOULD then asseble all files matching your criteria.
>>>> >
>>>> > -==-==--==-==--==-==--==-==--==-==-
>>>> > WHAT I'VE CHANGED:
>>>> > I've changed the 'structure' of the DefaultAssebler quite a bit
>>>> > because the
>>>> > 'reader' had to be called muliple times depending on the number of 
>>>> files
>>>> > found
>>>> > matching the wildcard search
>>>> >
>>>> > I've created a file called AssemblerXmlReader which contains the core
>>>> > info on how to asseble the events and listeners from a xml file.
>>>> >
>>>> > -==-==--==-==--==-==--==-==--==-==-
>>>> > PROBLEMS:
>>>> > The one little niggle I don't particularly like is the fact that I 
>>>> had to
>>>> > resort to
>>>> > looking for a file seperator when dealing with the path to the physical
>>>> > file.
>>>> > If anyone can think of a better way......please let me know.
>>>> > -==-==--==-==--==-==--==-==--==-==-
>>>> > WHAT STILL NEEDS TO BE DONE:
>>>> > Better wild card support. At the moment... the code just assumes a 
>>>> partial
>>>> > file name...
>>>> > E.g. xyz*.ext
>>>> >
>>>> > Another thing I realised it that there needs to be a mechanism to link
>>>> > listeners to a 'NAMED'
>>>> > EventGateway.
>>>> >
>>>> > E.g.
>>>> > assembly_descriptor_1.xml
>>>> > --'Gateway1'    <-Named
>>>> > ----Listener1
>>>> > ----Listener2
>>>> >
>>>> > --'Gateway2'    <-Named
>>>> > ----Listener3
>>>> > ----Listener4
>>>> >
>>>> > assembly_descriptor_2.xml
>>>> > --'Gateway1'
>>>> > ----Listener5
>>>> > ----Listener6
>>>> >
>>>> >
>>>> > Notice that Listener5 and 6 are in a seperate file.. but need to
>>>> > be added to
>>>> > 'Gateway1'.
>>>> > Hmmm.... something to think about.
>>>> >
>>>> > Regards
>>>> > KD
>>>> >
>>>> > Ps.
>>>> > Comments VERY welcome.
>>>> >
>>>> >