Rather than a specialized SubDirSubDeployer, how about having the SAR
report multiple watch-urls?

It may also be possible to have the SAR start its own
URLDeploymentScanner for its content rather than explicitly sub-deploy
it. This would support automatic redeployment of unpacked sar content
over the web as well; for the packed case, I think it would be easy to
have a URLLister that scans a jar: URL as well as the current file: and
http: ones.

Yes, you would need a real jboss-service.xml to start the nested
URLDeploymentScanner, but that would be mostly boilerplate if we made
the default scanned URL the SAR's root.


> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Sacha Labourey
> Sent: Wednesday, March 19, 2003 6:27 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] [PROPOSAL]: clean 
> conf/jboss-service.xml & deploy
> 
> 
> >   The thing I care about most is ease of configurability
> > (which, for the most part, I think we already have).  I like 
> > the idea that I can add or remove functionality by adding or 
> > removing "modules" from /deploy.  Much of the functionality 
> > of the server works this way (jmx-console, for example).  
> > There is, however, quite a bit of information in 
> > /conf/service.xml.  If this information could be refactored 
> > out to /deploy, I'd find that a much simpler situation.  At 
> > the moment, if I want to "pare down" jboss to some small 
> > feature set, I need to edit /conf/service.xml. That's not a 
> > big deal, but the less of that I need to do, the better 
> > (especially for automation).  
> 
> Yes, that is the problem: we should not have to modify this file.
> 
> >   Regarding #2, I find the current state of /deploy to be
> > highly intuitive, personally.  Would it be possible to make 
> > your scheme work by giving .sar's the ability to be nested?  
> > That way, /deploy/JMS.sar (a directory) could contain 
> > jms-foo.sar and jms-bar.sar.
> 
> That's already possible (russian dolls), but then:
>  - you need a fake META-INF/jboss-service.xml
>  - you cannot simply re-deploy one of the element in the 
> directory: you have to re-deploy the whole JMS thing
> 
> Cheers,
> 
> 
> sacha
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink? 
> You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
> What are you waiting for? 
> http://ads.sourceforge.net/cgi-> bin/redirect.pl?micr5043en
> 
> 
> _______________________________________________
> Jboss-development mailing list [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to