IBM, WebSphere 4.0.x and wasting time
[
dion
]
13:16, Tuesday, 23 March 2004
(update: Apparently the TechNotes on the WSAD support page are the best place to look for issues, along with the README file of the released product.)
In the last month, as part of automating our build process, I've raised 4 bug reports on the ejbdeploy tool of WebSphere Application Server, Advanced Edition (For the interested, PMRs 49750, 55301, 55386, 55930).
49750 - opened 2004-02-19 and closed on 2004-03-05 ('corrupt' metadata files)
55301 - opened 2004-03-05 and closed on 2004-03-24 ('cmp ejb cant have a cmp field called 'value')
55386 - opened 2004-03-08 and closed on 2004-03-10 ('corrupt' metadata files)
55930 - opened 2004-03-23 (ejbdeploy doesn't include RMIC code if an ejbModule directory exists)
All of these are problems with the tool where it either fails to run to completion successfully, or runs successfully but doesn't create a correct jar.
The code can be successfully exported out of IBM WebSphere Studio AD in each case, so there's an inconsistency between the development and deployment environments.
The response from IBM on 55301 when I enquired if these would be fixed in an upcoming release was
Potential fixes for problems in WSAS 4.0.x would be evaluated and several factors will help us to make decision whether or not fixes for it would be
developed such as its prevalence, workaround availability, and if the newer releases already have fixes for them. For this particular problem we would not work on a fix for WSAS 4.0.
The end result? I've wasted days on these issues with a decision from IBM that these issues will be not be fixed in a later release.
The decision to not fix these issues mean that any other poor sucker on WAS 4.0.x is going to have to go through the same pain as I did.
It also doesn't give me a good feeling about other bugs we may pick up on the way, if they're already known about (by IBM) and I then spend days trying to work around them.
It would be much better if the list of issues and workarounds were documented so that we could easily find them, and in the case of calling a CMP field 'value' steer clear of them altogether.
Surely this would make the support team's job easier too.
TrackBack