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
>