I'm still plugging away on my change, albeit much slower than I'd like.
Navigating the APIs and various technologies in play has not been as
straightforward as I'd hope, given all the irons I have in the fire. At any
rate, I think I have a handle on what classes I'll need and how the process
will work. To make sure I'm moving in the right direction, as I plan to
start coding as soon as I send this, here is my plan. After some thought
and great input from Tim, I think I'm going to go with approach #1 above
(create a ReadableArchive implementation to "wrap" the resource file).
Having said that:
- I will create a *ReadableArchive *implementation, e.g., *
ResourceReadableArchive*
- I will create an *ArchiveHandler *implementation, *
ResourceArchiveHandler*, for the *ResourceReadableArchive*
- I will create a *Sniffer *that will recognize and claim the
*ResourceReadableArchive
*for the container
Here, then, is how I see things playing out in DeployCommand.execute():
- In *line 165*, the archiveFactory will find the RRA for the resource
file (via the ReadableArchive @Contract)
- In *line 173*, the ArchiveHandler will be retrieved
- If no name is supplied, the default application name acquired in *line
181 *will be based on the name of the resource file (e.g., foo-ds.xml
will be foo)
- *Line 187 *gives me pause, as I'm not sure yet how to handle
redeployment. The answer, though, will likely be very similar to the
undeploy code, and will likely be achieved by copying the resource file to
the .deployed (?) file, and using its contents to determine what resources
to un/redeploy.
- In *line 205*, ResourceArchiveHandler.expand() will simply copy the
resource file to the expansion directory.
- In *line 206*, ResourceArchiveHandler.close() will be a no-op
- The ClassLoader code in *lines 224-228 *has me a little concerned, as
I've not done any real ClassLoader work (beyond bumbling through figuring
out which CL to grab to load resources :), so we'll have to see what happens
when this block executes.
- The call to ApplicationLifecyle.deploy() in *line 262* likewise may
give me heartburn, as I've not yet had a chance to really read the code,
but, as they say, I'll cross that bridge when we get there. :P
I think that covers the basics, though much is left to determine/verify. If
I can get it to that point, I'll feel much better about the quickly looming
deadline.
I do have a question regarding *where* this code should lie. I haven't
successfully determined which container handles the JDBC resources. My guess
is that this is where my new classes should live. Unless told otherwise,
I'll try to determine where that container is and work there.
Hong, Tim, you've been identified as the experts in this area, so I'm
emailing you directly to make sure you see this. Tim, the usual cavets,
exceptions apply for you. :)
I'm going to start coding now while I await input. :)
Thanks!
--
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