|
Home > Archive > WebSphere Application Server > June 2004 > Unable to find setter method for attribute: name
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Unable to find setter method for attribute: name
|
|
|
| Hello -
I'm writing to ask your help for a very bizarre problem. Perhaps those
who understand how Websphere deals with beans will be able to sort out
this issue for me.
We are running Websphere 5.0, SP1, Base edition. All of our developers
are running on Windows 2000.
We have a build script (using ant and JDK 1.3.1_08) that builds our site
and creates a war file. The site includes a number of tag libraries.
One of our developers (who is in India) has been having trouble getting
the site to run. When she compiles and installs the site locally on her
machine, she gets the following error in the logs:
[6/27/04 10:20:33:562 GMT+05:30] 462d527d WebGroup E SRVE0026E:
[Servlet Error]-[/include/../states/sections/standard_equipment.jsp&#
40;12,0) Unable to find setter method for attribute: name]:
org.apache.jasper.compiler.CompileException:
/include/../states/sections/standard_equipment.jsp(12,0) Unable to find
setter method for attribute: name
at
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generateSette
rs(BasicTagBeginGenerator.java(Compiled Code))
at
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generateServi
ceMethodStatements(BasicTagBeginGenerato
r.java(Compiled Code))
at
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generate
(BasicTagBeginGenerator.java(Compiled Code))
at org.apache.jasper.compiler.JspParseEventListener
$GeneratorWrapper.generate(JspParseEventListener.java(Compiled Code))
at org.apache.jasper.compiler.JspParseEventListener.generateAll
(JspParseEventListener.java(Compiled Code))
at
org.apache.jasper.compiler.JspParseEventListener.endPageProcessing
(JspParseEventListener.java:292)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:234)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.loadJSP
(JspServlet.java:963)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
$JspServletWrapper.loadIfNecessary(JspServlet.java:289)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
$JspServletWrapper.service(JspServlet.java:326)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile
(JspServlet.java:694)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service
(JspServlet.java:792)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService
(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service
(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.ServicingServletState.service
(StrictLifecycleServlet.java:333)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service
(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service
(ServletInstance.java:283)
at
com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch
(ValidServletReferenceState.java:42)
at
com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch
(ServletInstanceReference.java:40)
at
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispat
ch(WebAppRequestDispatcher.java:923)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch
(WebAppRequestDispatcher.java:528)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward
(WebAppRequestDispatcher.java:176)
at org.apache.jasper.runtime.PageContextImpl.forward
(PageContextImpl.java:498)
at org.apache.jsp._redirect._jspService(_redirect.java:403)
at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service
(HttpJspBase.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
$JspServletWrapper.service(JspServlet.java:364)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile
(JspServlet.java:694)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service
(JspServlet.java:792)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService
(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service
(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service
(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service
(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service
(ServletInstance.java:283)
at
com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch
(ValidServletReferenceState.java:42)
at
com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch
(ServletInstanceReference.java:40)
at
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispat
ch(WebAppRequestDispatcher.java:923)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch
(WebAppRequestDispatcher.java:528)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward
(WebAppRequestDispatcher.java:176)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward
(WebAppInvoker.java:79)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook
(WebAppInvoker.java:201)
at
com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocatio
n(CachedInvocation.java:71)
at
com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invok
e(CacheableInvocationContext.java:114)
at
com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI
(ServletRequestProcessor.java:186)
at
com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service
(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest
(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest
(HttpConnection.java:516)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:362)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:593)
===
However, none of us are getting this same error.
Also, if we compile a war on another machine, and then copy the war over
to her machine and then install it, the site works fine. So, it doesn't
seem to be a problem with her websphere install. Rather, it seems to be
a problem with the war files that are generated on her machine.
I did a comparison of the class file in question that contains the setter
method for 'name' on a working machine and her machine, and they were
exactly the same. In fact, comparing the generated war files from her
machine and another machine, I am not able to find *any* differences
which could account for this behavior.
However, there are some things BeyondCompare cannot see - for example, if
there were a subtle difference in the generated byte code for the bean.
I have confirmed that when compiling on her machine, she uses the same
JDK we do - sun jdk 1.3.1_08.
I am going to try to take one of the wars generated on her machine and
try it on a known good machine to see if we can reproduce the error.
However, in the meantime, does anyone have any idea what might be going
on?
Is it some sort of capitalization issue? The bean in question is
referenced as
<spi:render name= ... >
but in the classfile the setter is
public void setName(String name)
I found the following post possibly relevant:
http://groups.google.com/groups?hl=...=UTF-8&threadm=
39ddee39.10611788%40news&rnum=5&prev=/groups%3Fq%3D%2522unable%2520to%
2520find%2520setter%2520method%2522%26hl
%3Den%26lr%3D%26ie%3DUTF-8%26sa%
3DN%26tab%3Dwg
especially this part:
The problem lies in how JRun and Tomcat find property setter methods
when they are generating servlets from JSP code. JRun simply writes a
setXXX(value) line, whereas Tomcat uses beans introspection to find the
appropriate "set" method.
How does websphere find property setter methods? Is there something that
could *change* how websphere finds property setter methods - specifically
something in the war or the compiled libraries used by the war?
Any other wacky theories or ideas are welcome. This problem has stumped
me and I have no idea what else to try.
thanks,
karl
karl_travel_no_spam@yahoo.com
| |
| Larry Carasco 2004-06-28, 9:01 am |
| Karl, do you have a getter method for "name" which doesn't return a String?
We encountered something recently which sounds very similar which related to
having the set and get methods for a given attribute which acted upon
different types, the get method was in fact redundant.
"k" <karl_travel_no_spam@yahoo.com> wrote in message
news:Xns95154EF7B5Akarltravelnospamyaho@
207.217.125.202...
> Hello -
>
> I'm writing to ask your help for a very bizarre problem. Perhaps those
> who understand how Websphere deals with beans will be able to sort out
> this issue for me.
>
> We are running Websphere 5.0, SP1, Base edition. All of our developers
> are running on Windows 2000.
>
> We have a build script (using ant and JDK 1.3.1_08) that builds our site
> and creates a war file. The site includes a number of tag libraries.
>
> One of our developers (who is in India) has been having trouble getting
> the site to run. When she compiles and installs the site locally on her
> machine, she gets the following error in the logs:
>
> [6/27/04 10:20:33:562 GMT+05:30] 462d527d WebGroup E SRVE0026E:
> [Servlet Error]-[/include/../states/sections/standard_equipment.jsp&#
> 40;12,0) Unable to find setter method for attribute: name]:
> org.apache.jasper.compiler.CompileException:
> /include/../states/sections/standard_equipment.jsp(12,0) Unable to find
> setter method for attribute: name
> at
> com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generateSette
> rs(BasicTagBeginGenerator.java(Compiled Code))
> at
> com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generateServi
> ceMethodStatements(BasicTagBeginGenerato
r.java(Compiled Code))
> at
> com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generate
> (BasicTagBeginGenerator.java(Compiled Code))
> at org.apache.jasper.compiler.JspParseEventListener
> $GeneratorWrapper.generate(JspParseEventListener.java(Compiled Code))
> at org.apache.jasper.compiler.JspParseEventListener.generateAll
> (JspParseEventListener.java(Compiled Code))
> at
> org.apache.jasper.compiler.JspParseEventListener.endPageProcessing
> (JspParseEventListener.java:292)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:234)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.loadJSP
> (JspServlet.java:963)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
> $JspServletWrapper.loadIfNecessary(JspServlet.java:289)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
> $JspServletWrapper.service(JspServlet.java:326)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile
> (JspServlet.java:694)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service
> (JspServlet.java:792)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService
> (StrictServletInstance.java:110)
> at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service
> (StrictLifecycleServlet.java:174)
> at com.ibm.ws.webcontainer.servlet.ServicingServletState.service
> (StrictLifecycleServlet.java:333)
> at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service
> (StrictLifecycleServlet.java:116)
> at com.ibm.ws.webcontainer.servlet.ServletInstance.service
> (ServletInstance.java:283)
> at
> com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch
> (ValidServletReferenceState.java:42)
> at
> com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch
> (ServletInstanceReference.java:40)
> at
> com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispat
> ch(WebAppRequestDispatcher.java:923)
> at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch
> (WebAppRequestDispatcher.java:528)
> at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward
> (WebAppRequestDispatcher.java:176)
> at org.apache.jasper.runtime.PageContextImpl.forward
> (PageContextImpl.java:498)
> at org.apache.jsp._redirect._jspService(_redirect.java:403)
> at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service
> (HttpJspBase.java:89)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet
> $JspServletWrapper.service(JspServlet.java:364)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile
> (JspServlet.java:694)
> at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service
> (JspServlet.java:792)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService
> (StrictServletInstance.java:110)
> at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service
> (StrictLifecycleServlet.java:174)
> at com.ibm.ws.webcontainer.servlet.IdleServletState.service
> (StrictLifecycleServlet.java:313)
> at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service
> (StrictLifecycleServlet.java:116)
> at com.ibm.ws.webcontainer.servlet.ServletInstance.service
> (ServletInstance.java:283)
> at
> com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch
> (ValidServletReferenceState.java:42)
> at
> com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch
> (ServletInstanceReference.java:40)
> at
> com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispat
> ch(WebAppRequestDispatcher.java:923)
> at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch
> (WebAppRequestDispatcher.java:528)
> at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward
> (WebAppRequestDispatcher.java:176)
> at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward
> (WebAppInvoker.java:79)
> at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook
> (WebAppInvoker.java:201)
> at
> com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocatio
> n(CachedInvocation.java:71)
> at
> com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invok
> e(CacheableInvocationContext.java:114)
> at
> com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI
> (ServletRequestProcessor.java:186)
> at
> com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service
> (OSEListener.java:334)
> at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest
> (HttpConnection.java:56)
> at com.ibm.ws.http.HttpConnection.readAndHandleRequest
> (HttpConnection.java:516)
> at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:362)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:593)
>
>
> ===
>
> However, none of us are getting this same error.
>
> Also, if we compile a war on another machine, and then copy the war over
> to her machine and then install it, the site works fine. So, it doesn't
> seem to be a problem with her websphere install. Rather, it seems to be
> a problem with the war files that are generated on her machine.
>
> I did a comparison of the class file in question that contains the setter
> method for 'name' on a working machine and her machine, and they were
> exactly the same. In fact, comparing the generated war files from her
> machine and another machine, I am not able to find *any* differences
> which could account for this behavior.
>
> However, there are some things BeyondCompare cannot see - for example, if
> there were a subtle difference in the generated byte code for the bean.
> I have confirmed that when compiling on her machine, she uses the same
> JDK we do - sun jdk 1.3.1_08.
>
> I am going to try to take one of the wars generated on her machine and
> try it on a known good machine to see if we can reproduce the error.
> However, in the meantime, does anyone have any idea what might be going
> on?
>
> Is it some sort of capitalization issue? The bean in question is
> referenced as
> <spi:render name= ... >
>
> but in the classfile the setter is
> public void setName(String name)
>
> I found the following post possibly relevant:
> http://groups.google.com/groups?hl=...=UTF-8&threadm=
> 39ddee39.10611788%40news&rnum=5&prev=/groups%3Fq%3D%2522unable%2520to%
> 2520find%2520setter%2520method%2522%26hl
%3Den%26lr%3D%26ie%3DUTF-8%26sa%
> 3DN%26tab%3Dwg
>
> especially this part:
> The problem lies in how JRun and Tomcat find property setter methods
> when they are generating servlets from JSP code. JRun simply writes a
> setXXX(value) line, whereas Tomcat uses beans introspection to find the
> appropriate "set" method.
>
>
> How does websphere find property setter methods? Is there something that
> could *change* how websphere finds property setter methods - specifically
> something in the war or the compiled libraries used by the war?
>
> Any other wacky theories or ideas are welcome. This problem has stumped
> me and I have no idea what else to try.
>
> thanks,
> karl
> karl_travel_no_spam@yahoo.com
>
| |
|
| "Larry Carasco" <larryc@rbasoftware.co.uk> wrote in
news:cbmvsv$8pkg$1@news.boulder.ibm.com:
> Karl, do you have a getter method for "name" which doesn't return a
> String? We encountered something recently which sounds very similar
> which related to having the set and get methods for a given attribute
> which acted upon different types, the get method was in fact
> redundant.
Thanks, but no - in fact, there is no 'getter' method. Just a setter
method.
I have also verified that the setName method of the class in question is
included in the jar file which is in the WEB-INF/lib directory, so it
is there for websphere to read.
Do you have any other theories?
thanks,
Karl
>
> "k" <karl_travel_no_spam@yahoo.com> wrote in message
> news:Xns95154EF7B5Akarltravelnospamyaho@
207.217.125.202...
>
>
>
| |
| George Chorny 2004-06-28, 9:01 am |
| Isnt it that those should come in pairs? Setter and Getter?
Also, do not assume that if you have your jar in Web-INF/lib it's being
loaded... get ClassLoaderViewer Extension for your websphere (search IBM
site for it)
- George C.
k wrote:
[vbcol=seagreen]
> "Larry Carasco" <larryc@rbasoftware.co.uk> wrote in
> news:cbmvsv$8pkg$1@news.boulder.ibm.com:
>
>
> Thanks, but no - in fact, there is no 'getter' method. Just a setter
> method.
>
> I have also verified that the setName method of the class in question is
> included in the jar file which is in the WEB-INF/lib directory, so it
> is there for websphere to read.
>
> Do you have any other theories?
>
> thanks,
> Karl
>
| |
|
| George Chorny <gchorny@ravatech.com> wrote in
news:Q4MDc.24753$OT6.11563401@news4.srv.hcvlny.cv.net:
> Isnt it that those should come in pairs? Setter and Getter?
>
> Also, do not assume that if you have your jar in Web-INF/lib it's
> being loaded... get ClassLoaderViewer Extension for your websphere
> (search IBM site for it)
>
> - George C.
re: pairs - perhaps... however, as I noted below, the site works on
every other machine, windows and solaris, that we have installed it on.
So I don't think the lack of a 'get' method is the problem, or at least
that doesn't seem to pose a problem for other machines. Also, as I
described below, a war file built on another machine seems to work fine
on her machine, so it doesn't seem that her version of websphere is set
up incorrectly. It is only the war-file that she generates on her
machine that are some how bad. But I can't figure out why...
re: classloaderviewer extension - we haven't tried that yet, that is a
good idea. However, what could cause something in WEB-INF/lib to not be
loaded? Is there something in the war-file that could cause that? Is
there some setting I can view somewhere that would help me detect why
that jar might not be loaded?
thanks,
karl
>
> k wrote:
>
>
| |
| Todd Kaplinger 2004-06-28, 9:02 am |
| Did you by chance having multiple setName calls?
public void setName (String s);
public void setName (int i);
k wrote:
> George Chorny <gchorny@ravatech.com> wrote in
> news:Q4MDc.24753$OT6.11563401@news4.srv.hcvlny.cv.net:
>
>
>
>
>
> re: pairs - perhaps... however, as I noted below, the site works on
> every other machine, windows and solaris, that we have installed it on.
> So I don't think the lack of a 'get' method is the problem, or at least
> that doesn't seem to pose a problem for other machines. Also, as I
> described below, a war file built on another machine seems to work fine
> on her machine, so it doesn't seem that her version of websphere is set
> up incorrectly. It is only the war-file that she generates on her
> machine that are some how bad. But I can't figure out why...
>
> re: classloaderviewer extension - we haven't tried that yet, that is a
> good idea. However, what could cause something in WEB-INF/lib to not be
> loaded? Is there something in the war-file that could cause that? Is
> there some setting I can view somewhere that would help me detect why
> that jar might not be loaded?
>
> thanks,
> karl
>
>
>
| |
| dave artus 2004-06-29, 3:22 am |
| Could it be that in the failing case the source files are being
included in the WAR and in the success case they are not? I had
an oddity back in WAS 3.5 days where something like this happened.
Transpired that WAS/Java was trying to compile the source, which was in
the WAR, because the date of the source was not older than the class,
but of course couldn't write the newly compiled class to the WAR.
k wrote:
> George Chorny <gchorny@ravatech.com> wrote in
> news:Q4MDc.24753$OT6.11563401@news4.srv.hcvlny.cv.net:
>
>
>
>
>
> re: pairs - perhaps... however, as I noted below, the site works on
> every other machine, windows and solaris, that we have installed it on.
> So I don't think the lack of a 'get' method is the problem, or at least
> that doesn't seem to pose a problem for other machines. Also, as I
> described below, a war file built on another machine seems to work fine
> on her machine, so it doesn't seem that her version of websphere is set
> up incorrectly. It is only the war-file that she generates on her
> machine that are some how bad. But I can't figure out why...
>
> re: classloaderviewer extension - we haven't tried that yet, that is a
> good idea. However, what could cause something in WEB-INF/lib to not be
> loaded? Is there something in the war-file that could cause that? Is
> there some setting I can view somewhere that would help me detect why
> that jar might not be loaded?
>
> thanks,
> karl
>
>
>
| |
|
| Thanks for all of the suggestions - we finally figured out the problem.
This was rather a rather interesting and mean little bug.
Basically, the root problem was we had another class with the same
name/package in another jar file in WEB-INF/lib - however, this second
copy of the class was a different implementation.
i.e.
WEB-INF/lib/a.jar (contains good class com.foo.A)
WEB-INF/lib/b.jar (contains bad class com.foo.A)
Now, as I mentioned below, we initially thought the problem was with the
..war files, since .war files generated on her machine did not work, while
..war files generated on my machine did (work on her machine that is).
This fact caused me to be blind to the possibility that there were two
instances of the class - because if there were, why did it work on other
machines??
I was thrown a curve ball when I took a .war file generated on her
machine, that did not work on her machine, and installed it on my machine
and did not get the error!
So, I started looking to causes other than differences between the .war
files. What I found was most interesting. Basically, the 'broken'
machine is running a FAT32 filesystem, which returns files in no
particular order - at least when File.filelist() is invoked from java.
My system is NTFS, which returns files in alphabetical order.
So, when websphere goes to load the .jar files on my machine, it loads
them in alphabetical order. When it goes to load them on her machine,
for whatever reason it loads b.jar first, so the bad classes shadow the
good ones.
I think the reason we were able to get *other* .war files to work on her
machine was that the files had different dates or were dropped onto the
hard disk in a different fashion, and thus ended up being sorted in a
different way by FAT32.
So, at the end of the day, this was really our bug, but it was only
revealed by the behavior of a particular hard disk.
It could also be argued that Websphere should be more deterministic about
its library loading. Is there a way to tell websphere in what order to
load in .jar files from WEB-INF/lib?
In any case, thanks for your help, and if this helps someone out there
I'll be pleasantly surprised... 
-karl
dave artus <artusd@uk.ibm.com> wrote in news:cbr6h8$9oni$1
@news.boulder.ibm.com:
> Could it be that in the failing case the source files are being
> included in the WAR and in the success case they are not? I had
> an oddity back in WAS 3.5 days where something like this happened.
> Transpired that WAS/Java was trying to compile the source, which was in
> the WAR, because the date of the source was not older than the class,
> but of course couldn't write the newly compiled class to the WAR.
>
> k wrote:
>
on.[vbcol=seagreen]
least[vbcol=seagreen]
fine[vbcol=seagreen]
set[vbcol=seagreen]
be[vbcol=seagreen]
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generate[vbcol=seagreen]
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generate[vbcol=seagreen]
com.ibm.ws.webcontainer.jsp.compiler.BasicTagBeginGenerator.generate[vbcol=seagreen]
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppD[vbcol=seagreen]
com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppD[vbcol=seagreen]
com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvo[vbcol=seagreen]
com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.[vbcol=seagreen]
2520t[vbcol=seagreen]
2[vbcol=seagreen]
>
>
|
|
|
|
|