Do you think anybody has fixed it? :(
-marina
Sahoo 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
>