[server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

i'm increasingly convinced that the 3.0 codebase contains some
compelling reasons to upgrade. i think it's important to offer an
upgrade path for existing installations including retaining 1.4 JVM
support. this means preserving 1.4 compatibility in the API and
library layers and in any functions that existing in james 2.

i quite fancy experimenting with some stuff (for example OpenJPA) that
requires java 5. IIRC there are already some optional modules which
require a 1.5 JVM but i'd like to use a more regular system. i propose
using module names to allow java5 in the function layer. for example,
openjpa-java5 would act like openjpa-function but would only be
compiled when a 1.5 JVM is used.

any objections?

going forward, this will result in the issue that - given the current
build - new features would only be available atfer downloading the
source and compiling with a 1.5 JVM. i would like to suggest the
following long term strategy: we use the same module system but ship
the phoenix built under 1.4 (without new features) and spring built
under 1.5 (with the new features).

opinions?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Sun, Nov 2, 2008 at 9:11 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Sun, Nov 2, 2008 at 12:43, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> i'm increasingly convinced that the 3.0 codebase contains some
>>> compelling reasons to upgrade. i think it's important to offer an
>>> upgrade path for existing installations including retaining 1.4 JVM
>>> support. this means preserving 1.4 compatibility in the API and
>>> library layers and in any functions that existing in james 2.
>>>
>>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>>> requires java 5. IIRC there are already some optional modules which
>>> require a 1.5 JVM but i'd like to use a more regular system. i propose
>>> using module names to allow java5 in the function layer. for example,
>>> openjpa-java5 would act like openjpa-function but would only be
>>> compiled when a 1.5 JVM is used.
>>>
>>> any objections?
>>>
>>> going forward, this will result in the issue that - given the current
>>> build - new features would only be available atfer downloading the
>>> source and compiling with a 1.5 JVM. i would like to suggest the
>>> following long term strategy: we use the same module system but ship
>>> the phoenix built under 1.4 (without new features) and spring built
>>> under 1.5 (with the new features).
>>>
>>> opinions?
>>
>> IMHO this is an useless waste of time :-)
>> Let's drop Java 2 1.4 and declare java 5 as a requisite.
>>
>> Java 1.4 completed the EOL period 3 days ago: no one should seriusly use
>> java 2 1.4 in any internet exposed machine.
>> Unless we plan to include james in an applet or some old embedded device
>> (and I never read about this scenario in this lists) java 1.4
>> compatibility is useless.
>>
>> Java 5 runtime already provides "an upgrade path for existing
>> installations" by smoothly running java 2 v1.4 code. This is true
>> expecially if you think that JAMES is run in its own virtual machine and
>> is not a component to be run inside old application servers.
>>
>> Once we'll have a working java5 release *if* many users will ask for a
>> java 1.4 solution they can help us figuring it out using
>> retroweaver/translator.
>
> +1
> For a major release, upgrading the required Java version is ok.

seems like we have a reasonable consensus on upgrading the minimum
java version for 3.0 to 1.5

any objections?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Bernd Fondermann <be...@googlemail.com>]

On Sun, Nov 2, 2008 at 12:43, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> i'm increasingly convinced that the 3.0 codebase contains some
>> compelling reasons to upgrade. i think it's important to offer an
>> upgrade path for existing installations including retaining 1.4 JVM
>> support. this means preserving 1.4 compatibility in the API and
>> library layers and in any functions that existing in james 2.
>>
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5. IIRC there are already some optional modules which
>> require a 1.5 JVM but i'd like to use a more regular system. i propose
>> using module names to allow java5 in the function layer. for example,
>> openjpa-java5 would act like openjpa-function but would only be
>> compiled when a 1.5 JVM is used.
>>
>> any objections?
>>
>> going forward, this will result in the issue that - given the current
>> build - new features would only be available atfer downloading the
>> source and compiling with a 1.5 JVM. i would like to suggest the
>> following long term strategy: we use the same module system but ship
>> the phoenix built under 1.4 (without new features) and spring built
>> under 1.5 (with the new features).
>>
>> opinions?
>
> IMHO this is an useless waste of time :-)
> Let's drop Java 2 1.4 and declare java 5 as a requisite.
>
> Java 1.4 completed the EOL period 3 days ago: no one should seriusly use
> java 2 1.4 in any internet exposed machine.
> Unless we plan to include james in an applet or some old embedded device
> (and I never read about this scenario in this lists) java 1.4
> compatibility is useless.
>
> Java 5 runtime already provides "an upgrade path for existing
> installations" by smoothly running java 2 v1.4 code. This is true
> expecially if you think that JAMES is run in its own virtual machine and
> is not a component to be run inside old application servers.
>
> Once we'll have a working java5 release *if* many users will ask for a
> java 1.4 solution they can help us figuring it out using
> retroweaver/translator.

+1
For a major release, upgrading the required Java version is ok.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> i'm increasingly convinced that the 3.0 codebase contains some
> compelling reasons to upgrade. i think it's important to offer an
> upgrade path for existing installations including retaining 1.4 JVM
> support. this means preserving 1.4 compatibility in the API and
> library layers and in any functions that existing in james 2.
> 
> i quite fancy experimenting with some stuff (for example OpenJPA) that
> requires java 5. IIRC there are already some optional modules which
> require a 1.5 JVM but i'd like to use a more regular system. i propose
> using module names to allow java5 in the function layer. for example,
> openjpa-java5 would act like openjpa-function but would only be
> compiled when a 1.5 JVM is used.
> 
> any objections?
> 
> going forward, this will result in the issue that - given the current
> build - new features would only be available atfer downloading the
> source and compiling with a 1.5 JVM. i would like to suggest the
> following long term strategy: we use the same module system but ship
> the phoenix built under 1.4 (without new features) and spring built
> under 1.5 (with the new features).
> 
> opinions?

IMHO this is an useless waste of time :-)
Let's drop Java 2 1.4 and declare java 5 as a requisite.

Java 1.4 completed the EOL period 3 days ago: no one should seriusly use
java 2 1.4 in any internet exposed machine.
Unless we plan to include james in an applet or some old embedded device
(and I never read about this scenario in this lists) java 1.4
compatibility is useless.

Java 5 runtime already provides "an upgrade path for existing
installations" by smoothly running java 2 v1.4 code. This is true
expecially if you think that JAMES is run in its own virtual machine and
is not a component to be run inside old application servers.

Once we'll have a working java5 release *if* many users will ask for a
java 1.4 solution they can help us figuring it out using
retroweaver/translator.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 3, 2008 at 10:04 AM, Danny Angus <da...@apache.org> wrote:
> I agree with Norman, we should possibly poll the users/dev lists but I
> can't believe that 1.4 is still a requirement.

we've POLLed the user list and everyone says 1.5 :-)

perhaps we should find somewhere to record this on the website...

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Danny Angus <da...@apache.org>]

I agree with Norman, we should possibly poll the users/dev lists but I
can't believe that 1.4 is still a requirement.

d.

On Sun, Nov 2, 2008 at 11:42 AM, Norman Maurer <no...@apache.org> wrote:
> Hi Robert,
>
> I'm very limited in free time atm. So I think the descision should be made
> by the active developers. Anyway I think we should drop java 1.4 support at
> all. I see no real reason to support such old / outdated jvm.
>
>
> Cheers,
> Norman
>
> 2008/11/2 Robert Burrell Donkin <ro...@gmail.com>
>
>> i'm increasingly convinced that the 3.0 codebase contains some
>> compelling reasons to upgrade. i think it's important to offer an
>> upgrade path for existing installations including retaining 1.4 JVM
>> support. this means preserving 1.4 compatibility in the API and
>> library layers and in any functions that existing in james 2.
>>
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5. IIRC there are already some optional modules which
>> require a 1.5 JVM but i'd like to use a more regular system. i propose
>> using module names to allow java5 in the function layer. for example,
>> openjpa-java5 would act like openjpa-function but would only be
>> compiled when a 1.5 JVM is used.
>>
>> any objections?
>>
>> going forward, this will result in the issue that - given the current
>> build - new features would only be available atfer downloading the
>> source and compiling with a 1.5 JVM. i would like to suggest the
>> following long term strategy: we use the same module system but ship
>> the phoenix built under 1.4 (without new features) and spring built
>> under 1.5 (with the new features).
>>
>> opinions?
>>
>> - robert
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Norman Maurer <no...@apache.org>]

Hi Robert,

I'm very limited in free time atm. So I think the descision should be made
by the active developers. Anyway I think we should drop java 1.4 support at
all. I see no real reason to support such old / outdated jvm.


Cheers,
Norman

2008/11/2 Robert Burrell Donkin <ro...@gmail.com>

