You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2007/05/24 18:02:58 UTC
JAMES v Java 6
Please note that JAMES will not build with Java 6 unless Mordred is removed
or updated. Incompatible changes in JDBC.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Kevin Jackson <fo...@gmail.com>.
> > Right.
> > Also the SSL support does not work with Java6.
Having tried the -version:1.5.0_11 trick suggested to get the SSL
working on Java6 today, some things to note.
- Current james server (SVN_TRUNK) doesn't work with jdk6/java6 (same
couldn't generate secret problem as before)
- using the -version: trick in your launcher script will only work if
you have the version you specify installed see this from
http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html:
-version:release
Specifies that the version specified by release is required by the
class or jar file specified on the command line. If the version of the
java command invoked does not meet this specification and an
appropriate implementation is found on the system, the appropriate
implementation will be used.
release not only can specify an exact version, but can also
specify a list of versions called a version string. A version string
is an ordered list of version ranges separated by spaces. A version
range is either a version-id, a version-id followed by a star (*), a
version-id followed by a plus sign (+) , or two version-ranges
combined using an ampersand (&). The star means prefix match, the plus
sign means this version or greater, and the ampersand means the
logical anding of the two version-ranges. For example:
-version:"1.5.0_04 1.5*&1.5.1_02+"
The meaning of the above is that the class or jar file requires
either version 1.5.0_02, or a version with 1.5 as a version-id prefix
and that is not less than 1.5.1_02. The exact syntax and definition of
version strings may be found in Appendix A of the Java Network
Launching Protocol & API Specification (JSR-56).
For jar files, the usual preference is to specify version
requirements in the jar file manifest rather than on the command line.
See the following NOTES section for important policy information
on the use of this option.
So although the -version:1.5.0+ in the PHOENIX_OPTS works, it still
requires that there are two vms installed (at least from my
understanding of the notes and from what I've observed today).
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Stefano Bagnara <ap...@bago.org>.
Kevin Jackson ha scritto:
>> Right.
>> Also the SSL support does not work with Java6.
>
> Has anyone found out what's causing this problem? I recall it was
> something to do with the available algorithms and some internal change
> from Java5 -> Java6.
I think no one looked at it more deeply. It is tracked here:
http://issues.apache.org/jira/browse/JAMES-782
> It's not great having 2 vms on our server (Java5 for james, and Java6
> for tomcat)
As suggested in a comment to that issue, you can tell java6 to run in
java5 compatible mode using "-version:1.5" in your launch script.
Tell us if it works for you too, and please comment on the JIRA issue
about your findings.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Kevin Jackson <fo...@gmail.com>.
> Right.
> Also the SSL support does not work with Java6.
Has anyone found out what's causing this problem? I recall it was
something to do with the available algorithms and some internal change
from Java5 -> Java6.
It's not great having 2 vms on our server (Java5 for james, and Java6
for tomcat)
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Please note that JAMES will not build with Java 6 unless Mordred is removed
> or updated. Incompatible changes in JDBC.
>
> --- Noel
Right.
Also the SSL support does not work with Java6.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Norman Maurer <no...@apache.org>.
Stefano Bagnara schrieb:
> Jukka Zitting ha scritto:
>
>> Hi,
>>
>> On 5/24/07, Noel J. Bergman <no...@devtech.com> wrote:
>>
>>> Please note that JAMES will not build with Java 6 unless Mordred is
>>> removed
>>> or updated. Incompatible changes in JDBC.
>>>
>> I checked that and the problem is
>> org.apache.james.util.mordred.PoolConnEntry class that implements
>> java.sql.Connection. Just adding dummy placeholders for the new
>> methods in JDBC 4 doesn't solve the problem due to a reference to the
>> new SQLXML interface.
>>
>> How about using commons-dbcp for that functionality? The
>> o.a.j.util.mordred.JdbcDataSource class could even be kept as a facade
>> for commons-dbcp for full backwards compatibility with existing
>> configurations.
>>
>
> IMO in trunk we can even remove mordred at all. It is deprecated stuff.
>
> In our config.xml we wrote this since at least JAMES Server 2.2.0
> (meaning 3 years ago): "James has previously used an in-house connection
> pool, Mordred. Mordred is being deprecated in favor of Jakarta Commons
> DBCP."
>
> I'm +1 to remove mordred at all in trunk (after tagging because before
> this change trunk is backward compatible to 2.3.1, instead after this
> change we are no more 100% compatible).
>
> Stefano
>
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Bernd Fondermann <be...@googlemail.com>.
On 5/27/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin ha scritto:
> > tagging is unnecessary with subversion. subversion uses universal
> > version numbers and every commit is atomic. all that's needed is a
> > document recording incompatible changes (using stefano's definition).
>
> IMHO the tag is the simpler way to document this ;-)
> Btw, I'm fine with any other record.
>
> > personally speaking, i think that deleting mordred is unnecessary at
> > this stage given the new modular build. i can very easily factor
> > mordred into a separate optional module which will only be built when
> > using java 5 or less. once this is done, we can switch the default
> > configuration (and update the changes document with the version
> > number).
> >
> > i'm currently working on refactoring and modularisation. if there's a
> > consensus that this is the right approach, i'd be happy to execute.
>
> +1 As we have an "assignee" then I agree that this is the best solution.
> I simply wanted to avoid deciding a solution with no assignee. Mordred
> is deprecated and I won't work to keep it updated. If someone do, then
> I'm really happy ;-)
+1
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin ha scritto:
> tagging is unnecessary with subversion. subversion uses universal
> version numbers and every commit is atomic. all that's needed is a
> document recording incompatible changes (using stefano's definition).
IMHO the tag is the simpler way to document this ;-)
Btw, I'm fine with any other record.
> personally speaking, i think that deleting mordred is unnecessary at
> this stage given the new modular build. i can very easily factor
> mordred into a separate optional module which will only be built when
> using java 5 or less. once this is done, we can switch the default
> configuration (and update the changes document with the version
> number).
>
> i'm currently working on refactoring and modularisation. if there's a
> consensus that this is the right approach, i'd be happy to execute.
+1 As we have an "assignee" then I agree that this is the best solution.
I simply wanted to avoid deciding a solution with no assignee. Mordred
is deprecated and I won't work to keep it updated. If someone do, then
I'm really happy ;-)
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/25/07, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
> > Stefano Bagnara wrote:
> >
> >> I'm +1 to remove mordred at all in trunk (after tagging because before
> >> this change trunk is backward compatible to 2.3.1, instead after this
> >> change we are no more 100% compatible).
> >
> > How do you figure? Trunk is not compatible with 2.3.x due to the changes in the deployment descriptor. And that's the only change here. Someone would need to replace a single token in the configuration file. There is no code level issue.
>
> Current "compatibility" between 2.3.1 and trunk is defined as: storage
> compatibility + config.xml compatibility. This mean that we tried to
> have james trunk working "as is" with a 2.3.1 config.xml
sounds reasonable
> We never declared compatibility at code level for trunk vs v2.3.
cool
> > I'm not sure that we have any need for a tag. If someone needs mordred, it exists in other tags and branches essentially unchanged from its current state. The only difference is the removal of the JDBC 3 comments.
>
> The tag is not about mordred but about config.xml + storage
> compatibility between trunk and v2.3. Btw I don't care too much about
> this. I remember what is the release that break that compatibility. I
> just think it is a good practice to tag source tree before breaking
> compatibility.
tagging is unnecessary with subversion. subversion uses universal
version numbers and every commit is atomic. all that's needed is a
document recording incompatible changes (using stefano's definition).
personally speaking, i think that deleting mordred is unnecessary at
this stage given the new modular build. i can very easily factor
mordred into a separate optional module which will only be built when
using java 5 or less. once this is done, we can switch the default
configuration (and update the changes document with the version
number).
i'm currently working on refactoring and modularisation. if there's a
consensus that this is the right approach, i'd be happy to execute.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
>
>> I'm +1 to remove mordred at all in trunk (after tagging because before
>> this change trunk is backward compatible to 2.3.1, instead after this
>> change we are no more 100% compatible).
>
> How do you figure? Trunk is not compatible with 2.3.x due to the changes in the deployment descriptor. And that's the only change here. Someone would need to replace a single token in the configuration file. There is no code level issue.
Current "compatibility" between 2.3.1 and trunk is defined as: storage
compatibility + config.xml compatibility. This mean that we tried to
have james trunk working "as is" with a 2.3.1 config.xml
We never declared compatibility at code level for trunk vs v2.3.
> I'm not sure that we have any need for a tag. If someone needs mordred, it exists in other tags and branches essentially unchanged from its current state. The only difference is the removal of the JDBC 3 comments.
The tag is not about mordred but about config.xml + storage
compatibility between trunk and v2.3. Btw I don't care too much about
this. I remember what is the release that break that compatibility. I
just think it is a good practice to tag source tree before breaking
compatibility.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v Java 6
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I'm +1 to remove mordred at all in trunk (after tagging because before
> this change trunk is backward compatible to 2.3.1, instead after this
> change we are no more 100% compatible).
How do you figure? Trunk is not compatible with 2.3.x due to the changes in the deployment descriptor. And that's the only change here. Someone would need to replace a single token in the configuration file. There is no code level issue.
I'm not sure that we have any need for a tag. If someone needs mordred, it exists in other tags and branches essentially unchanged from its current state. The only difference is the removal of the JDBC 3 comments.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Stefano Bagnara <ap...@bago.org>.
Jukka Zitting ha scritto:
> Hi,
>
> On 5/24/07, Noel J. Bergman <no...@devtech.com> wrote:
>> Please note that JAMES will not build with Java 6 unless Mordred is
>> removed
>> or updated. Incompatible changes in JDBC.
>
> I checked that and the problem is
> org.apache.james.util.mordred.PoolConnEntry class that implements
> java.sql.Connection. Just adding dummy placeholders for the new
> methods in JDBC 4 doesn't solve the problem due to a reference to the
> new SQLXML interface.
>
> How about using commons-dbcp for that functionality? The
> o.a.j.util.mordred.JdbcDataSource class could even be kept as a facade
> for commons-dbcp for full backwards compatibility with existing
> configurations.
IMO in trunk we can even remove mordred at all. It is deprecated stuff.
In our config.xml we wrote this since at least JAMES Server 2.2.0
(meaning 3 years ago): "James has previously used an in-house connection
pool, Mordred. Mordred is being deprecated in favor of Jakarta Commons
DBCP."
I'm +1 to remove mordred at all in trunk (after tagging because before
this change trunk is backward compatible to 2.3.1, instead after this
change we are no more 100% compatible).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: JAMES v Java 6
Posted by "Noel J. Bergman" <no...@devtech.com>.
Jukka Zitting wrote:
> Noel J. Bergman <no...@devtech.com> wrote:
> > Please note that JAMES will not build with Java 6 unless Mordred
> > is removed or updated. Incompatible changes in JDBC.
> I checked that and the problem is
> org.apache.james.util.mordred.PoolConnEntry class that implements
> java.sql.Connection.
I wasn't going into details, but yes, that leads you to the incompatible changes.
> How about using commons-dbcp for that functionality? The
> a.j.util.mordred.JdbcDataSource class could even be kept
> as a facade for commons-dbcp for full backwards
We have been telling people to switch to DBCP for years, and it is just a matter of changing one token in the configuration file. Mordred has been much better tested than DBCP *with JAMES*, but its time that we remove mordred from trunk, and force ourselves to make sure that DBCP works properly for us.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 5/24/07, Noel J. Bergman <no...@devtech.com> wrote:
> Please note that JAMES will not build with Java 6 unless Mordred is removed
> or updated. Incompatible changes in JDBC.
I checked that and the problem is
org.apache.james.util.mordred.PoolConnEntry class that implements
java.sql.Connection. Just adding dummy placeholders for the new
methods in JDBC 4 doesn't solve the problem due to a reference to the
new SQLXML interface.
How about using commons-dbcp for that functionality? The
o.a.j.util.mordred.JdbcDataSource class could even be kept as a facade
for commons-dbcp for full backwards compatibility with existing
configurations.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: JAMES v Java 6
Posted by Norman Maurer <no...@apache.org>.
Thx for the info :-)
bye
Norman
Noel J. Bergman schrieb:
> Please note that JAMES will not build with Java 6 unless Mordred is removed
> or updated. Incompatible changes in JDBC.
>
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
> !DSPAM:1,4655b75779385358399506!
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org