OK, you saw my last email ( in the "JSR/SAR (Jetty) Undeployment..." thread)
right?

Well then expanding a little, this is what I had envisioned...

> -----Original Message-----
> From: marc fleury [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 10:23 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] RH, Jetty, Service Archives...
> 
> 
> |> 3. Can I include jars in it (I tried top level dir and 
> META-INF/lib -
> |> no joy) - how ?
> |>
> |
> |You can't currently include jars, you should be able to in 
> my opinion, but
> |currently you can't.
> 
> TODO
> 
> |Whichever you think is best.  I personally think there 
> should be room for a
> |directory structure in a sar that gets expanded when it is 
> deployed.  This
> 
> yes TODO
> 
> |There would be issues with redeployment but
> |they shouldn't be hard to resolve.
> 
> Can you expand on how you would solve the redeployment issues 
> on directory
> structures in SARs.
> 
> In fact I need the following
> 1- how would you package it? where?
> 2- how would you specify it? needed?
> 3- what happens on redeploy.

1- keep it simple.  in a sar you can have a directory called "root" in the
META-INF dir, everything that is in this directory is copied exactly to
${jboss.system.deployed}\sarname\root

I think we then add a method to ServiceMBeanSupport that looks up this
directory, this way it can be set by the ServiceDeployer if the mbean being
deployed extends ServiceMBeanSupport (or implements the ServiceMBean
interface) and is easy for clients to find.

All the jars in the sar are also copied to ${jboss.system.deployed}\sarname
to avoid the file sharing violations that prevent the user from simply
moving the original file to undeploy.  This is under the assumption that all
required classes are now in jars, I guess we can copy plain class files too,
but jars would be neater I reckon.

2- not sure what you mean?  the above paragraph maybe.

3- I think (again going for simple) that when the sar is redeployed nothing
from the directory structure is overwritten, but the jars are.  This way any
persistent data in the directory structure is kept and any configuration
files the user wants to update manually can be updated in the expanded
directory structure and when the sar is redeployed the new configuration
will take effect.  If the user wants the files from the sar to be copied
over all they have to do is delete the ones in the deployed directory before
they redeploy their app.

I think this will pretty much allow us to do we want to do.

> 
> As usual when designing features don't go for "full design in 
> the future" go
> for "simple and right now" you will be surprised about the 
> staying power of
> "simple and right now"
> 

This is something I am begining to learn the hard way.   *wry grin*


> |Cheers
> |
> |David
> 
> David, if you have some time try to pitch in there, if not 
> let me know I
> believe I will try to work on some stuff over the next few 
> days.  I need to
> take care of the marketing of JBoss but I want to code some of the rh
> advanced features (jmx bus stuff)...
> 

I am away all from work all next week, so I won't be able to do anything and
when I get back chances are I will have a stack of stuff to catch up on etc,
so its not really looking good.  I do have time today to look at some simple
stuff.  In fact I think I can come up with a simple dependency mechanism for
the AutoDeployer which will clean up a lot of those issues by handling it
all in one place.  That will just leave the service deployer changes to do.

If people don't mind leaving it a couple of weeks I might be able to get
back to it.

That's the best I can do at the moment, my priorities have to be keeping on
top of any reported bugs in JBossMQ and our developments at work.

David.

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

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

Reply via email to