> i'm increasingly convinced that the 3.0 codebase contains some
> compelling reasons to upgrade. i think it's important to offer an
> upgrade path for existing installations including retaining 1.4 JVM
> support. this means preserving 1.4 compatibility in the API and
> library layers and in any functions that existing in james 2.
>
> i quite fancy experimenting with some stuff (for example OpenJPA) that
> requires java 5. IIRC there are already some optional modules which
> require a 1.5 JVM but i'd like to use a more regular system. i propose
> using module names to allow java5 in the function layer. for example,
> openjpa-java5 would act like openjpa-function but would only be
> compiled when a 1.5 JVM is used.
>
> any objections?
>
> going forward, this will result in the issue that - given the current
> build - new features would only be available atfer downloading the
> source and compiling with a 1.5 JVM. i would like to suggest the
> following long term strategy: we use the same module system but ship
> the phoenix built under 1.4 (without new features) and spring built
> under 1.5 (with the new features).
>
> opinions?
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Wed, Nov 12, 2008 at 8:03 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
>
>> OSGi is fine for containing coursely grained services but avoiding
>> spring for configuration and assembly of these services is going to
>> make a *lot* of work.
>
> OSGi is about assembly.

depends on what you mean by assembly ;-)

for example, composing a socket service library, a protocol library
and a repository to create a complete service is the kind of assembly
that OSGi is very strong. OSGi is weaker at the assembly of a service
from finely grained components with an IoC design where the selection
of components is the configuration. spring is strong in this case.

> What do you have in mind for Spring?

1. easy configuration and assembly of components that are already
spring enabled into a service loadable and composable by OSGi (spring
already supports this BTW)

for example, a major part of the work involved in creating a basic
activeMQ based spool manager without spring is creating code to
configure and assemble the component. so use spring for assemble and
finely grained custom configuration then use OSGi to load and compose
the service, providing standardised high level configuration
information.

2. for some allowing easy customisation for deeply IoC services

for example, imap, fail fast and jsieve both use flexible handler
chains to allow developer customization of the components assembled
into the service.

> And configuration can be pretty nicely handled by Commons Configuration if we
> want a configuration object, else we can use DI using annotation (for
> example).

i agree (and had in mind that this is how most of the existing
services would be ported)

but i would prefer to avoid supporting yet another IoC container for
components maintained outside James

>> > > Danny proposes the use of a configuration service that injects
>> > > configuration to the component to be configured, which would
>> > > allow us to use Spring or Commons Configuration or anything else.
>
>> i would go further. i would really like to avoid using a service at
>> all for configuration and assembly. (using a service to load services
>> would create a nasty design knot that would be better avoided.)
>
>> OSGi would allow services to be delivered as self-assembling,
>> self-configuring applications linked to each other by dynamic
>> service references (we use dynamic proxies for these initially).
>> the applications would be able to use spring, commons, hand
>> rolled, pico etc - whatever is most convenient.
>
> Would you please clarify your seeming contradictions above?  From where are
> these self-configuring applications going to get their configuration
> information?  And please remember that we are delivering an application that
> some administrator has to be able to configure in a sane, sensible and
> consistent manner.  So, no, it is not acceptable for each bundle to have its
> own ad hoc means of configuration.  We want the ability to have a consistent
> configuration delivered to the service, and that seemed to be what Danny had
> in mind: a service that read configuration from some source, and delivered
> it to the dependent services.

i think we need to think of two separate cases:

1. configuration of James by an administrator
2. easy extension of James by a developer or deployer

IMHO a standard, simple and fixed configuration is needed for
administrators. the superset of all possible configuration options for
all extensions is just too complex. therefore, finely grained
configuration and assembly information which is not generally
application should not be added to the james configuration file.
whether an option is readable and understandable for a james
adminstrator would be a good test.

so, IMHO each service needs to become a self-contained application
capable of self-assembly and specialist configuration

for example, IMAP (or fail fast SMTP) has some basic qualities such as
ports which all implementations should share. so, these should be
loaded from the james configuration. configuration and assembly
details such as the precise choice of handler chains should not be
loaded from the james configuration but by the service itself as it
boots.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [server] Java 5, Spring And Phoenix

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

Robert Burrell Donkin wrote:

> OSGi is fine for containing coursely grained services but avoiding
> spring for configuration and assembly of these services is going to
> make a *lot* of work.

OSGi is about assembly.  What do you have in mind for Spring?  And
configuration can be pretty nicely handled by Commons Configuration if we
want a configuration object, else we can use DI using annotation (for
example).

