Remove or change timestamp of javax.servlet source files in gwt-user.jar #3444

Closed
dankurka opened this Issue Jun 10, 2015 · 23 comments

Comments

Projects
None yet
1 participant
@dankurka
Member

dankurka commented Jun 10, 2015

Originally reported on Google Code with ID 3439

Found in GWT Release:
1.6.0

Detailed description:
The 1.6.0 and 1.6.1 versions of gwt-user.jar contain the
source code for the javax.servlet package.
The problem is the source code has a newer timestamp than the class files.
This causes the javax.servlet classes to be recompiled by maven and placed
in the war's WEB-INF/classes directory.
These classes then conflict with the provided servlet-api.jar found in most
application servers.

Can someone fix the deployed jars to either:
1) include class files having a later timestamp than the source files
or
2) contain no javax source code.

The source code might not be required, since the jars for version 1.5.3
didn't include any javax.servlet sources.

(this description was adapted from Will's post explaining the problem in
the gwt group)

Workaround if you have one:
(I use linux)
What worked for me was to update all the timestamps in the jar's
javax.servlet package to the same date as the GWT 1.5.3's classes
timestamps. I then deployed them to my local maven repository, under a new
version "1.6.1-patched".

Script to change timestamps :

---------------------
#!/bin/bash
#

PATH_TO_GWT_USER_JAR=$1

mkdir work
cd work
cp -v $PATH_TO_GWT_USER_JAR .
jar xf gwt-user-1.6.1.jar javax/servlet
touch -mt 200408280906 javax/servlet/*
touch -mt 200408280906 javax/servlet/**/*
jar uf gwt-user-1.6.1.jar javax/servlet/
-------------------------------

You need to tell the script what jar it should modify:
patchGwtJavaxServlet.sh
/home/username/.m2/repository/com/google/gwt/gwt-user/1.6.1/gwt-user-1.6.1.jar

You will then have a /work directory containing gwt-user-1.6.1.jar with
corrected timestamps. You then need to put it on your local repository or
company repository following the standard maven practice, and to update
your pom.xml to use this patched jar.

Links to the relevant GWT Developer Forum posts:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/e0486a1de1f58c06/00bfe80aac3408e6

Reported by neveue on 2009-03-04 12:40:26

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Seems like an easy fix that will have a lot of benefit for Maven users. Sending over

to Scott for a deeper look.

Reported by sumitchandel+legacy@google.com on 2009-03-06 23:17:48

  • Labels added: Category-Build, Type-Defect, Priority-High
Member

dankurka commented Jun 10, 2015

Seems like an easy fix that will have a lot of benefit for Maven users. Sending over

to Scott for a deeper look.

Reported by sumitchandel+legacy@google.com on 2009-03-06 23:17:48

  • Labels added: Category-Build, Type-Defect, Priority-High
@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Fixed in r4951.

Reported by scottb+legacy@google.com on 2009-03-07 00:49:51

  • Status changed: FixedNotReleased
  • Labels added: Milestone-1_6_RC
Member

dankurka commented Jun 10, 2015

Fixed in r4951.

Reported by scottb+legacy@google.com on 2009-03-07 00:49:51

  • Status changed: FixedNotReleased
  • Labels added: Milestone-1_6_RC
@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
still the same bug in the 1.6.4 release !!

Reported by cyril.lakech on 2009-04-23 21:14:35

Member

dankurka commented Jun 10, 2015

still the same bug in the 1.6.4 release !!

Reported by cyril.lakech on 2009-04-23 21:14:35

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
1_6_RC has been released.

Reported by jlabanca+personal@google.com on 2009-05-11 19:55:04

  • Status changed: Fixed
Member

dankurka commented Jun 10, 2015

1_6_RC has been released.

Reported by jlabanca+personal@google.com on 2009-05-11 19:55:04

  • Status changed: Fixed
@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
@Cyril (Comment 4):
I'm using the 1.6.4 release since a few weeks and it works flawlessly for me. I think
the bug was fixed.

------ Details --------
I checked the timestamps in the gwt-user-1.6.4.jar, and the javax/servlet/*
filestamps are indeed correct:
- the .class files all have the modified timestamp: 2008-07-22 02:00:30.000000000 +0200
- the .java files all have the modified timestamp: 2008-07-22 02:00:00.000000000 +0200
Since the .class files have a more recent timestamp than the .java files, the bug we
had in 1.6.1 does not occur anymore.
----End of Details-----

@gwt-team:
While commenting, I'd also like to thank you for fixing this bug. I didn't do it
before because I wanted to avoid spamming the Issue Tracker to simply say "Thanks".
So:
Thanks for fixing this bug promptly and thanks for the great work you do on GWT!

Reported by neveue on 2009-05-14 09:15:50

Member

dankurka commented Jun 10, 2015

@Cyril (Comment 4):
I'm using the 1.6.4 release since a few weeks and it works flawlessly for me. I think
the bug was fixed.

------ Details --------
I checked the timestamps in the gwt-user-1.6.4.jar, and the javax/servlet/*
filestamps are indeed correct:
- the .class files all have the modified timestamp: 2008-07-22 02:00:30.000000000 +0200
- the .java files all have the modified timestamp: 2008-07-22 02:00:00.000000000 +0200
Since the .class files have a more recent timestamp than the .java files, the bug we
had in 1.6.1 does not occur anymore.
----End of Details-----

@gwt-team:
While commenting, I'd also like to thank you for fixing this bug. I didn't do it
before because I wanted to avoid spamming the Issue Tracker to simply say "Thanks".
So:
Thanks for fixing this bug promptly and thanks for the great work you do on GWT!

Reported by neveue on 2009-05-14 09:15:50

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Yes the timestamps problem is fixed. Great ! 

But we still have to filter our compilation because of the java files in this jar...
the compilation of our project compile also the javax servlet java files in our
output dir and in our war... so we got errors at runtime because javax servlet are
already on the application server.

Any idea ? Why do we need those java files in this jar ? in 1.5.3 we did not have
this issue...

Reported by cyril.lakech on 2009-05-14 09:23:05

Member

dankurka commented Jun 10, 2015

Yes the timestamps problem is fixed. Great ! 

But we still have to filter our compilation because of the java files in this jar...
the compilation of our project compile also the javax servlet java files in our
output dir and in our war... so we got errors at runtime because javax servlet are
already on the application server.

Any idea ? Why do we need those java files in this jar ? in 1.5.3 we did not have
this issue...

Reported by cyril.lakech on 2009-05-14 09:23:05

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I would say there's a problem with your tooling if you have a tool that insists on 
recompiling Java files that are in a jar, particularly when the class files are 
already up-to-date.

The source if provided as a convenience for debugging.

Reported by scottb+legacy@google.com on 2009-05-14 16:28:15

Member

dankurka commented Jun 10, 2015

I would say there's a problem with your tooling if you have a tool that insists on 
recompiling Java files that are in a jar, particularly when the class files are 
already up-to-date.

The source if provided as a convenience for debugging.

Reported by scottb+legacy@google.com on 2009-05-14 16:28:15

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I use maven 2 and the gwt maven plugin from codehaus...

Sources should be in another artifact I think, he we want to debug google code we
could add this sources distribution to the classpath... (a gwt-users-sources.jar as
maven does...)

I know that you don't use maven 2 but my context is a very popular enterprise context.

You should have a closer look to this issue. Maybe the solution is just to remove
java files from the jar and change your mind about distribution of the gwt libraries.

Thanks

Reported by cyril.lakech on 2009-05-14 16:37:05

Member

dankurka commented Jun 10, 2015

I use maven 2 and the gwt maven plugin from codehaus...

Sources should be in another artifact I think, he we want to debug google code we
could add this sources distribution to the classpath... (a gwt-users-sources.jar as
maven does...)

I know that you don't use maven 2 but my context is a very popular enterprise context.

You should have a closer look to this issue. Maybe the solution is just to remove
java files from the jar and change your mind about distribution of the gwt libraries.

Thanks

Reported by cyril.lakech on 2009-05-14 16:37:05

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I can confirm that maven insists in compiling the sources for the javax.servlet
package so this is still somewhat of an issue (can be worked around with other maven
plugins but it still is a PITA)

Scott, you say that those java files are provided as a convenience for debugging and
I understand the logic behind that argument but, are you sure that gwt devs would
really go so far as to place break points in javax.servlet.* classes ? Why would they
do that ? (I honestly can't think of any use case where this would be needed)

Reported by diaz.salvador on 2009-06-15 11:19:07

Member

dankurka commented Jun 10, 2015

I can confirm that maven insists in compiling the sources for the javax.servlet
package so this is still somewhat of an issue (can be worked around with other maven
plugins but it still is a PITA)

Scott, you say that those java files are provided as a convenience for debugging and
I understand the logic behind that argument but, are you sure that gwt devs would
really go so far as to place break points in javax.servlet.* classes ? Why would they
do that ? (I honestly can't think of any use case where this would be needed)

Reported by diaz.salvador on 2009-06-15 11:19:07

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Nobody should need to debug javax.servlet as we never need to debug spring, hibernate
or other frameworks internal code...

By convention, a product (like gwt-user) should be provided without the sources in
a
bundle and optionalty with sources in another bundle.

This standrd is not only a maven standard but a best pratice in general. On many
project, you can find a product.zip and a product.src.zip on the download page for
sample.

Maybe there is a problem with my tooling (Eclipse + Maven) and every solution is welcome.

Reported by cyril.lakech on 2009-06-15 12:22:19

Member

dankurka commented Jun 10, 2015

Nobody should need to debug javax.servlet as we never need to debug spring, hibernate
or other frameworks internal code...

By convention, a product (like gwt-user) should be provided without the sources in
a
bundle and optionalty with sources in another bundle.

This standrd is not only a maven standard but a best pratice in general. On many
project, you can find a product.zip and a product.src.zip on the download page for
sample.

Maybe there is a problem with my tooling (Eclipse + Maven) and every solution is welcome.

Reported by cyril.lakech on 2009-06-15 12:22:19

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Issue still present when compiling with maven. Please remove sources that are not 
related to GWT itself.

Reported by zlowred on 2009-07-08 14:58:40

Member

dankurka commented Jun 10, 2015

Issue still present when compiling with maven. Please remove sources that are not 
related to GWT itself.

Reported by zlowred on 2009-07-08 14:58:40

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Issue still present when compiling with maven.
gwt-user in version 1.7.0 is affected too.

I agree with #11 (a product (like gwt-user) should be provided without the sources

in a bundle and optionalty with sources in another bundle), #10 (I think that gwt 
devs wouldn't really go so far as to place break points in javax.servlet.* classes)

and #9 (the solution is just to remove java files from the jar and change your mind

about distribution of the gwt libraries)

Reported by faramir2 on 2009-07-18 16:41:52

Member

dankurka commented Jun 10, 2015

Issue still present when compiling with maven.
gwt-user in version 1.7.0 is affected too.

I agree with #11 (a product (like gwt-user) should be provided without the sources

in a bundle and optionalty with sources in another bundle), #10 (I think that gwt 
devs wouldn't really go so far as to place break points in javax.servlet.* classes)

and #9 (the solution is just to remove java files from the jar and change your mind

about distribution of the gwt libraries)

Reported by faramir2 on 2009-07-18 16:41:52

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
google wants to be near to enterprise project but when we contact them to change their
mind they just add à comment to say we must change our tooling... because sources of
external project are distributed for debbuging convenience... Funny answer! is not
it?

we use eclipse and maven2... No strange tools...  And nobody need to debug javax...
Or You are a javax Dev.

No answer since may from google and this problem reported a long time ago is still
present in gwt 1.7

Now we must use tricky configuration or patched distribution of gwt to work... And
then google ask us to tell our manager that their tools are enterprise ready.

Using a bug tracker should avoid direct mail to change some stuff but here we have
no more choice. we could blog about this bug to buzz it and then we may have a real
solution

I Hope this issue would be really closed for gwt 2.0

Reported by cyril.lakech on 2009-07-18 21:45:29

Member

dankurka commented Jun 10, 2015

google wants to be near to enterprise project but when we contact them to change their
mind they just add à comment to say we must change our tooling... because sources of
external project are distributed for debbuging convenience... Funny answer! is not
it?

we use eclipse and maven2... No strange tools...  And nobody need to debug javax...
Or You are a javax Dev.

No answer since may from google and this problem reported a long time ago is still
present in gwt 1.7

Now we must use tricky configuration or patched distribution of gwt to work... And
then google ask us to tell our manager that their tools are enterprise ready.

Using a bug tracker should avoid direct mail to change some stuff but here we have
no more choice. we could blog about this bug to buzz it and then we may have a real
solution

I Hope this issue would be really closed for gwt 2.0

Reported by cyril.lakech on 2009-07-18 21:45:29

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
It is our policy to ship source files in most cases as they are generally harmless and

often very useful to users.  I fixed the timestamp problem in 1.6.4, as other users

have confirmed.  I do not consider this a GWT issue any longer.  If Maven is rebuilding

class files that are newer than source files, take it up with them.  Or contact the
guy 
who maintains the GWT maven repository and ask him to remove the source files.

Reported by scottb+legacy@google.com on 2009-07-20 03:38:00

Member

dankurka commented Jun 10, 2015

It is our policy to ship source files in most cases as they are generally harmless and

often very useful to users.  I fixed the timestamp problem in 1.6.4, as other users

have confirmed.  I do not consider this a GWT issue any longer.  If Maven is rebuilding

class files that are newer than source files, take it up with them.  Or contact the
guy 
who maintains the GWT maven repository and ask him to remove the source files.

Reported by scottb+legacy@google.com on 2009-07-20 03:38:00

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I've only dabbled with maven a bit, but it seems that if the gwt maven repository servlet-api-2.5.jar
artifact 
(hope I'm using the right term) were replaced with a servlet-api-2.5.jar which did
not have any source files 
(as Scott suggested in comment 15) things would work.

In fact it seems that if you're building a web project which already has servlet-api-2.5.jar
included elsewhere 
that you could simply exclude servlet-api-2.5.jar from the gwt maven repository altogether.
Would those 
projects compile correctly then?

I realize these ideas sound less than ideal from a maven perspective, but having the
source included in a jar is 
standard practice for GWT and in fact extremely useful while debugging. While I may
not necessarily regularly 
set a breakpoint in a servlet class, but I might certainly step through code that lives
there. If nothing else this 
allows me to inspect variables after my code has finished executing to ensure that
my servlets are doing the 
right thing.

Reported by fredsa on 2009-07-21 06:22:43

Member

dankurka commented Jun 10, 2015

I've only dabbled with maven a bit, but it seems that if the gwt maven repository servlet-api-2.5.jar
artifact 
(hope I'm using the right term) were replaced with a servlet-api-2.5.jar which did
not have any source files 
(as Scott suggested in comment 15) things would work.

In fact it seems that if you're building a web project which already has servlet-api-2.5.jar
included elsewhere 
that you could simply exclude servlet-api-2.5.jar from the gwt maven repository altogether.
Would those 
projects compile correctly then?

I realize these ideas sound less than ideal from a maven perspective, but having the
source included in a jar is 
standard practice for GWT and in fact extremely useful while debugging. While I may
not necessarily regularly 
set a breakpoint in a servlet class, but I might certainly step through code that lives
there. If nothing else this 
allows me to inspect variables after my code has finished executing to ensure that
my servlets are doing the 
right thing.

Reported by fredsa on 2009-07-21 06:22:43

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Yes, I can exclude servlet-api-2.5.jar and then compile is successful.

But I do not understand why I must include source files (whose are in provided .jar

file) to my productive/release version of software?

Only problem here is that source and compiled files are provided in one package in

central maven repository, which should be splitted into two files. I don't know who

deliver .jar files to central repo, but that person should change that thing before

uploading (deploying .jar files).

Reported by faramir2 on 2009-07-26 15:53:55

Member

dankurka commented Jun 10, 2015

Yes, I can exclude servlet-api-2.5.jar and then compile is successful.

But I do not understand why I must include source files (whose are in provided .jar

file) to my productive/release version of software?

Only problem here is that source and compiled files are provided in one package in

central maven repository, which should be splitted into two files. I don't know who

deliver .jar files to central repo, but that person should change that thing before

uploading (deploying .jar files).

Reported by faramir2 on 2009-07-26 15:53:55

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
It appears we have the following situation:

1. GWT developers prefer and GWT may require or encourage jar files to contain both

bytecode (*.class) and source (*.java)
2. Maven suggests a practice of separate source and bytecode java. Also maven users

encounter issues with *.java files in servlet-api-2.5.jar
3, Someone in the maven community is responsible for uploading the GWT jars into the

maven central repository.

It seems that the best solution would be as you suggest (in comment 17) for a 
bytecode only version of servlet-api-2.5.jar to be uploaded to the maven repository

instead of the GWT's bytecode + source code version.

My only recommendation is that the bytecode only version of 'servlet-api-2.5.jar' be

given a different name in the maven repository to distinguish it from the original,

e.g. 'servlet-api-2.5-binary.jar'

Reported by fredsa on 2009-07-27 17:02:22

Member

dankurka commented Jun 10, 2015

It appears we have the following situation:

1. GWT developers prefer and GWT may require or encourage jar files to contain both

bytecode (*.class) and source (*.java)
2. Maven suggests a practice of separate source and bytecode java. Also maven users

encounter issues with *.java files in servlet-api-2.5.jar
3, Someone in the maven community is responsible for uploading the GWT jars into the

maven central repository.

It seems that the best solution would be as you suggest (in comment 17) for a 
bytecode only version of servlet-api-2.5.jar to be uploaded to the maven repository

instead of the GWT's bytecode + source code version.

My only recommendation is that the bytecode only version of 'servlet-api-2.5.jar' be

given a different name in the maven repository to distinguish it from the original,

e.g. 'servlet-api-2.5-binary.jar'

Reported by fredsa on 2009-07-27 17:02:22

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
So, I develop mainly on the Mac - the rest of our team is split between Mac and Windows.
And maven doesn't 
try to package up javax.* classes when building our modules in those environments,
so everything was 
working fine.

But on Ubuntu, those javax.* classes do get packaged up. For the life of me, I could
not figure out why I was 
seeing this linkage error when I tried to start the web app.

At the very least, this gotcha should be emphasized in the documentation or release
notes. It's not obvious in 
the least, and many of us are using maven to handle builds.

Reported by celeste.council on 2009-07-27 23:03:50

Member

dankurka commented Jun 10, 2015

So, I develop mainly on the Mac - the rest of our team is split between Mac and Windows.
And maven doesn't 
try to package up javax.* classes when building our modules in those environments,
so everything was 
working fine.

But on Ubuntu, those javax.* classes do get packaged up. For the life of me, I could
not figure out why I was 
seeing this linkage error when I tried to start the web app.

At the very least, this gotcha should be emphasized in the documentation or release
notes. It's not obvious in 
the least, and many of us are using maven to handle builds.

Reported by celeste.council on 2009-07-27 23:03:50

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I'm using Windows Vista to develoop and maven try to package up javax.* classes.
I'm using maven 2.0.9 version. I think that it's not Ubuntu fault.

Reported by faramir2 on 2009-07-28 08:02:39

Member

dankurka commented Jun 10, 2015

I'm using Windows Vista to develoop and maven try to package up javax.* classes.
I'm using maven 2.0.9 version. I think that it's not Ubuntu fault.

Reported by faramir2 on 2009-07-28 08:02:39

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Just got this bug at my ubuntu installation.

With gwt 1.7.0 the same problem.

Have to use this WA
http://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg16016.html

Reported by seqira on 2009-08-03 16:38:37

Member

dankurka commented Jun 10, 2015

Just got this bug at my ubuntu installation.

With gwt 1.7.0 the same problem.

Have to use this WA
http://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg16016.html

Reported by seqira on 2009-08-03 16:38:37

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
"3, Someone in the maven community is responsible for uploading the GWT jars into the

maven central repository."

Who is this person of the maven community ?

I create a new bug http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
because this one is in mode "defect".

Please everyone, vote for these bugs by starring it at the top of the page. Ask
people with the same problem to star those bugs too and blog about this problem.

Reported by cyril.lakech on 2009-08-07 08:29:13

Member

dankurka commented Jun 10, 2015

"3, Someone in the maven community is responsible for uploading the GWT jars into the

maven central repository."

Who is this person of the maven community ?

I create a new bug http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
because this one is in mode "defect".

Please everyone, vote for these bugs by starring it at the top of the page. Ask
people with the same problem to star those bugs too and blog about this problem.

Reported by cyril.lakech on 2009-08-07 08:29:13

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
In just add a blog entry on the web:
http://cyrillakech.blogspot.com/2009/08/gwt-userjar-issue-with-javaxservlet.html

Reported by cyril.lakech on 2009-08-10 22:21:15

Member

dankurka commented Jun 10, 2015

In just add a blog entry on the web:
http://cyrillakech.blogspot.com/2009/08/gwt-userjar-issue-with-javaxservlet.html

Reported by cyril.lakech on 2009-08-10 22:21:15

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member

Reported by rjrjr@google.com on 2011-02-09 00:21:48

  • Labels added: Milestone-1_6-RC
  • Labels removed: Milestone-1_6_RC
Member

dankurka commented Jun 10, 2015

Reported by rjrjr@google.com on 2011-02-09 00:21:48

  • Labels added: Milestone-1_6-RC
  • Labels removed: Milestone-1_6_RC

@dankurka dankurka closed this Jun 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment