JBossDeveloper

I am sure there are a tons of other more important things to do at this stage than discussing a hot deployment file-based API, so yes, if anyone has a different opinion can go ahead and implement it. On the other hand, independently of the underlying technical restrictions that suggest a certain design over another,I think the issue with this thread is that there doesn't seem to be an agreement as to what are the requirements. Without it, no matter what you implement, it is not going to be accepted.

Dimitris Andreadis wrote:

 

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.

 

I liked this idea. So here's my initial version of a variant of the current FileSystemDeploymentService https://github.com/jaikiran/jboss-as/commit/7a8c0d4261842cc45eba312b47f1b0192180db12

To summarize, this new OptOutFileSystemDeploymentService allows users to selectively disable processing of deployments (the exact opposite of the current approach). I'm pasting the javadoc here for more clarity:

/**
 * A {@link org.jboss.as.server.deployment.scanner.api.DeploymentScanner} which allows skipping of deployments present in
 * a directory.
 * <p/>
 * The presence of a &lt;fileName&gt;.skipdeploy marker file indicates that the deployment named &lt;fileName&gt; has to be skipped
 * during the deployment process. This is useful when a (usually large) deployment file is being copied to the deploy folder.
 * To prevent the deployment scanner from picking up the (incomplete) deployment, the user is expected to <i>first</i> place a
 * &lt;fileName&gt;.skipdeploy marker file in the deploy folder and <i>then</i> start copying the actual deployment file. Once the actual
 * deployment file is completely copied, the user should then delete the &lt;fileName&gt;.skipdeploy marker file so that the deployment
 * scanner pick up the deployment for processing, during its next scheduled interval.
 * <p/>
 * The contents of the .skipdeploy marker file does <i>not</i> matter and it can even be an empty file.
 * <p/>
 * Note that this {@link OptOutFileSystemDeploymentService} is different from the {@link FileSystemDeploymentService} only
 * in the way the deployment is triggered. In case of {@link FileSystemDeploymentService} the <i>presence</i> of a marker file
 * triggers a deployment (i.e. requires an additional action from the user even for small simple deployments or even when the
 * hot deployment is disabled). On the other hand, this {@link OptOutFileSystemDeploymentService} relies on the <i>absence</i>
 * of a marker file to trigger the deployment processing.
 *
 * @author Jaikiran Pai
 */
public class OptOutFileSystemDeploymentService extends FileSystemDeploymentService {

The main advantage of this scanner is that it allows users to just place their deployments in the deployment folder (either when the server is down or when the server is running) and not worry about any additional marker files. This I guess will cover many of our users. Then for those users who have to disable the hot deployment processing for large deployments, then will first create a *.skipdeploy file, then copy over the deployment and once its completely copied, remove the *.skipdeploy file.

Note that this new scanner continues to create/delete the rest of the internal marker files which Brian already explained. The end users don't really have to worry/care about those, so I did not change any of that behaviour. The only difference in these 2 scanners is related to the trigger that leads to the deployment processing.

I have built and tested this locally for standalone deployments. Worked fine for me. But if anyone else wants to test it out and see how it goes, that would be great. And ofcourse, since this is just the initial version, feel free to express any suitable changes that might be needed. Currently I did not find (or rather did not dig deep enough to find) a way to configure either of these 2 scanners outside of the code, so it's been enabled by default.

Is it worth making it the default scanner in our next release?

Message was edited by: jaikiran pai - Changed marker file from .skip to .skipdeploy, based on Max's suggestion.

This is really a case where folks need to put their code where their mouth is.

I think Jaikiran just "spoke". :-)

> Is it worth making it the default scanner in our next release?

I'd say let's experiment a bit first.

Just for aesthetics, I think the informative markers should be called: deploying, deployed/failed, undeploying, undeployed.

Then, the removal of the packed archive makes for a more symmetrical trigger, too. Do you know if that causes any resource/class-loading issues in the unpacked case? If this is so, maybe removing the .deployed descriptor is a preferred trigger, but that should delete the deployment, too.

I'm not set about the redeploy trigger. Maybe touching the .deployed descriptor is a good option, after all.

Just for aesthetics, I think the informative markers should be called: deploying, deployed/failed, undeploying, undeployed.

 

From earlier mail about why this was deliberatly not chosen:

"We did not use .deploy, .deployed as markers since it could cause confusion in filebrowser that can cut off the ending."

Which actually means we should consider finding better word for undeployed/undeploying...

Dimitris Andreadis wrote:

 

Do you know if that causes any resource/class-loading issues in the unpacked case? If this is so, maybe removing the .deployed descriptor is a preferred trigger, but that should delete the deployment, too.

 

I'll leave that question to someone who knows more about how this is currently handled in AS7. I kind of know that the contents are copied over to data/content folder. But I don't know the exact details from a developer point of view.

Dimitris Andreadis wrote:

 

I'm not set about the redeploy trigger. Maybe touching the .deployed descriptor is a good option, after all.

Ideally, if at all we want to use marker files, it would be good to reduce the number of marker files that the users should be aware about. IMO, the user could continue using the AS 4.x (and 5.x) approach of redeploying, by updating the real deployment file. Again, if he wants to disable that redeployment till it's completely copied, he can first copy a .skipdeploy (just like a normal deploy operation).

Guys, I'm sorry if I sounded overly-critical yesterday.  I realize that I've only been working on AS7 a few weeks while some of you have been putting in long hours on it for months and months.  There's a lot of really great stuff in AS7 but I don't think we want the user's first impression to be a turn-off.  I've seen this sort of thing kill great software in the past and we really, really need to get it right.

