James v3 -- JRE 1.3 or JRE 1.4+?

["Noel J. Bergman" <no...@devtech.com>]

> I'm not pushing 1.4.1 in any way.  I'm just saying if we move to the
> JNDI DNS service, we get a perk if the user is running the new JDK.

Ah, I understand.

There are lots of benefits to JDK 1.4.1:

  - JNDI DNS Service
  - JDBC v3
  - Better networking
  - java.nio (too bad NBIO isn't more portable; we should look a SEDA, too)
  - ...

We ought to consider whether we are willing to maintain James v2 for JRE
1.3+ and James v3 for JRE 1.4+.  Considering that James v2 works well, and
James v3 will be a while in development, I have some inclination to suggest
that we adopt JRE 1.4+ for James v3.  On the other hand, there is always
some risk involved in moving raising the JRE required.

Thoughts?

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: James v3 -- JRE 1.3 or JRE 1.4+?

["Noel J. Bergman" <no...@devtech.com>]

> > You talked about exposing javax.sql.DataSource.
> Right, that's how I propose offering db connections to anyone

OK, so then the only code that would know about DBCP or JDBC would be James
internals?  I think we can handle through configuration settings.

> I think just a pooled connection is enough.

I think that is correct for the most part, so lets leave it at that until we
see a need for more.

> I'm not sure [how to make optional use of JDK 1.4]... possibly reflection?

One way would be to use dynamic loading, and isolate JDK 1.4 specific
features in separate classes/packages.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: James v3 -- JRE 1.3 or JRE 1.4+?

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
> You talked about exposing javax.sql.DataSource.  

Right, that's how I propose offering db connections to anyone (the only 
way instead of the Avalon lookup to the mordred pool).

 > Another question is whether
> we need to offer a pool directly, or whether we just need to provide the
> means to get a suitable (pooled) connection?

I think just a pooled connection is enough.  Maybe for monitoring you'd 
want the actual pool, but dunno why else you'd want the pool directly. 
Thoughts?

>>ideally we could use the better exceptions in JDK 1.4 to build richer
> 
> failure
> 
>>messages, but if they're not available, then just skip them and do what
>>we do now. (also similarly if the extra socket options are available,
>>then set them, otherwise ignore them).
> 
> 
> How do you propose coding that?

I'm not sure... possibly reflection?  Again I haven't done the cross-JVM 
version coding in a bit, so I'm rusty on how you would go about doing this.

-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: James v3 -- JRE 1.3 or JRE 1.4+?

["Noel J. Bergman" <no...@devtech.com>]

> I think that may be the overiding factor as if we want Apache to
> use James and they're running FreeBSD without 1.4.

Yes, right now it is FreeBSD 1.3.1, Classic VM, green threads, no JIT.  I
understand that there is a JIT available for FreeBSD, though.

