Brian Stansberry [
http://community.jboss.org/people/bstansberry%40jboss.com] created the
discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
http://community.jboss.org/message/570597#570597
--------------------------------------------------------------
This forum interface drives me nuts. As I write this I'm chatting about what public
mailing list we should use for AS 7 dev discussions.
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.
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 marker
files provide is an indication that the content was actually deployed. There are other
ways to see that; and by itself that's not justification for the confusion of having
two files around.
>
> I agree - if the file stays around the marker file has no real importance.
>
>
>
> Well, maybe for consistency and actually knowing the file got deployed without
having to scan logs ?
>
>
>
> 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.
How are users to know where the actual deployment is happening from ?
Suggestion: put a deploy.location=/var/tmp/blahbla/foo.war into the marker file - simply
for ease of debugging/transparency.> > I've been tempted to do that. Haven't
because 1) it forms a semi-contract that I'm not sure we should commit ourselves to.
2) It also encourages poking around in places users aren't meant to go poking. 3) It
also forces the deployment content repository to expose internal implementation details to
the deployment scanner service, which isn't the end of the world but isn't nice
either.
> >
> > There is INFO level logging of where the deployment content is stored (which
shoots my #2 above). :-)
> >
>
> I keep hearing this "by exposing the actual deployment location there is a
semi-contract"-excuse and I just don't buy it.
>
> The deployment is going to be *somewhere* wether that is on the filesystem or
in-memory then telling the user where it is being 'read' from is never a bad
information to have.
>
>
>
> And as you said - it gets logged anyway (for a reason I assume ? :)
I have
no serious objection to telling people where deployments are stored. This is OSS after
all. As we go along there should be a wiki page describing exactly how this works for a
given release. I'm just doubtful about persisting it in this file. People come to
count on reading the file and you can't lightly stop writing it even if it becomes a
problem.
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 suspect this is leading into the subject of hot replacement of classes, which sounds
like a good topic for over a beer next week.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/570597#570597]
Start a new discussion in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]