Max Andersen [
http://community.jboss.org/people/max.andersen%40jboss.com] created the
discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/570942#570942
--------------------------------------------------------------
Re: the remotable API to upload individual files w/in a deployment, let's discuss
next week and then I'll open a JIRA.>
> Re: Windows jar locking with exploded deployments -- from various discussions I have
a vague feeling it may be possible to avoid that without copying. I'm doubtful.
Bottom line is if when this is implemented we have to copy to avoid file locking problems,
we'll copy.
>
Ok!
>
> > Max Andersen wrote:
> > > > If we're going to leave the original file around, for zipped
files IMO we should do away with the marker files, and use them solely for exploded
deployments, where they have a clear purpose. If the zipped files are left around, the
only thing the
> > >
> > >
> > > Or is there other/better ways to get this info now ?
> When anything is deployed, an entry for it is written in the
standalone/configuration/standalone.xml file.
ah - so deployment actually changes the original .xml file? Nice.
I hope it will retain comments that are in that file ? :p
> Why have markers both at toplevel /foo.war.deployed and
foo.war/META-INF/jboss-deploy - why not just have them as foo.war.deploy (request
deployment of foo.war) and foo.war.deployed (marker for foo.war have been deployed) ? More
consistent IMO.
> > > Fine with me.
> >
> >
> >
> >
> >
> >
> >
> > At submodule deployments it might make sense to have other markers at a
different "Depth" but when its the "same" thing you trigger a redeploy
of the marker should be the same.
There's no plan to support independent redeployment of submodules.
> The downside to that is multiple changes can't be made as an atomic unit, with
no requests seeing only some of the changes. But I don't think that's a critical
use case. Devs doing testing will deploy content, make some requests, update some files in
the deployment, make some requests, etc. They're not making requests in the middle of
copying in changed files.
> >
> >
> > This is actually a critical use case. Today we use jmx calls to tell AS to
*not* scan folders while we are copying files over and then continue when we are done. If
we didn't do that you would see *alot* more failure deployments.
> >
> >
> >
> >
> >
> >
> >
> > i.e. users updating a jar or set of jars - that copy operation will actually
take some ms's or even seconds for large jars and without disabling the scanner we see
alot more partial deployments.
> >
> >
> >
> >
> >
> >
> >
> > This can happen both on the initial creation of the foo.war or during
editing/changes.
> >
> >
> >
> >
> >
> >
> >
> > I think it would be great have a marker file to prevent deployment - i.e.
foo.war.nodeploy would make the scanner skip checking foo.war. Then the tool or user can
remove it when he wants it in play again.
> >
> >
> >
> Doesn't the .deploy file mechanism deal with this? With an exploded deployment,
the user has to add that file to trigger redeploy. Once the thing is deployed, changing
the contents changes what's visible as a resource to the deployment's classloader,
but the scanner doesn't do a full redeploy just because it detects some of the content
changed.
>
I guess - so if user change a file manually they will have to touch the .deploy file.
> I suspect this is leading into the subject of hot replacement of classes, which
sounds like a good topic for over a beer next week.
>
Luckily I think this problem is actually simpler to handle once we get the basic
'filesystem API' in place.
At least from a tooling user/dev perspective - the actual runtime implications is harder
;)
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/570942#570942]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]