So I ask you to take advantage of my perspective here, which is as one who is coming to the product with little knowlege of how or why certain decisions were made.  I just want to deploy something.

So this morning I downloaded the beta and tried to do just that.  I tried to deploy something.  I see the README file that talks about "dodeploy" files.  So my earlier criticism about how I would know about it is somewhat alleviated.

But here is how it turned out:

1) Download AS

2) Drop my WAR in standalone/deployments 

3) Start AS

Nothing happens.  Decide it's time to look at the README.  (BTW, the README says "/deployment" but the dir name is plural "/deployments")

1) Create a "dodeploy" file.

2) Start AS

Nothing happens.  I notice that my dodeploy file name is misspelled.  The WAR name is a little long and complicated, so that's not surprising.  But I'm annoyed at the fact that I had to type it and now I have to fix it.

1) Fix the file name

2) Start AS

Nothing happens except that I get this warning:

09:08:26,174 WARN  [org.jboss.as.deployment] (pool-6-thread-1) Deployment of 'C:
\jboss-7.0.0.Beta1\standalone\deployments\mojarra2.0-notbundled.war.dodeploy' re
quested, but the deployment is not present

But I know the deployment is there!  Maybe I should touch the dodeploy.  I can't do that from Explorer so I have to open a command prompt.  There is no "touch" command on Windows, but luckily I have Cygwin in my path for just such occasions.  Woops!  I can't touch what isn't there.  My dodeploy file is gone!!  Where did it go?

Let's take the README a more literally.  Instead of creating a dodeploy file and starting the server, let's try starting the server and actually issuing the touch command from the command prompt.

1) Start AS

2) cd to standalone/deployments

3) touch my-long-funky-war-name.war.dodeploy

It finally deploys!!

Pretending that I'm a developer seeing AS7 for the first time, what's my impression?  Love the quick boot time.  Hate the deployment mechanism.  Fix the latter and I'm very, very happy.

Stan

When it comes to marker names without a uniqueness issue I'd go for:

.skipdeploy

.isdeploying

.deployed

.failed

.isundeploying

.undeployed

I really wish you guys would actually read the whole thread and actually consider the technical issues, instead of just repeating an approach that has failed vetting.

1. Auto-deployment of zip based archives can be done without markers, as I mentioned numerous times in this thread. In fact, we are going to do it; we just haven't gotten to it yet. I will repeat again, it is possible to detect and ignore an incomplete zip file (by analyzing the last block).

2. Processing incomplet or corrupt zips can (and has according to support cases) crash the JVM, since it uses a sometimes fragile native code library.

3. It is not possible to detect when to deploy or redeploy all EE6 applications portably and reliably. You simply can not get away from a marker file. They may not have DDs and you can't rely on a directory timestamp.

4. "Skip" DOES NOT ADDRESS 3 and it's nearly pointless when you have 1 implemented. It also encourages misuse ( if they can't be bothered to use dodeply why would they use skip?) it's also more commands when you actually do use it correctly.

5. The errors caused by sloppy exploded  redeploy appear like an app server bug, and can lead to strange and confusing results. Further gratuitous redeploy is a major usability problem, in particularly when you are in the middle of a debug session.

3 is referring to exploded directories.

Also since I am replying again, I just want to mention that windows hasn't defaulted to diaplaying 3 char extensions in a long long time. In fact I would argue that java 6 probably doesn't even support these versions.

I need to apologize for jumping in and out of this thread a couple of times and I understand the frustration from the people actually implementing the stuff. It's has been a very long discussion (and I actually went through the entire thread yesterday to re-establish context) but you need to understand we don't critisize just for the fun of it, but because we feel it is important for our users and customers to get this right.

The old mechanism had its problems but it cannot be outrightly dismissed saying it was broken. It's been in use for a decade and it was one of the key features of JBoss (drag&drop an archive to hotdeploy it, remove to undeploy), a feature that everybody loved and all our competitors copied. Hundrends of thousands of users are already familiar with it. Remember also farming, a mechanism that had even more problems than hotdeployment? We removed it at one point and then we had to add it back because customers liked it no matter how many problems it had.

Going back to the issue, I think we need to have in mind 2 categories of users.

A) The developer, the occasional user or someone who's just playing with JBoss and/or was familiar with the old JBoss. For them, drag&drop should work out of the box. Those guys shouldn't have to *create* a file marker. Maybe they could touch the .deployed marker to cause a redeployment (for both packed/unpacked deployments), or remove it to trigger an undeployment, but in no case they must have to create a marker file themselves. Older IDEs just copying files around should work too (with the exception of those that touch nested descriptors to cause a redeploy). (Oh, yes, and don't forget that 75% of our users use Windoze )

B) The serious developer or admin/script writer. Those guys need safety and either through the IDE that understands about marker files or through scripting, they want the safest deployment method possible. They'll use every marker file trick available.

Those requirements lead to a mixed solution. One that let's you use the usual drag&drop behaviour to deploy/undeploy stuff BUT also let's you use the marker files to enhance the experience. In the case of an unpacked deployment, using the marker file for redeployment/undeployment looks like the best alternative, anyway. I tried to put the workflows in paper and it looks complex to implement, but I prefer the complexity to fall in our hands than to our users who will download AS7 and fail trying to do a simple deployment.

Sorry for the long post, I hope that clarfied a bit my position on this thread.