Vince,
excellent question, thanks for bringing this up.
I would really love to see other people's opinion. Not only
specification leads but people who really use this in real life
scenarios. Come on, don't be shy :-)
I would even start by asking *if* developers actually want to
evolve/upgrade their existing applications.
One possible answer is to just continue using J2EE 1.4 for a project
that started with it - it will continue to work.
If you are just adding a code and it is relatively isolated from the
existing code maybe you can create a new ejb module and call the
existing code. Then you would only upgrade the J2EE application that
packages the two modules, or create new one - this is a relatively small
task.
If I decided to do a large refactoring and rewrite my app completely to
optimize for future simplicity I may be tempted to switch completely
from ejb 2.x to 3.0. But who can afford to rewrite the whole app?
I agree that mix/match sounds strange. Even though specification allows
it and in principle is should work just fine. I think it would be a
little confusing to work with annotations and xml at the same time.
-pavel
Vince.Kraemer_at_Sun.COM wrote:
> Does anybody have a pointer to what folks should do with their existing J2EE 1.4 code/applications?
>
> What are the migration/evolution best practices?
>
> For example: if I have a J2EE 1.4 ejb-jar and I want to start doing EJB 3.0, what should I do?
>
> a. change the namespace in my existing jar, then rock and roll...
> b. create a new jar for my EJB 3.0 components and "call" back and forth between the two jars...
>
> I would imagine that we don't get to mix-and-match @Entity and CMPs...
>
> What other "gotchas" are there?
>
> vbk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>