Excellent Analysis, Sahoo.
On Thu, Sep 25, 2008 at 12:25 PM, Sahoo <Sahoo_at_sun.com> wrote:
> 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
>
>