EJB project help

I am going to start playing with EJB 3. I have 0-experience with EJB
(other than readying books about it a few years ago, but no code work).
What is the best way to set-up IntelliJ to handle one of these
projects? I took a look at :
http://www.jetbrains.com/idea/features/ejb_support.html

but I'm a little confused.

What kind of modules do I create and in what order. What is the
relationship between a J2EE module and a EJB module?

5 comments
Comment actions Permalink

EJB3 has nothing to do with the current EJB support, which is purely EJB2. If you want to use EJB3, just create your modules as regular java modules, without any special EJB knowledge in IDEA.

0
Comment actions Permalink

Very good I will do that. I noticed that in the JBoss EJB3 trailblazer
application, they have an ant build script and an IntelliJ .ipr :-P
that is a java module.


Just for background - can you explain how these modules fit together in
the EJB2 world?

Hani Suleiman wrote:

>EJB3 has nothing to do with the current EJB support, which is purely EJB2. If you want to use EJB3, just create your modules as regular java modules, without any special EJB knowledge in IDEA.

>

0
Comment actions Permalink

Very briefly (there are tons of tutorials out there covering this):

A J2EE application consists of modules. Modules are of 3 different types, application clients (eg, swing frontends), web modules (webapps, what web monkeys usually do all day), and ejb modules.

IDEA supports EJB modules and web modules. Both of these are driven by descriptors (ejb-jar.xml, and web.xml respectively), one aspect of IDEA's support is that you can righ click on a module and add relevant entities, and have it update the descriptor accordingly. So for EJB, you can right click and create a new session bean, and IDEA will add it to your ejb-jar.xml. You can also add methods to your session bean implementation, and IDEA will add it to the right interface and to the descriptor, etc. Basically cutting down a lot of the manual work involved.

All of this isn't that relevant for EJB3 because of two reasons:

1) EJB3, as part of Java EE 5, embraces the 'use sane defaults' approach. That means that you don't need to specify everything, most things have a sensible default value. This also does away with most of the interfaces and descriptor hell that exists in EJB2

2) The use of annotations instead of descriptors. That way your source code describes what it does, rather than an external file and the pain of keeping the two in sync.

0
Comment actions Permalink

How do I set-up an EJB2 project in IntelliJ? How do the J2EE
application and the EJB module relate? What goes in each?

Hani Suleiman wrote:

>Very briefly (there are tons of tutorials out there covering this):
>
>A J2EE application consists of modules. Modules are of 3 different types, application clients (eg, swing frontends), web modules (webapps, what web monkeys usually do all day), and ejb modules.
>
>IDEA supports EJB modules and web modules. Both of these are driven by descriptors (ejb-jar.xml, and web.xml respectively), one aspect of IDEA's support is that you can righ click on a module and add relevant entities, and have it update the descriptor accordingly. So for EJB, you can right click and create a new session bean, and IDEA will add it to your ejb-jar.xml. You can also add methods to your session bean implementation, and IDEA will add it to the right interface and to the descriptor, etc. Basically cutting down a lot of the manual work involved.
>
>All of this isn't that relevant for EJB3 because of two reasons:
>
>1) EJB3, as part of Java EE 5, embraces the 'use sane defaults' approach. That means that you don't need to specify everything, most things have a sensible default value. This also does away with most of the interfaces and descriptor hell that exists in EJB2
>
>2) The use of annotations instead of descriptors. That way your source code describes what it does, rather than an external file and the pain of keeping the two in sync.

>

0
Comment actions Permalink

Yeah, one of my co-workers was able to get this going for me.

Create a project - select multiple modules.
Create an EJB module. Select all libraries - set them to be copied and
linked via manifest - export them if they are also used by the web module.
Create a WEB module. Set it to depend on the EJB module. Add any
additional libraries. All libraries that come from the EJB module need
to be marked copy and linked via manifest.
Create J2EE App module. Select the ejb and web module for deployment.
Select .ear to be created and deployed.


Yeah!

Question: Why aren't the EJB and WEB modules defaulted to be deployed?



Norris Shelton wrote:

How do I set-up an EJB2 project in IntelliJ? How do the J2EE
application and the EJB module relate? What goes in each?

>

Hani Suleiman wrote:

>
>> Very briefly (there are tons of tutorials out there covering this):
>>
>> A J2EE application consists of modules. Modules are of 3 different
>> types, application clients (eg, swing frontends), web modules
>> (webapps, what web monkeys usually do all day), and ejb modules.
>>
>> IDEA supports EJB modules and web modules. Both of these are driven
>> by descriptors (ejb-jar.xml, and web.xml respectively), one aspect of
>> IDEA's support is that you can righ click on a module and add
>> relevant entities, and have it update the descriptor accordingly. So
>> for EJB, you can right click and create a new session bean, and IDEA
>> will add it to your ejb-jar.xml. You can also add methods to your
>> session bean implementation, and IDEA will add it to the right
>> interface and to the descriptor, etc. Basically cutting down a lot of
>> the manual work involved.
>>
>> All of this isn't that relevant for EJB3 because of two reasons:
>>
>> 1) EJB3, as part of Java EE 5, embraces the 'use sane defaults'
>> approach. That means that you don't need to specify everything, most
>> things have a sensible default value. This also does away with most
>> of the interfaces and descriptor hell that exists in EJB2
>>
>> 2) The use of annotations instead of descriptors. That way your
>> source code describes what it does, rather than an external file and
>> the pain of keeping the two in sync.
>>
>>

0

Please sign in to leave a comment.