[EMAIL PROTECTED] wrote:
> I agree with you that we should look forward to see what is coming in next versions
>of J2EE. But shouldn't we first look at _current_ spec? There are lots of things in
>J2EE 1.2/1.3 (even in EJB 2.0) that JOnAS is miles away from (Where is the new CMP
>model? Where is security services? Where is container interoperability? etc.).
> Before we discuss, what could be in J2EE 1.4 (e. g., what does this relate to an
>EJB-container-only-product?) we should discuss how to implement the _current_ spec.
JOnAS 2.4 is now available, and our first priority is now to provide full EJB 2.0
support.
We are working on it, but don't hesitate to use this mailing list (and the
architecture mailing list) to discuss and contribute...
JOnAS EJB 2.0CMP will ve provided using JORM. Container interoperability using IIOP.
We have also to support the use of JAAS.
> After that, we should discuss on a higher level: Is JOnAS really only an EJB
>container, or will it tend to become a complete server product that is greater than
>J2EE (since SOAP is not mandatory in neither J2EE 1.2 nor 1.3, but only an option
>that COULD come in the next release, that, if we are honest, does not appear before
>the next twelve months). So the question is: quo vadis, JOnAS? I mean, what sense
>does it make to implement SOAP ontop of JOnAS if JOnAS is currently not able to do al!
> l !
> !
> what EJB 2.0 tells? At
> ent, JOnAS is a horizontal layer in the J2EE architecture, with SOAP ontop, it will
>become a totally specialized product. If we plan to make JOnAS a _complete_ server
>product, including top-level protocols like SOAP or HTTPS, we should make a good plan
>how to implement this.
The aim of JOnAS is to answer as much as possible user requirements, and to be as
complete as possible.
The completeness of JOnAS depends on the contributions of the community.
I agree that we have to make good plans to implement this, and it is what we are
trying to do.
We have created an architecture mailing list to discuss these more longer terms
evolution and relations between ObjectWeb components, and I think we can discuss that
on this architecture mailing list.
G�rard Vand�me INRIA Rh�ne-Alpes - SIRAC Project - ObjectWeb Initiative
[EMAIL PROTECTED] phone: +33 4 76 61 54 87
http://www.inrialpes.fr http://www.objectweb.org
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