> right now we don't offer any pooling alternatives
> (and the one we offer isn't as good).

You talked about exposing javax.sql.DataSource.  Another question is whether
we need to offer a pool directly, or whether we just need to provide the
means to get a suitable (pooled) connection?

> ideally we could use the better exceptions in JDK 1.4 to build richer
failure
> messages, but if they're not available, then just skip them and do what
> we do now. (also similarly if the extra socket options are available,
> then set them, otherwise ignore them).

How do you propose coding that?

> can rework to support future non-blocking IO

Typically, you just need to invert the handling so that data is pushed into
the actual protocol handler, instead of being pulled.  In most cases, we're
pretty close.

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: James v3 -- JRE 1.3 or JRE 1.4+?

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
> Serge,
> 
> Not sure what is running on nagoya, but Brian had indicated that he'd like
> to be able to run James on FreeBSD, and I don't know when JDK 1.4 will be on
> that platform.

Yeah, I think that may be the overiding factor as if we want Apache to 
use James and they're running FreeBSD without 1.4.  doh!

>>  - JNDI DNS Service
> 
> 
> Not sure how much this practically buys us.  Your thoughts?  Can we make use
> of this optionally?

Yes, during initialization you can specify what DNS servers to use.  If 
there aren't any specified, for < 1.4.1 it defaults to localhost.  For 
 >= 1.4.1, it uses your underlying DNS settings (like /etc/resolv.conf 
or Windows XP network settings).

>>  - JDBC v3
> 
> 
> The primary benefit we want is pooling, for which we can use DBCP, but I
> think we should make sure that someone with JDK 1.4 can substitute JDBC v3
> transparently, so we have to be careful about what interfaces we expose.

Ok, I don't know how you expose it transparently, but we can see.  Maybe 
offer DBCP as a wrapper so you could alternatively just specify your 
own.  Is this really such a big deal?  Right now we don't offer any 
pooling alternatives (and the one we offer isn't as good).

>>  - Better networking
> 
> 
> We can do without it for now.

I haven't done the cross-JDK version stuff in a bit, but ideally we 
could use the better exceptions in JDK 1.4 to build richer failure 
messages, but if they're not available, then just skip them and do what 
we do now. (also similarly if the extra socket options are available, 
then set them, otherwise ignore them).

>>  - java.nio (too bad NBIO isn't more portable; we should look a SEDA,
> 
> too)
> 
> Since java.nio doesn't support TLS, yet, we can't use it anyway.  But we
> should design the handlers as if we were using non-blocking I/O, even though
> we don't switch yet.

Well, Peter and others have much expertise and recent experience working 
on the handlers, so if Peter or however else can rework to support 
future non-blocking IO, I guess that's nice.

> So perhaps we can stay with JDK 1.3, but I think that we ought to keep an
> eye on where things are going, and allow such things as replacing DBCP with
> JDBC v3 transparently.

Def.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: James v3 -- JRE 1.3 or JRE 1.4+?

["Noel J. Bergman" <no...@devtech.com>]

Serge,

Not sure what is running on nagoya, but Brian had indicated that he'd like
to be able to run James on FreeBSD, and I don't know when JDK 1.4 will be on
that platform.

So let's look at the items for JDK 1.4:

>   - JNDI DNS Service

Not sure how much this practically buys us.  Your thoughts?  Can we make use
of this optionally?

>   - JDBC v3

The primary benefit we want is pooling, for which we can use DBCP, but I
think we should make sure that someone with JDK 1.4 can substitute JDBC v3
transparently, so we have to be careful about what interfaces we expose.

>   - Better networking

We can do without it for now.

>   - java.nio (too bad NBIO isn't more portable; we should look a SEDA,
too)

Since java.nio doesn't support TLS, yet, we can't use it anyway.  But we
should design the handlers as if we were using non-blocking I/O, even though
we don't switch yet.

So perhaps we can stay with JDK 1.3, but I think that we ought to keep an
eye on where things are going, and allow such things as replacing DBCP with
JDBC v3 transparently.

What other benefits from JDK 1.4 API changes might be of key interest for
James v3?

	--- Noel


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: James v3 -- JRE 1.3 or JRE 1.4+?

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
> There are lots of benefits to JDK 1.4.1:
> 
>   - JNDI DNS Service
>   - JDBC v3
>   - Better networking
>   - java.nio (too bad NBIO isn't more portable; we should look a SEDA, too)
>   - ...
> 
> We ought to consider whether we are willing to maintain James v2 for JRE
> 1.3+ and James v3 for JRE 1.4+.  Considering that James v2 works well, and
> James v3 will be a while in development, I have some inclination to suggest
> that we adopt JRE 1.4+ for James v3.  On the other hand, there is always
> some risk involved in moving raising the JRE required.
> 
> Thoughts?

I was thinking about this some, specifically your JDBC v3 comment.  The 
thing is though, this only gives us the API, not the driver 
capabilities.  For instance, we've been running JDK 1.4 on our prod 
systems within a few months of when it came out, but the JDBC driver we 
purchased doesn't have the v3 pooling.  Ok, we're cheap and don't want 
to pay for the upgrade, but this is an enterprise-wide license so it 
isn't cheap.

Since we have a pooler readily available (DBCP), and I don't know of any 
other compeling requirement for raising the JRE required.  Sure it'd be 
nice, but that's almost always the case.  I think the only reason we 
even require JDK 1.3 is because of the shutdown-hooks.  I'd almost 
prefer figuring out a way to make that support optional and then support 
JDK 1.2.

-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: James v3 -- JRE 1.3 or JRE 1.4+?

[Kenny Smith <ke...@journalscape.com>]

> We ought to consider whether we are willing to maintain James v2 for 
> JRE 1.3+ and James v3 for JRE 1.4+.  Considering that James v2 works 
> well, and James v3 will be a while in development, I have some 
> inclination to suggest that we adopt JRE 1.4+ for James v3.  On the 
> other hand, there is always some risk involved in moving raising the 
> JRE required.
>
> Thoughts?

I don't personally deal with this headache anymore, but if we leave the 
option to use 1.3 then we leave James open to be used on FreeBSD or 
other non-directly supported platforms that don't have ports yet.

Kenny Smith
JournalScape.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>