Hi, Jason
I will try to answer some of the questions (I haven't followed up on
this thread closely).
> 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*
>
This sounds ok. But if we use the second option you mentioned before
(creating a jar), we could possibly re-use the existing InputJarArchive
and JarHandler code.
>
> * 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.
>
The code in DeployCommand to handle redeployment is just to call
UndeployCommand first. So as long as we can make sure the
UndeployCommand can undeploy the resources properly, the code in
DeployCommand to handle redeployment for other archives could be used to
handle the resource archive as well.
>
> * 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
>
You would need to write a ResourceDeployer to handle the lifecycle of
the resources.
In v2, there used to be a ResourcesMBean which can be used to
create/delete resources. I am not sure what's the equivalent of that in
v3. Your ResourceDeployer should be just calling the equivalent of this
ResourcesMBean to create/delete resources.
I have Cced Jagadish in this thread. He is the owner of the resource
backend. He should be able to help you on this.
The ResourceDeployer will be invoked (through Sniffer/ContainerInfo) in
ApplicationLifecycle to do the deployment/undeployment of the resources.
>
> 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.
Jadagish should be able to point you to the right directories for this.
Thanks,
- Hong
> 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