[jbosstools-issues] [JBoss JIRA] (TOOLSDOC-345) NeedInfo: Distinction between Eclipse and JBDS/JBT Server Tools

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/TOOLSDOC-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781983#comment-12781983 ] 

Rob Stryker commented on TOOLSDOC-345:
--------------------------------------

During a publish, changed files in the workspace will be moved to your deployment.  So for example,  {workspace}/project1/webcontent/myhtml.html will be copied over to {jbossasroot}/standalone/deployments/project1.war/myhtml.html. 

Any changes will now be visible. 

The server itself, the running JBoss server, will not 'redeploy' the module. This is because html files are served directly without changes by the app server. HTML files aren't run or interpreted or executed on teh server at all. They're simply served as regular files. So an updated html file will be completely ignored by the app server, and the server will serve out the new updated one the same as it served out the old one. 

If you change a .class file somewhere though,  the server ALSO will not 'redeploy' the application. This is because the server is not scanning EVERY file in your module for updates. Class files *are* used by the server's logic, but, the server team has decided that checking the timestamps on all files in a deployment is a big waste of time for the server. If a user wants a module to be re-deployed, they should use one of the re-deploy mechanisms. The server will not note that the .class file has been changed and respond to that with a redeploy of the application. 

SO...  when you modify a .html file and republish the app, the server doesn't redeploy, but the new .html file is able to be served out to clients. If you modify a .class file and republish, though, the server ALSO doesn't redeploy, but the new .class file will NOT take effect in teh server. The server will only SEE the new .class file if the module is properly undeployed and redeployed. 

Users will complain about this behavior. I changed an html file and can see the results immediately, but I changed a System.out.println line in my .java file and published the changes and the server is not printing anything. Yes, this is intended. The server did not scan for timestamp changes on the .class file and did not redeploy the application. On disk, the new .class file is inside your deployments folder, but, the server only loaded those classes when it initially deployed the application. The updated .class file you published has so far been completely ignored by the running server. 

To fix this, when modifying .java (and thus .class) files, you need to use FULL PUBLISH or RESTART on your module. This ensures the server actually deletes what's in running memory, and reloads your module from disk. 

Users would then complain, I don't WANT to have to undeploy and redeploy my app every time I make a change to a .java / .class file. Why doesn't the running server notice the change? OR at least why doesn't JBT notice the change and tell the server to redeploy FOR me.  I'm waaaay too lazy to click full publish, or undeploy / redeploy.  

In response to this, we added application reload behavior. 

So now, when a user changes a .java file, and it gets changed to a .class file, and copied into a standalone/deployments folder, JBT will then ALSO check if ANY changed files match the 'application reload behavior' pattern. If one does, we will ALSO tell the server to redeploy the application, not just copy the changed files over. 

As I said, in the past, if you changed a .java file, you get a new .class file, the .class file gets copied to standalone/deployments/MyProject.war/some/file.class,  and the running server completely ignores it.  NOW, if your application reload behavior includes .class, JBT will ALSO tell your server "hey, user wants this application re-deployed from disk, so, undeploy and redeploy it for him". 

Of course users don't wnat this behavior on every change. Since html files are served directly, they never need a redeploy. So if we simply forced a redeploy after every single change, users who just change a line in a html file will have to wait while the server undeploys and redeploys the application. This could take any number of seconds dependign on the size of the deployment. So it makes sense as a customizable setting for the users. 


                
> NeedInfo: Distinction between Eclipse and JBDS/JBT Server Tools
> ---------------------------------------------------------------
>
>                 Key: TOOLSDOC-345
>                 URL: https://issues.jboss.org/browse/TOOLSDOC-345
>             Project: Documentation for JBoss Tools and Developer Studio
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: User Guide - JBoss Server Tools
>    Affects Versions: 4.1.0
>            Reporter: Michelle Murray
>            Assignee: Rob Stryker
>             Fix For: 4.1.0
>
>
> I am trying to distinguish which features are provided by Eclipse and which are provided by JBoss Server Tools so that I can accurately document JBoss Server Tools.
> The unique JBoss Server Tools features I have are:
> * automatic runtime detection
> * ability to download and install a JBoss runtime
> * JBoss Server Editor - lots of the panes in the overview tab are unique and * the deployment tab is completely unique
> * set a default server icon
> * set default filesets
> * set default classpath entries
> * create new server wizard also seems different for JBoss enterprise and community servers than in the wizard in Eclipse alone
> What have I missed?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira