Hi Sahu:
Wow! Very tricky problem. Great Analysis!
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
>