Hi,

I have the ServiceDeployer working to my satisfaction with classpath
dependencies, depends tag dependencies (both for deploy and undeploy), and
a primitive version of the local directory copied out of the sar, and I
plan to check this in soon.

Right now the local directory feature works like this:

you include in you jboss-service.xml file one or more elements

<local-directory path="mylocaldir"/>

any jarEntry starting with the path is copied to the db directory (with the
"path" removed from the path).  If it is already there, it is not
overwritten.  No attempt is made to remove anything on undeploy.

Now there are at least two problems with this.

1. How does your program find its local directory?  I don't want to bind
anything in jndi, since jndi may not be started when these local
directories are copied.  I think it's time for the JBossFilesSystemRoot
mbean which anyone can use to find the jboss local directory structure. 
I'm thinking this would be the first mbean loaded, and could be used by
everyone else to find where stuff is.  For instance, log4j can find its
config files, the ServiceDeployer can find where to put local directories,
and your app can find where to look for its local directory.  Is this OK
with everyone?

2.  Name collisions.  Right now, I just copy the directory as is, with no
attempt to put it in a unique subdirectory.  I think we should keep this
simple scheme until someone complains loudly because they have an actual
problem.  Unless we include the entire URL of the sar in the path name for
the local directory, we would need a URL to unique name map that persisted
even when the sar was undeployed.  Does anyone have a problem with leaving
this simple and relying on users to specify different local directory
names?

Thanks
david jencks

_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to