On May 27, 2008, at 7:00 AM, Jason Lee wrote:
> More progress to note, and an API conundrum. I've chased down all
> the moving parts, I think, and here's my understanding of things.
> The Autodeployer currently finds all of the archives in the
> autodeploy directory, and gets a list of all the Sniffers running in
> the system. The Autodeployer then creates a ReadableArchive Object
> from the File representing the archive, and passes that to each
> Sniffer's handles() method.
>
> Armed with that knowledge, I see a problem: an XML is not an
> archive. To solve that, I see a few solutions. The first is to
> create a new ReadableArchive type that clones the semantics of the
> ReadableArchive, but does some trickery to make it work with/on an
> XML file. I don't really like this, as it makes the semantics of
> the interface lie. :)
>
> The second option is to create a JAR file on the fly, then use that
> in the same manner that other archives are. This might not be a bad
> approach, as that would allow for the single file use case, but also
> allow us to support a jar of xml files in the cases where a group of
> resources might need to be deployed. I think, though, the second
> use case there might be better served by multiple entries in the XML
> file, though that may just be a style choice.
>
> The third approach I see is to change the Sniffer API to take a
> File, and, perhaps, leave it up to the individual Sniffers to create
> the ReadableArchives where appropriate. The downside to this, of
> course, is that it touches a fair amount of code, and, given my
> deadline on this, would take longer to implement. :) If that's the
> approach deemed most appropriate, though, I'd rather do The Right
> Thing.
this would be very difficult because that means the each Sniffer would
have to create it's own ReadableArchive and eventually its own class
loader for its ReadableArchive instance. I think it would make sharing
of loaded classes between sniffer inexistent with a long list of
potential problems associated with it and that would also be a big
performance regression.
My take would be to take option 2.
Jerome
>
>
> So...any thoughts/direction on this? I'm hesitant to start on any
> one direction until I get something akin to an official position, as
> I'm in no position to make that call. :)
>
> Thanks for the feedback! :)
>
> On Fri, May 16, 2008 at 3:50 PM, Jason Lee <jason_at_steeplesoft.com>
> wrote:
> Alrighty. I think that I have the autdeployer fixed up so that it
> doesn't reject non-archive files. I have test-ds.xml and
> mojarra-scales-demo.war in autodeploy/. The war is deployed, and the
> xml file is ignored, as no sniffer claims it (I'm guessing :). I just
> need to see how (and where) the war is handled to figure out how to
> proceed. Once I get the system picking up the XML file, I can then
> work with the relevant GF engineers to work out an appropriate file
> format.
>
> Can someone point me in the right direction WRT to the sniffer? I've
> done some grepping for strings that might be relevant, but I'm not
> coming up with much. If anyone is interested, I can post a diff
> showing the changes I've made. They're not pretty at the moment, but
> I'll focus on making it pretty when everyone is happy with how things
> work. :P
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com
>
>
>
> --
> Jason Lee, SCJP
> Software Architect -- Objectstream, Inc.
> Mojarra and Mojarra Scales Dev Team
> https://mojarra.dev.java.net
> https://scales.dev.java.net
> http://blogs.steeplesoft.com