> > > Danny proposes the use of a configuration service that injects
> > > configuration to the component to be configured, which would
> > > allow us to use Spring or Commons Configuration or anything else.

> i would go further. i would really like to avoid using a service at
> all for configuration and assembly. (using a service to load services
> would create a nasty design knot that would be better avoided.)

> OSGi would allow services to be delivered as self-assembling,
> self-configuring applications linked to each other by dynamic
> service references (we use dynamic proxies for these initially).
> the applications would be able to use spring, commons, hand
> rolled, pico etc - whatever is most convenient.

Would you please clarify your seeming contradictions above?  From where are
these self-configuring applications going to get their configuration
information?  And please remember that we are delivering an application that
some administrator has to be able to configure in a sane, sensible and
consistent manner.  So, no, it is not acceptable for each bundle to have its
own ad hoc means of configuration.  We want the ability to have a consistent
configuration delivered to the service, and that seemed to be what Danny had
in mind: a service that read configuration from some source, and delivered
it to the dependent services.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 10, 2008 at 9:23 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Norman Maurer asked:

<snip>

>> What's wrong with spring ?
>
> Non-standard and unnecessary.  OSGi is the standard.

OSGi is fine for containing coursely grained services but avoiding
spring for configuration and assembly of these services is going to
make a *lot* of work.

> Danny proposes the use
> of a configuration service that injects configuration to the component to be
> configured, which would allow us to use Spring or Commons Configuration or
> anything else.

i would go further. i would really like to avoid using a service at
all for configuration and assembly. (using a service to load services
would create a nasty design knot that would be better avoided.)

OSGi would allow services to be delivered as self-assembling,
self-configuring applications linked to each other by dynamic service
references (we use dynamic proxies for these initially). the
applications would be able to use spring, commons, hand rolled, pico
etc - whatever is most convenient.

> Regardless, we'll want to go back to plain POJO interfaces.  And that's
> another reason for looking at annotations.

true

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Bernd Fondermann <be...@googlemail.com>]

On Mon, Nov 10, 2008 at 21:01, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Mon, Nov 10, 2008 at 7:54 PM, Norman Maurer <no...@apache.org> wrote:
>> 2008/11/10 Noel J. Bergman <no...@devtech.com>
>
>>> > following long term strategy: we use the same module system but ship
>>> > the phoenix built under 1.4 (without new features) and spring built
>>> > under 1.5 (with the new features).
>>>
>>> -1 to Spring.  +1 for OSGi.
>>>
>>>        --- Noel
>>>
>> What's wrong with spring ?
>
> <ducks>
>
> i think it's important to realise that OSGi and spring are not
> necessarily competing alternatives

+1

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 10, 2008 at 7:54 PM, Norman Maurer <no...@apache.org> wrote:
> 2008/11/10 Noel J. Bergman <no...@devtech.com>

>> > following long term strategy: we use the same module system but ship
>> > the phoenix built under 1.4 (without new features) and spring built
>> > under 1.5 (with the new features).
>>
>> -1 to Spring.  +1 for OSGi.
>>
>>        --- Noel
>>
> What's wrong with spring ?

<ducks>

i think it's important to realise that OSGi and spring are not
necessarily competing alternatives

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[David Jencks <da...@yahoo.com>]

On Nov 10, 2008, at 1:23 PM, Noel J. Bergman wrote:

> Norman Maurer asked:
>
>> Why we would need java 6 ? Which feature you miss in java 5 ?
>
> JSR-223, for one.  Yes, we could backport using BSF, but deployment  
> would be
> easier if we went with Java 6.
>
> Also, "little features include SSLParameters class that encapsulates  
> the
> configuration of SSL connections and new parameters and options for  
> some of
> the security related classes. The changes even filter down to the  
> socket
> level. Socket read timeouts are now fully supported."  Oh, and built- 
> in
> support for LDAP using JAAS.
>
> I am not concerned with the improvements for the GUI, WS, etc., nor  
> even the
> ones that we want, such as in the areas of performance and  
> debugging, since
> anyone can move forward to Java 6.
>
>> What's wrong with spring ?
>
> Non-standard and unnecessary.

Umm, dunno about necessity but OSGI RFC 124

david jencks

>  OSGi is the standard.  Danny proposes the use
> of a configuration service that injects configuration to the  
> component to be
> configured, which would allow us to use Spring or Commons  
> Configuration or
> anything else.
>
> Regardless, we'll want to go back to plain POJO interfaces.  And  
> that's
> another reason for looking at annotations.
>
> 	--- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [server] Java 5, Spring And Phoenix

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

