Bugzilla – Full Text Bug Listing
| Summary: | Linked file in war does not work with jboss ide runtime server | ||
|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Jeffrey Wexler <bsgcic1776> |
| Component: | jst.j2ee | Assignee: | Rob Stryker <stryker> |
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | Chuck Bridgham <cbridgha> |
| Severity: | normal | ||
| Priority: | P3 | CC: | ccc, remy.suen |
| Version: | 3.2 | ||
| Target Milestone: | 3.5.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Jeffrey Wexler
This would appear to be a JBoss server adapter issue, and thus not WTP (or Eclipse). However, Rob would know that better than I, so I am assigning this to him for the initial investigation. The period that this bug appears to occur is immediately after creation of the link (to a file or directory). However, after shutting down eclipse, restarting the computer, starting eclipse, and then starting the JBoss 5.1.0.GA server with the ear project, the linking appears to work ok even without creating a symbolic link in linux. Thus, as a very rough guess, it appears that something that is suppose to occur, be initialized, or other upon the creation of a link is not executed immediately after the link creation. However, the process of shutting down eclipse and the computer and restarting everything appears to execute the needed operation. The most notable occurrence of this bug is upon creation of a new link to a new xhtml template in WebContent/layout. First off, you should never have to the eclipse platform to fix an error of this nature, much less restart your entire computer. There are only a few places where caching occurs, and usually closing and re-opening your project should fix them. If you are using JBoss tools, you can try to initiate a full publish in the server's view rather than just the incremental one. However... I've just tried this out with both jbt server adapters and generic and have found it unreplicatable. I had originally suspected that perhaps the linking of files didn't let the virtual component cache clear up. The cache clears on workspace change events and the idea was that if the file is actually in Project A, perhaps Project B wasn't clearing its cache for its deployables. But this was not true. Creating the linked resource does fire workspace and resource events as appropriate. Even modifying the file in project A fires events for both project A and project B, and the cache is cleared. Sadly I am not able to replicate. In this video i add a few different files, trying over and over to make it fail. It doesn't ;) http://oxbeef.net/work/330070.ogg Rob, I just tried to view the video but got a 403 Forbidden error. Let me qa it a bit more on my end as I continue to develop to identify in greater detail as to what the triggers are for this. When the error has occurred, I have tried to get around it via full publish of the ear as well as stopping, full publish, and re-starting the jboss tools app server. Those steps have not fixed the issue when it has occurred. Thus far, the only two steps that have independently fixed it were either creating the symbolic links in addition to the eclipse links for the respective link to files causing issue or by going to the extreme of shutting everything down and restarting everything. Given that this is difficult to reproduce for others, I am listing further details of my environment: * JRebel 3.1.2a (Note that I plan to upgrade it to the newly released 3.5) (zeroturnaround.com) (addins: JRebel Eclipse Debugger Integration; JRebel Eclipse Integration; JRebel WTP Integration) * Although JRebel states (emphasizes) to select "Never publish automatically" for the JBoss server, in Helios I was encountering some issues with the JRebel dynamic updates and thus switched the setting to "Automatically publish when resources change" which mostly solved that issue. (An exception actually being when I create a new linked folder or file - full publish solves that). * Ubuntu 10.04 LTS for 64-bit with Japanese locale * Gnome version 2.30.2 with build date 25 June 2010 * Eclipse install was the one for Java EE development * Jboss tools of course * Wordwrap addin (com.ahtik.wordwrap.featuer.group) * Log Viewer addin (de.anbos.eclipse.logviewer.feature.feature.group) * Groovy-Eclipse addins (org.codehaus.groovy.m2eclipse) (I don't even need this one anymore) * HP TouchSmart tx2 laptop with AMD Turion X2 64-bit (dual processor). 8GB RAM. Approx. 80GB free disk space. The following is the eclipse.ini: -startup plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.1.R36x_v20100810 -product org.eclipse.epp.package.jee.product --launcher.defaultAction openFile -showsplash org.eclipse.platform --launcher.XXMaxPermSize 512m --launcher.defaultAction openFile -vmargs -Dosgi.requiredJavaVersion=1.5 -XX:PermSize=512m -XX:MaxPermSize=512m -Xms1024m -Xmx4096m -XX:-UseGCOverheadLimit My links are such that there is an ear project group (i.e., the war project, ear project, and ejb project) that have the respective common files to be shared amongst ears. Then I link to files and folders in the above ear project group from four other ear project groups. Usually there are no issues and the linkages work wonderfully. But, I do encounter the issues of this bug report when I create a new file in the war of the common project and link to it from the others. I keep the Ubuntu up-to-date with all of the updates. I cannot think of any other details that might be relevant. video permissions have been updated... think it should work now I was able to watch the video. There are some differences in your projects than mine but I don't think those differences should matter (for one, the projects that I am using were created using File->New "Seam Web Project" and created as ears). Also, I use the Navigator instead of the Package Explorer but again I cannot imagine that that would make a difference. I think I should provide screen shots or a video next time it happens. There is an error that is written to the console which basically says that the "file cannot be found at:" and then it lists the physical location on the disk (e.g., /basedevdir/workspace/myProject/myFolder ...). I will include that in the update. I am not sure whether I should be logging the following as a new bug or as an additional comment on this bug. Kindly let me know if I should open a new bug for this. I have found a very bizarre, surprising error with linked files and folders in war projects. If an xhtml form page and its corresponding .page.xml file are physically residing in the war project (i.e., not linked from another project), then everything works fine. However, if those same files are either linked in themselves or are located in a folder that was linked in, then user selections on the form during the initial submission of the form by the user are reset (i.e., reset to null values) when the user clicks on the submit button. (Note, that the user selections are successfully sent to the java backing file via jsf prior to the user clicking the submit button.) (Also note, that if I re-make selections on the form and then re-submit, then it does successfully send the proper selections in the 2nd submission - just the initial submission for that session/conversation has the issue.) I re-state the the only difference between the two cases above is that the one that works is the one where the files are not linked; the case that does not work is when they are linked. (The backing java file in the ejb is in a linked folder and there are no issues with it existing via the linkage. Only the linked folders and files in the war exhibit the bizarre behavior.) This was a really really tough bug to diagnose because I never would have imagined that being linked versus not linked would cause the behavior. Anyway, it does. The workaround is to create a symbolic link within the linux filesystem corresponding to the linked folder in the war in eclipse. After doing so, the form works even when linked into the war project in eclipse. Thus, for now, obviously I will be creating such symbolic links in the filesystem corresponding to all linked files and folders in the wars as a workaround, but want to ensure that you are aware that there is a pretty significant bug with linkages in war folders (which is an exceptionally fantastic feature, by the way). retargeting to 3.3 Retargeting to maintenance, but, last time I tried this, it was unreplicatable. If I cannot replicate it again, I will probably assign it to the inbox and mark it as help-wanted, or possibly close the issue as unreplicatable. It'd be nice if you could get other people to replicate it so I know it's an issue more than one person has. For now, just delaying to 3.3.1. To be clear, this really is "noteclipse", but i'm leaving it open for now Moving to 3.4.1 It has been over two years since Rob said this was NOT_ECLIPSE. I think it is time to close it as such. |