JBossDeveloper

Max Andersen wrote:

 

There will be flag in server configuration (TBD where exactly) to
enable old style scanning for/reaction on descriptors, but will not be

enabled by default. This will allow existing tooling for pre-AS7 to work sensibly.

This makes absolutely no sense to me. Existing tools will have to be updated anyway to deal with a different directory structure, different configuration files, and likely different jboss deployment descriptors. Assuming this wasn't an issue it's still off by default, so what's the point

foo.war.donotdeploy - Marker for server to ignore foo.war (used to ensure partial deployments does not happen while copying)

If we need this, we are better off just requiring  a .deploy marker. It's the same number of steps, and is slightly more intuitive. Note that we can actually detect partially copied zips.

Jason Greene wrote:

 

Max Andersen wrote:

 

There will be flag in server configuration (TBD where exactly) to
enable old style scanning for/reaction on descriptors, but will not be

enabled by default. This will allow existing tooling for pre-AS7 to work sensibly.

This makes absolutely no sense to me. Existing tools will have to be updated anyway to deal with a different directory structure, different configuration files, and likely different jboss deployment descriptors.

 

Tools does not need to know about different structure, configuration nor deployment descriptors to deploy.

They just need to know about the destination directory - nothing else.

 

Assuming this wasn't an issue it's still off by default, so what's the point

 

The option were off by default to provide the safer "API" by default and option existed to let existing tools work with AS7...(those that works/worked with AS 3,4,5 & 6.

foo.war.donotdeploy - Marker for server to ignore foo.war (used to ensure partial deployments does not happen while copying)

 

If we need this, we are better off just requiring  a .deploy marker. It's the same number of steps, and is slightly more intuitive. Note that we can actually detect partially copied zips.

 

 

you mean if the file is not properly zipped ? will you keep doing that on every rescan until it becomes complete ?

can you detect these partial copied zips without locking the file ?

 

the flag were there to have good balance between implicit and explicit control.

Jason Greene wrote:

 

jaikiran pai wrote:

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.

 

 

I was reading a mail about configuring Java2 security for a web application on AS5 and realized that it might have to play a role here too. Users might have to know the (consistent) location where the deployments will be extracted so that they can setup appropriate permissions.

 

A very good point. This should become a separate forum thread, as it affects all deployments (domain deployments) as well. We may need to somehow add this info to the domain.

I think that as long as we use a predictable code source URL for deployments it doesn't have to be a specific filesystem location (especially if it varies between expanded and non-expanded deployments).  Maybe in this case, the resource loader should use a VFS URL or even a special deployment URL type (e.g. "deployment:///foo.war").

David Lloyd wrote:

 

Jason Greene wrote:

 

jaikiran pai wrote:

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.

 

 

I was reading a mail about configuring Java2 security for a web application on AS5 and realized that it might have to play a role here too. Users might have to know the (consistent) location where the deployments will be extracted so that they can setup appropriate permissions.

 

A very good point. This should become a separate forum thread, as it affects all deployments (domain deployments) as well. We may need to somehow add this info to the domain.

I think that as long as we use a predictable code source URL for deployments it doesn't have to be a specific filesystem location (especially if it varies between expanded and non-expanded deployments).  Maybe in this case, the resource loader should use a VFS URL or even a special deployment URL type (e.g. "deployment:///foo.war").

In other words, our internal content repository structure and location should not be a matter of public API.

Hello,

I wonder if it is somehow possible to update a deployment in place. With AS6 I placed a foo.war in the deploy directory and I was still able to change it using mc for instance. I don't see such a possibility with AS7 since the original file is replaced with foo.war.deployed...

Thanks,

Martin

That is what this suggestion is about changing

See my post from Nov 20, 2010 about the suggested layout/functionallity.

Cool - any hudson builds or similar we can take this from or does it require getting an AS 7 build setup locally ?

btw. what counts as a community demand ?

Does the fact that about every appserver I know supports this counts ?

That every tool I know about when it comes from ant, maven, gradle, netbeans, eclipse, myeclipse, you name it won't be able to easily deploy to AS 7 ?

Of course that means everyone have to use JBoss Tools or Developer Studio (or learn the file marker api and implement that in thei ant/maven scripts until their other tooling is updated)

...of course someone could actually implement this autohotdeploy externally now by writing a filemonitor and add the touch file

A maven and ant  plugin that uses the deployment API is less work, more correct, and more informative to the user. As to IDEs, the will need to be updated anyway.

Brian - is my posting about the file markers what got/will be implemented ? looking at the patch on github it seems not all markers and names are the same ?

Reading the code I see this:

foo.war.dodeploy - trigger deploy of archive or exploded directory.

foo.war.faileddeploy - ACK from server that deploy failed (content should contain info about reason for failure)

foo.war.deployed - ACK from server that foo.war.isdeployed.

Is thats correct/intent ?

Jason - if AS 7 had hotdeploy by just copying the war/ear/folder there then IDE's would not need to be updated for basic usage.

And ant doesn't really need a plugin to utilize this - users just add a <touch name="${deploy.name}.dodeploy"/> to their deployment.

Maven is tricky - I guess extending Cargo would be the option to support ? Anyone targeting/working on that ?

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

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 ?

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

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.