feedback needed: to-ejb3.0 migration and javaee coding style conversion

Hello All!

We need your feedback on the new feature.
This feature is accessible via "Apply Javaee Style" action
available in editor, project view popup menu
when EJB-related element is edited or selected.

What it does:
- pre 3.0 EJB modules are converted to 3.0.
- EJB 3.0 code can be changed in a number of ways:
1. home/component interfaces can be migrated to a business interface,
project-scoped ejb and non-ejb clients are changed accordingly
2. EJB environment access style can be switched between
injection/lookup
3. XML metadata can be copied/moved to java annotations


Gregory

7 comments
Comment actions Permalink

For one thing, it should be Java EE, not Javaee ;)

The naming is also pretty confusing, it's not a style that's being applied, it's a version migration. Also last time I tried it on some sizable ejb2 beans it hung/took too long to do anything or give feedback, but this was in the earliest EAP. I'll retest with the latest once 5.1.1 is out and I can use the same project files.

0
Comment actions Permalink

Hello Hani,

Hani Suleiman wrote:

For one thing, it should be Java EE, not Javaee ;)
The naming is also pretty confusing, it's not a style that's being
applied, it's a version migration.


It's not only version migration.
That's why it is difficult to find a good name.
It can move metadata to annotations for EJB 3.0 beans/modules and change
environment access (injection/lookup).
Therefore the final name is still under consideration and all
suggestions are welcome :)

Also last time I tried it on some
sizable ejb2 beans it hung/took too long to do anything or give
feedback, but this was in the earliest EAP. I'll retest with the
latest once 5.1.1 is out and I can use the same project files.


How many EJBs/code does the project contain?
Did it hang/take too long to respond on preview generation or
on actual refactoring stage?

Thanks,
Gregory

0
Comment actions Permalink

If you can't find a good name for it, then it is probably not a single task.
If it takes an excessive amount of time to complete then it is also probably not a single task.

Maybe this should be split into three tasks under Refactor->Migrate:

1. J2EE to Java EE 5 EJB version migration
2. metadata (xml to annotation) migration
3. jndi lookup to injection migration with options for setter or construction injection.

AFAIK each of these tasks is independent of one another, so they should be useful separately
anyway.

Tim

0
Comment actions Permalink

Hello Tim!

Tim Haley wrote:

If you can't find a good name for it, then it is probably not a
single task.


It is possible. But please see my considerations below.

> If it takes an excessive amount of time to complete then

it is also probably not a single task.


In the next EAP the tasks will be better separated so there will be
no slowdowns caused by unneeded refactoring.
For example if you do version migration there is no slowdowns
caused by the environment handling code.

Maybe this should be split into three tasks under Refactor->Migrate:

1. J2EE to Java EE 5 EJB version migration

> 2. metadata (xml to annotation) migration
> 3. jndi lookup to injection migration with

options for setter or construction injection.


The first task is too trivial and is not expected to be frequently utilized.
The second and the third are too close to each other
(2 requires 3, especially if XML/annotations merge is required).
I think it is better to have a single entry point with
good defaults and mnemonics than to pollute menu with too similar actions.

AFAIK each of these tasks is independent of one another, so they
should be useful separately anyway.

Tim


Thanks,
Gregory

0
Comment actions Permalink

Gregory,

Your comments sound reasonable. I really haven't looked at Java EE 5 and EJB 3 too much
yet, so I was not sure about how trivial each task would be or the utility of each task
separately.

Thanks for the response,

Tim

0
Comment actions Permalink

I tried this again, and it's equally...surprising as the first time I tried.

To explain my situation:

I have an EJB2 session bean that fronts about 5 entity beans. I'm NOT migrating the session bean, I just select the entity beans. Here are problems I get right off the start:

1) Too long before I see anything, I select the entities I want converted, then there's a freeze for about 30 seconds, then the status bar says '45 references changed' or something like that.

2) I can't uncheck 'keep home interfaces'. Why? The home interface just contains finders. findByPrimary comes for free via EntityManager.find(), and the others can and should all be converted to @NamedQuery inside the entity.

3) Every method is marked with:
@javax.ejb.TransactionAttribute(javax.ejb.TransactionAttributeType.SUPPORTS)
@javax.annotation.security.PermitAll

Since every method has the exact same annotations, these should be specified in the class level, not per method.

4) The conversion is fairly dumb when it comes to ejb2 semantics. For example, ejbRemove() should be converted to:

@PostRemove
public void remove()
{
}

Same for a number of other methods like ejbStore/ejbLoad/ejbPostCreate. If these methods have empty bodies, then they should be silenty deleted. The resultant 3.0 compatible bean should not have any ejb* methods. The create methods should be turned into constructors, and calls to home.create(...) should be flagged/modified to use a constructor.

5) The resultant class should be decoupled from ejb2 completely. It should NOT extend EntityBean. If it's abstract, it should be made concrete.

Basically as it stands right now, all it seems to do is add some trivial annotations which can be done manually within a couple of minutes. None of the hard stuff is covered yet!

0
Comment actions Permalink

Hello Hani,

At the moment there is no Entity 2.1 EJBs to persistent entities migration.

Home interfaces can be removed only for Session EJBs.
When home interface is removed all its clients are fixed accordingly.
Thus the project correctness is preserved.

In case of Entity 2.1 EJBs too complex changes will be needed
to fix client code (EJB and Java), so we decided not to implement this
feature.

Persistence mapping and annotated entity classes can be generated by EJB
module via separate action. This is a work in progress.
It will be up to EJB provider to move the code to EntityManager.


Hani Suleiman wrote:

I tried this again, and it's equally...surprising as the first time I
tried.

To explain my situation:

I have an EJB2 session bean that fronts about 5 entity beans. I'm NOT
migrating the session bean, I just select the entity beans. Here are
problems I get right off the start:

1) Too long before I see anything, I select the entities I want
converted, then there's a freeze for about 30 seconds, then the
status bar says '45 references changed' or something like that.


At the moment there should be progress indicator during usages search.
Unfortunately when the actual refactoring is performed is no progress
indicator right now.

It should be added soon, so there will be no "freeze".

2) I can't uncheck 'keep home interfaces'. Why? The home interface
just contains finders. findByPrimary comes for free via
EntityManager.find(), and the others can and should all be converted
to @NamedQuery inside the entity.

3) Every method is marked with:
@javax.ejb.TransactionAttribute(javax.ejb.TransactionAttributeType.SUPPORTS)
@javax.annotation.security.PermitAll

Since every method has the exact same annotations, these should be
specified in the class level, not per method.


These annotations reflect exactly what you have in ejb-jar.xml.

4) The conversion is fairly dumb when it comes to ejb2 semantics. For
example, ejbRemove() should be converted to:


As far as only entity class and methods are concerned, yes.
The problem is to correctly fix environment-related code and clients.

Basically as it stands right now, all it seems to do is add some
trivial annotations which can be done manually within a couple of
minutes. None of the hard stuff is covered yet!


Session beans and their clients are fully covered.


Gregory

0

Please sign in to leave a comment.