Norman Maurer asked:

> Why we would need java 6 ? Which feature you miss in java 5 ?

JSR-223, for one.  Yes, we could backport using BSF, but deployment would be
easier if we went with Java 6.

Also, "little features include SSLParameters class that encapsulates the
configuration of SSL connections and new parameters and options for some of
the security related classes. The changes even filter down to the socket
level. Socket read timeouts are now fully supported."  Oh, and built-in
support for LDAP using JAAS.

I am not concerned with the improvements for the GUI, WS, etc., nor even the
ones that we want, such as in the areas of performance and debugging, since
anyone can move forward to Java 6.

> What's wrong with spring ?

Non-standard and unnecessary.  OSGi is the standard.  Danny proposes the use
of a configuration service that injects configuration to the component to be
configured, which would allow us to use Spring or Commons Configuration or
anything else.

Regardless, we'll want to go back to plain POJO interfaces.  And that's
another reason for looking at annotations.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Norman Maurer <no...@apache.org>]

2008/11/10 Noel J. Bergman <no...@devtech.com>

> > i quite fancy experimenting with some stuff (for example OpenJPA) that
> > requires java 5.
>
> I want to see annotations, myself.  And favor a move to Java 6, as long as
> we are making the big switch.


Why we would need java 6 ? Which feature you miss in java 5 ?


>
>
> > following long term strategy: we use the same module system but ship
> > the phoenix built under 1.4 (without new features) and spring built
> > under 1.5 (with the new features).
>
> -1 to Spring.  +1 for OSGi.
>
>        --- Noel
>
What's wrong with spring ?


Cheers,
Norman

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 10, 2008 at 6:58 PM, Noel J. Bergman <no...@devtech.com> wrote:

<snip>

>> following long term strategy: we use the same module system but ship
>> the phoenix built under 1.4 (without new features) and spring built
>> under 1.5 (with the new features).
>
> -1 to Spring.  +1 for OSGi.

i don't see the benefit in making this dichotomy

both have different strengths: spring at assembly and configuration of
services from finely grained components, OSGi at dynamic service
containment

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Bernd Fondermann <be...@googlemail.com>]

On Mon, Nov 10, 2008 at 19:58, Noel J. Bergman <no...@devtech.com> wrote:
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5.
>
> I want to see annotations, myself.  And favor a move to Java 6, as long as
> we are making the big switch.

-1 to Java6 ATM. It is not yet available on MacOS, and at least Robert
and I are using Mac.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 10, 2008 at 8:05 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
>>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>>> requires java 5.
>>
>> I want to see annotations, myself.  And favor a move to Java 6, as long as
>> we are making the big switch.
>>
>>> following long term strategy: we use the same module system but ship
>>> the phoenix built under 1.4 (without new features) and spring built
>>> under 1.5 (with the new features).
>>
>> -1 to Spring.  +1 for OSGi.
>
> In my opinion Spring is a framework, OSGi a technology.
> You can create OSGi components/services that internally use spring. You
> probably could create an OSGi container based on the Spring framework.
> They are not alternatives.
>
> BTW, if you want to provide some OSGi stuff for JAMES Server, I think it
> would be very welcome!

been wondering about using dynamic proxies to bridge phoenix to OGSi

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] Java 5, Spring And Phoenix

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman ha scritto:
>> i quite fancy experimenting with some stuff (for example OpenJPA) that
>> requires java 5.
> 
> I want to see annotations, myself.  And favor a move to Java 6, as long as
> we are making the big switch.
> 
>> following long term strategy: we use the same module system but ship
>> the phoenix built under 1.4 (without new features) and spring built
>> under 1.5 (with the new features).
> 
> -1 to Spring.  +1 for OSGi.

In my opinion Spring is a framework, OSGi a technology.
You can create OSGi components/services that internally use spring. You
probably could create an OSGi container based on the Spring framework.
They are not alternatives.

BTW, if you want to provide some OSGi stuff for JAMES Server, I think it
would be very welcome!

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

RE: [server] Java 5, Spring And Phoenix

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

> i quite fancy experimenting with some stuff (for example OpenJPA) that
> requires java 5.

I want to see annotations, myself.  And favor a move to Java 6, as long as
we are making the big switch.

> following long term strategy: we use the same module system but ship
> the phoenix built under 1.4 (without new features) and spring built
> under 1.5 (with the new features).

-1 to Spring.  +1 for OSGi.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org