admin@glassfish.java.net

Re: clustering design spec

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Wed, 17 Mar 2010 11:25:20 -0700

Timothy Quinn wrote on 03/17/2010 08:48 AM:
> Some questions and comments...
>
> The text under the bullet "Initiation of the synchronization request" -
> I guess it's pasted from another document - refers to processing files
> in the order specified in Step 1. I didn't see step 1 or an equivalent
> list of file processing order.

Right, that section is obsolete. I'll remove it.

> In the communication transport layer section, there's a question raised
> about putting the zipped returned files into the action report. Why
> would we put it in the report? The already-existing payload classes and
> interfaces - which the deploy command uses for uploading archives to be
> deployed and which deploy and get-client-stubs use for downloading
> client files - should work fine for this. The returned files would go
> into the payload of the admin command's HTTP response (in compressed
> form) but the report would remain as a report. The logic already in the
> payload implementation would extract the compressed files from the
> payload and store them in the right places in the instance's directories.

Ok, good. This is just me not understanding well enough how the
ActionReport mechanism works and how I would use it to return files.
I knew the capability had to be there somewhere, but I wasn't sure how
easy it would be to reuse it for this purpose.

> The "Synchronization Issues/lib directory" talks about users adding JARs
> to an app's lib directory updating the lib directory but rewriting JARs
> not doing so. Are we saying that we would support users operating
> directly on the lib directory in the DAS-owned application directory:
> that is ${appsDir}/${appName}/lib? If so, it seems arbitrary to limit
> it to just that directory. If, on the the other hand, we're talking
> about a developer updating a JAR and rebuilding the app and then
> redeploying, the redeployment logic would touch the top-level app
> directory, right? So why would we need to treat the lib directory
> specially? What have I missed?

I'm not talking about the lib directory that's under an application.
I'm talking about the lib directory that's under the domain directory,
e.g., domains/domain1/lib.