]
Brian Fitzpatrick commented on JBIDE-5936:
------------------------------------------
I think #2 is more of what we were thinking in trying to move forward the ESB runtime
validation bits.
New ESB Project wizard validation needs to be earlier in the process
--------------------------------------------------------------------
Key: JBIDE-5936
URL:
https://jira.jboss.org/jira/browse/JBIDE-5936
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: esb
Affects Versions: 3.1.0.CR2
Reporter: Brian Fitzpatrick
Assignee: Brian Fitzpatrick
Fix For: 3.2.next
Original Estimate: 0 minutes
Remaining Estimate: 0 minutes
While testing a fix for JBIDE-5916, Rob Stryker discovered the strange and undesirable
behavior as documented below while testing against EAP 5.0 instead of SOA-P 5.0:
"When I am in the first page of the esb project wizard, automatically selected is my
JBoss EAP 5.0 Server Runtime. Below it is also automatically selected "ESB Version:
4.7". Yet when I push forward two pages, it tells me my server does Not have esb 4.7
in it, I then have to go back two pages and change the facet version, then forward two
pages to see if the error has disappeared.
I finally gave up, as it one by one informed me that I do not have a satisfactory version
in my EAP 5.0 runtime at all, which I find as extremely unlikely. At at least one attempt
told me I did not even have a runtime selected, when the UI clearly did. (I eventually got
confused enough that I did a du -a | grep -i "esb" command to see if the eap
server had any jars or anything that mentioned "esb" anywhere in the file name.
None did. So now I'm wondering if my install is just odd, but I don't suspect it
is.
I decide to switch to not using the "Server supplied runtime" and instead
creating a new one on the third page, and I again pointed to my jboss-eap-5.0 folder. At
no point did this dialog inform me that none of the versions were found. Instead I, once
again, had to select each of the 6 versions to find out none were valid for this folder.
I finally pointed directly to an actual esb server (jbossesb-server-4.4.GA) and the
dialog did auto-fill itself in, though I also remember I was the one who made that fix
about 2 months ago after a similarly infuriating attempt at this.
However even after I do this, I notice in my Package Explorer that there is NO classpath
container containing any ESB jars on hte project. So I check the .classpath file to see if
ANYTHING was added at all, and I see this:
<classpathentry kind="con" path="server.supplied/SomeName"/>
Aside from the ridiculously short and uninformative name "server.supplied", the
adept user will note that this entry was not, actually, server supplied at all, but rather
the other option, as I outlined above and pointed directly to an esb installation. Aside
from that, this "server.supplied" is directly visible in the Java Build Path
property page, under the Libraries tab. Which means this constant is exposed to users to
see."
The issue here seems to be that the runtime validation to see if it actually HAS an ESB
installed doesn't occur until page 3 of the wizard. This should be done up front on
page 1 of the wizard. If ESB isn't available in a selected runtime, the user should
not be able to continue in the wizard and should get an error message saying that the
runtime selected doesn't support ESB. Pretty simple.
The user should not be forced to go forward/back through the wizard trying different
combinations if NONE of the combinations will actually work.
This needs to be fixed for the next release.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: