You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Matthias Stöckel <Ma...@fztig938.bank.dresdner.net> on 2004/07/05 15:03:57 UTC
JDK 1.3.1 compatibility for cvs-head
Hi,
I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few issues about JDK 1.3.1 compatibility.
- jakarta-bcel-20040329.jar, "NoSuchMethodError" if used with JavaFlow [1].
- groovy-1.0-beta-5.jar, I get a "class file has wrong version 48.0, should be 47.0" during compilation.
- src/java/org/apache/cocoon/acting/HttpCacheAction.java uses the Function Calendar.getTimeInMillis(). For JDK 1.3.1 it is protected.
Can anybode confirm this problems? Could we perhaps agree to use only jars in cocoon-2.1 which have been compiled with a JDK 1.3.1?
Cheers,
Matthias
[1]http://www.mail-archive.com/bcel-dev@jakarta.apache.org/msg00231.html
Re: JDK 1.3.1 compatibility for cvs-head
Posted by Matthias Stöckel <Ma...@fztig938.bank.dresdner.net>.
Joerg Heinicke wrote:
> On 05.07.2004 15:03, Matthias Stöckel wrote:
>
>> Hi,
>>
>> I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few
>> issues about JDK 1.3.1 compatibility.
>>
>> - jakarta-bcel-20040329.jar, "NoSuchMethodError" if used with JavaFlow
>> [1].
>
>
> Are you sure it's the quoted StringBuffer problem? It might also be
> caused by a "wrong" bcel on classpath as we have extended the original one.
I got bcel from cvs and compiled it with 1.3.1 (including the bugzilla patches). Now it works for me. I don't have another jar in the classpath for sure. The problem didn't occur with the Cocoon JavaFlow samples. It happened only with my own application. The stacktrace pointed to the location which I quoted.
>
>> - groovy-1.0-beta-5.jar, I get a "class file has wrong version 48.0,
>> should be 47.0" during compilation.
>
>
> This is a known problem and should be fixed.
Yes, thanks.
>> - src/java/org/apache/cocoon/acting/HttpCacheAction.java uses the
>> Function Calendar.getTimeInMillis(). For JDK 1.3.1 it is protected.
>
>
> This was added only few day ago and should also be fixed. Pier?
Not yet ;-)
Sorry for nagging about 1.3.x compatibility, but unfortunately it isn't so easy to update the JRE in our production environment.
Cheers,
Matthias
Re: JDK 1.3.1 compatibility for cvs-head
Posted by bernhard huber <be...@gmx.at>.
> BTW, anyone knows of any good tool who can generate SHITLOADS of
> requests simulating "real" traffic (maybe from a log file or something
> like it).
i tried once grinder from sourceforge,
it is able to record your clicking, and replay.
You can control the number of processes, and number of thread,
generating real lots of load easily
regards bernhard
--
+++ Jetzt WLAN-Router f�r alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
Re: JDK 1.3.1 compatibility for cvs-head
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 6 Jul 2004, at 17:27, Vadim Gritsenko wrote:
> Antonio Gallardo wrote:
>> Joerg Heinicke dijo:
>>
>>> Yes, we decided to beware 1.3 compatibility as long as we need no
>>> feature of 1.4. The above issues don't make it necessary to switch
>>> to 1.4.
>>>
>>
>> Each day is harder and harder to find the libs compiled for 1.3. I
>> found
>> my self being compiling a lot of jars before commiting an updated jar
>> in
>> Cocoon. And sometimes it is not posible at all. As a sample libs that
>> needs JDBC 3.0 support.
>>
>
> I suggest to wait for SVN migration, create 2.1.6 branch (and keep it
> on JDK 1.3), and switch to JDK 1.4 for 2.2.
+1 ...
We also have some features that we need to backport from 2.2 into 2.1,
given that 2.2 currently fails miserably on VNUNET.COM (tried it
yesterday night, there seems to be something odd locking up requests,
like a synchronization lock).
BTW, anyone knows of any good tool who can generate SHITLOADS of
requests simulating "real" traffic (maybe from a log file or something
like it).
Pier
Re: JDK 1.3.1 compatibility for cvs-head
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Antonio Gallardo wrote:
>Joerg Heinicke dijo:
>
>
>>Yes, we decided to beware 1.3 compatibility as long as we need no
>>feature of 1.4. The above issues don't make it necessary to switch to 1.4.
>>
>>
>
>Each day is harder and harder to find the libs compiled for 1.3. I found
>my self being compiling a lot of jars before commiting an updated jar in
>Cocoon. And sometimes it is not posible at all. As a sample libs that
>needs JDBC 3.0 support.
>
>
I suggest to wait for SVN migration, create 2.1.6 branch (and keep it on
JDK 1.3), and switch to JDK 1.4 for 2.2.
Vadim
Re: JDK 1.3.1 compatibility for cvs-head
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
> Yes, we decided to beware 1.3 compatibility as long as we need no
> feature of 1.4. The above issues don't make it necessary to switch to 1.4.
Each day is harder and harder to find the libs compiled for 1.3. I found
my self being compiling a lot of jars before commiting an updated jar in
Cocoon. And sometimes it is not posible at all. As a sample libs that
needs JDBC 3.0 support.
Best Regards,
Antonio Gallardo.
Re: JDK 1.3.1 compatibility for cvs-head
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.07.2004 15:03, Matthias Stöckel wrote:
> Hi,
>
> I tried to compile a HEAD checkout of cocoon-2.1 and encountered a few
> issues about JDK 1.3.1 compatibility.
>
> - jakarta-bcel-20040329.jar, "NoSuchMethodError" if used with JavaFlow [1].
Are you sure it's the quoted StringBuffer problem? It might also be
caused by a "wrong" bcel on classpath as we have extended the original one.
> - groovy-1.0-beta-5.jar, I get a "class file has wrong version 48.0,
> should be 47.0" during compilation.
This is a known problem and should be fixed.
> - src/java/org/apache/cocoon/acting/HttpCacheAction.java uses the
> Function Calendar.getTimeInMillis(). For JDK 1.3.1 it is protected.
This was added only few day ago and should also be fixed. Pier?
> Can anybode confirm this problems? Could we perhaps agree to use only
> jars in cocoon-2.1 which have been compiled with a JDK 1.3.1?
Yes, we decided to beware 1.3 compatibility as long as we need no
feature of 1.4. The above issues don't make it necessary to switch to 1.4.
Joerg