On 09/25/08 13:54, Ramesh Babu Mandava wrote:
> Hi Sahu:
>
> Wow! Very tricky problem. Great Analysis!
>
+1
Sahoo,
What a relief!
I'm happy that you were able to nail down this hard to catch bug. This
problem it's solution tells me that, when we write pom.xml we got to be
more careful in what what we want in the target and finally in the build
image.
Regarding the analysis here, looks like I lacked some gray cells to
understand it completely :-)
My question is, why did classpath changed from
javax.servlet/target/javax.servlet-10.0-SNAPSHOT.jar to v3/web/javax.servlet/target/classes
while compiling v3/security/javax.security.jacc. The only relation I see is, v3/security and v3/web/javax.servlet are siblings under v3.
That doesn't mean maven switches classpath while compiling v3/security/javax.security.jacc. You might already knew, that the v3/security/javax.security.jacc
module declared dependency on org.glassfish-javax.servlet-{version}.jar (the OSGified jar). So, it did not use this OSGified jar where it supposed to find
the http/HttpServletRe*.class and, went back to the reactor cache to look for javax.servlet.* package from v3/web.??
In any case, you nailed the bug hard! Congrats.
thanks,
Harsha
>
> Thank you for taking care of this issue. It caused lot of problem for Security team :)
>
> Regards
> -Ramesh
>
>
>
>
>
>> OK, finally, I know what's going on. When I started dtracing
>> syscall::open for javax/servlet/http/HttpServletRequest.java file, I
>> saw
>> that it was being written into javax.servlet/target/classes directory.
>>
>> Who does this? javax.servlet/pom.xml has the following content in it:
>>
>> <resource>
>> <directory>src/main/java</directory>
>> </resource>
>>
>> I have tried to track this pom to its first version in v3 WS and it
>> always had this kind of <resource/>.
>>
>> Because src/main/java is mentioned as a resource dir and there is no
>> filter set, maven-resource-plugin copies all .java files to
>> target/classes dir. Subsequently while compiling javax.security.jacc
>> module in the same reactor, mvn uses javax.servlet/target/classes in
>> the
>> classpath as opposed to
>> javax.servlet/target/javax.servlet-10.0-SNAPSHOT.jar. By default javac
>>
>> uses upto seconds components while comparing files. So, when .class
>> and
>> .java have same timestamp upto seconds, javac can't determine which
>> file
>> is newer and it takes a defensive approach and compiles required
>> servlet
>> classes and puts them in javax.security.jacc/target/classes dir.
>>
>> So, on fast computers we see this problem more often.
>>
>> Thanks to Marina where the problem can be seen quite regularly and I
>> have been able to verify these facts in her environment. e.g., look at
>>
>> the output below in a workspace where we saw this problem and you
>> shall
>> notice that both .class and .java files have same timestamp upto seconds.
>>
>> bash-3.00$ ls -ltrE
>> web/javax.servlet/target/classes/javax/servlet/http/HttpServletRequest.*
>> -rw-r--r-- 1 mvatkina 1050 21628 2008-09-24 14:08:12.020956000
>>
>> -0700 HttpServletRequest.java
>> -rw-r--r-- 1 mvatkina 1050 1420 2008-09-24 14:08:12.759906000
>>
>> -0700 HttpServletRequest.class
>>
>>
>> What is the fix?
>> -----------------
>> Remove the work around we put earlier and change javax.servlet/pom.xml
>>
>> to use a filter to exclude .java files while copying files from
>> src/main/java.
>>
>> Thanks,
>> Sahoo
>>
>> Sahoo wrote:
>>
>>> DTrace helped us getting closer. After around 150 iterations, it
>>> failed once in my spare laptop and the dtrace output is attached
>>>
>> here
>>
>>> with. That file got opened three times. As the stack suggests, first
>>>
>>> by maven-compiler-plugin, then by maven-bundle-plugin and finally by
>>>
>>> maven-jar-plugin. So, it is the compiler-plugin that is responsible
>>>
>>> for creating that servlet class in jacc target dir. Next task is to
>>>
>>> find out why it does so.
>>>
>>> Sahoo
>>>
>>> Sahoo wrote:
>>>
>>>> We are seeing issue #5855 more frequently these days. The root
>>>>
>> cause
>>
>>>> has been identified (see issue tracker). We are yet to identify why
>>>>
>>>> we are having a bad jar file. Attached here with is a dtrace script
>>>>
>>>> that can help us getting closer to finding out the culprit. Those
>>>>
>> who
>>
>>>> are running builds on Solaris, please run the script to help us
>>>> identify the culprit. Run it like this:
>>>>
>>>> 0) Open a terminal
>>>> 1) become super user
>>>> 2) ./trace.d javax/servlet/http/HttpServletRequest.class <fully
>>>> qualified path to workspace (don't use use symbolic links)>
>>>> This prints an error in the beginning, just ignore it.
>>>> Let it run
>>>> Whenever you do a build, it shall watch that process. If the build
>>>>
>>>> produces javax/servlet/http/HttpServletRequest.class in
>>>> $WS/javax.security.jacc/target/classes/ folder, it prints the Java
>>>>
>>>> stack of that process.
>>>>
>>>> Send me the stack if it produces any.
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>