JBossDeveloper

Emanuel Muckenhuber wrote:

 

Max Rydahl Andersen wrote:

 

Thanks for the writeup Brian, which git repo contains these fixes ?

It's all in upstream here: https://github.com/jbossas/jboss-as

 

And the downloadable latest binary version can be obtained from this job http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x/

Max Rydahl Andersen wrote:

 

A few questions come up with me trying these things out a bit (based on the previous as7 builds on hudson)

 

I've had AS7 go bad on me because of some bugs in the deployer, so bad that I couldn't startup thus I removed both the .war.deployed and .war  files to trigger the undeployment....but it seem to not have an effect - it still deployed what was in the standalone.xml - I guess because it doesn't retain enough state to decide how to undeploy based on filemarkers?

 

This might be expected behavior, but its a bit confusing

 

Would you expect that putting .war.undeploy before AS7 starts up would work ?

That's the expected behavior currently. When starting up AS we first try to restore the persisted state and then check for deployment modifications. However failed deployments should get rolled back and not be persisted in standalone.xml.

okey - so keeping a foo.war.undeploy in the deployment folder at startup should trigger undeploy - but only after it tried deploying the state of the standalone.xml ?

The problem is that sometime deployments work fine from the perspective of AS7 but some runtime issue triggers problems and thus one would like to ensure its not getting deployed - but I guess the only option is then to manually edit the xml file...since using the remote API would have the same problems.

Makes sense concerning .isDeployed; how about the case of users using the management API to undeploy this app - will the marker files get updated too or is that too much magic

Ignore my last brain-dead comment. :-)

(which was already deleted)

You know, this whole idea with the marker files, I think it's just to complex for a simple deployment. If one is truly interested in deploying in a safe way, they could use the CLI, no?

Or, why not turn the problem upside down?

Treat the deployments directory exactly like in previous jboss versions (i.e. deploy something when is copied, undeploy when is removed) to retain backwards compatibility with user expectation, tools and the like.

In addition, if you want to go for an atomic deployment of XXX (packed or unpacked), create first a marker file XXX.skip, then copy in the deployment (packed or unpacked) and remove the XXX.skip file when done to trigger the deployment. Voila.

To undeploy either remove directly the deployment, or if you fear it cannot be done atomically, create again a XXX.skip, remove the deployment and then remove the XXX.skip file to trigger undeployment.

For a re-deployment just touch the packed file, or the directory in the unpacked case.

This would ensure atomic deployments, while retaining "backwards compatibility" for the ./deploy directory notion.

Dimitris Andreadis wrote:

 

You know, this whole idea with the marker files, I think it's just to complex for a simple deployment. If one is truly interested in deploying in a safe way, they could use the CLI, no?

The CLI does not yet provide a way to do deployments AFAIK and it also requires a running server and seem also to not support exploded/incremental deployemnts - so its for very different usecases.

I'm waiting eagerly to learn how to use the http/native approach to do deployment since that is very useful for remote deployment - but without eploded deployments the file approach is still the best for fast feedback development.

btw. you *always* want to deploy without intermediate scans which was the biggest pain when copying into the server - jboss tools at least made that painless with its disablement of the deployment scanner while copying.

Or, why not turn the problem upside down?

 

Treat the deployments directory exactly like in previous jboss versions (i.e. deploy something when is copied, undeploy when is removed) to retain backwards compatibility with user expectation, tools and the like.

 

 

I would love that and was my initial proposal but was told it could not be done without a lot of overhead/complexity.

 

In addition, if you want to go for an atomic deployment of XXX (packed or unpacked), create first a marker file XXX.skip, then copy in the deployment (packed or unpacked) and remove the XXX.skip file when done to trigger the deployment. Voila.

 

yup - I think that was called .donotdeploy marker in previous talks.

 

To undeploy either remove directly the deployment, or if you fear it cannot be done atomically, create again a XXX.skip, remove the deployment and then remove the XXX.skip file to trigger undeployment.

How would adding a .skip befor trying to remove the directory help ?

 

For a re-deployment just touch the packed file, or the directory in the unpacked case.

 

This would ensure atomic deployments, while retaining "backwards compatibility" for the ./deploy directory notion.

Yes I agree with this but the state changing files are still superuseful for both tools and users (i.e. .deploying, .deployed, .undeploying, .undeployed) IMO.

> How would adding a .skip before trying to remove the directory help ?

I guess it would only help in case where you a recursive deletion of a big deployment could somehow trigger the scanner mid-ways.

> Yes I agree with this but the state changing files are still superuseful for both tools and users (i.e. .deploying, .deployed, .undeploying, .undeployed) IMO.

I agree they are useful. I am just saying that the ./deploy notion was successful because it was simple, albeit not perfect.

The end users will have the final say, if they like the new mechanism, or not.

Dimitris Andreadis wrote:

I agree they are useful. I am just saying that the ./deploy notion was successful because it was simple, albeit not perfect.

+1000

Sure, it's useful, but the lack of a simple deploy/undeploy mechanism will hurt adoption.  I'm sure it's already

hurting beta participation.

Plus there is this nasty problem.  Am I the only one who sees it?

https://issues.jboss.org/browse/JBAS-8907

 

Dimitris Andreadis wrote:

 

The end users will have the final say, if they like the new mechanism, or not.

I'd argue that the market has already spoken on that long ago.  Anyone remember

SilverStream?

Stan

None of us (who have actually done the work of researching a way to making filesystem deployment actually work with the domain management model) are going to change this from how it is right now.  If you want to change it and you have a better idea, please implement it and submit the patch and it will be considered.  Yeah the old mechanism was "simpler and less correct", which is somehow being touted as a virtue (?!), however it is also completely and irretrievably incompatible with the new domain management architecture.  End of story.

As for hurting beta adoption - there IS no beta yet so I can only say "gimme a friggen break".  How about we stop this bitching and moaning session.  The mechanism actually works great; I've used it successfully and I think that users will like it just fine.  I like it a lot better than the "old way".  I screw it up much less.

Add the deployment file(s), make a "dodeploy" file for each.  Dead simple!

SilverStream?  Gimme a break.

I haven't seen JBAS-8907 yet, but I've seen a few others that are annoying for any user trying to deploy an app they got working on other AS's.

https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JBAS+AND+resolution+%3D+Unresolved+AND+reporter+%3D+currentUser%28%29

But I guess that is where the beta comes in and drags out some more of these to be fixed.

And yeah without the file based deployment I basically couldn't get AS7 to do anything in a "developer mode" - only small things deploys fine.

btw. in hope to help adoption we're trying to get a the AS eclipse plugins available in our nightly build updatesite to at do the marker file dance ASAP.

If you want to change it and you have a better idea, please implement it and submit the patch and it will be considered.  Yeah the old mechanism was "simpler and less correct",

What about if you leave the old one (which was used before Brian's update) as optional?

e.g. users could fallback to that one if that's what they feel is "simpler" for them and they don't need all of the domain management magic

Add the deployment file(s), make a "dodeploy" file for each.  Dead simple!

 

We do not cover the drag&drop/drag&remove scenario, thought. I hope noone misses that.

David Lloyd wrote:

 

None of us (who have actually done the work of researching a way to making filesystem deployment actually work with the domain management model) are going to change this from how it is right now.  If you want to change it and you have a better idea, please implement it and submit the patch and it will be considered.  Yeah the old mechanism was "simpler and less correct", which is somehow being touted as a virtue (?!), however it is also completely and irretrievably incompatible with the new domain management architecture.  End of story.

 

Yes, it's a virtue!!!!   The out-of-box experience is the #1 thing you have to get right.  At first a developer wants to try out AS7 and get a WAR running without having to learn new concepts. ("WTF is a dodeploy file and how would I know that I need one??")

This is a basic usability problem that has already been solved and we're taking a step backwards.

So just make the old deployment mechanism only available on standalone.  That's the main place you need it. 

Stan