Home > Archive > Java Beans > February 2005 > Do all vendors' share basic j2ee libs (ejb-api.jar, servlet.jar,
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Do all vendors' share basic j2ee libs (ejb-api.jar, servlet.jar,
|
|
|
| Hi;
I am trying to build some generic j2ee-related Ant scripts that need the
j2ee jars in the classpath. Although, I have no problem with different
versions for 1.3 and 1.4, but if I need different jars *per server* and
on top of that *per ide vendor*, then I have a real problem.
Ideally, (well, not SO ideal) I hope that the basic j2ee jars are all
the same, with additional vendor specific libs for clients.
I regularly work with JBoss (3x and 4x), JoNaS, and Sun's ri.
As for the ide, I use Eclipse/MyEclipse, Eclipse/JbossIDE, and
Eclipse/Lomboz. Other ide's are also used but not regularly. (Maybe, if
I can get some uniform scripts working across various ide's...)
Although, XDoclet has eased my work, I'm looking to further automate
many aspects to a custom environment.
Thank you all.
-nat
| |
| John C. Bollinger 2005-02-01, 3:59 pm |
| natG wrote:
> Hi;
> I am trying to build some generic j2ee-related Ant scripts that need the
> j2ee jars in the classpath. Although, I have no problem with different
> versions for 1.3 and 1.4, but if I need different jars *per server* and
> on top of that *per ide vendor*, then I have a real problem.
> Ideally, (well, not SO ideal) I hope that the basic j2ee jars are all
> the same, with additional vendor specific libs for clients.
>
> I regularly work with JBoss (3x and 4x), JoNaS, and Sun's ri.
> As for the ide, I use Eclipse/MyEclipse, Eclipse/JbossIDE, and
> Eclipse/Lomboz. Other ide's are also used but not regularly. (Maybe, if
> I can get some uniform scripts working across various ide's...)
>
> Although, XDoclet has eased my work, I'm looking to further automate
> many aspects to a custom environment.
The API is specified, but the jar names are not, and in practice there
is no universal convention. You do seem to be over complicating it a
bit though: I don't see a point to worrying about per-IDE jars, per
vendor jars, or per-J2EE-version jars. You should be using whatever
jars are required by the target app server or testing framework. These
will contain a complete implementation of the supported version of the
J2EE API, plus any relevant additional API provided by that app server.
John Bollinger
jobollin@indiana.edu
| |
|
| John C. Bollinger wrote:
> natG wrote:
>
>
>
> The API is specified, but the jar names are not, and in practice there
Interesting. Suppose I compile (vanilla ejb's and servlets) against
vendor A's jars, is it then ok to deploy in Vendor B's app server?
> is no universal convention. You do seem to be over complicating it a
> bit though: I don't see a point to worrying about per-IDE jars, per
> vendor jars, or per-J2EE-version jars.
This simplification is great news! I do wonder why though, the ide
wizards prompt for j2ee version, and include a *different api set*
pending on this. They force me to specify 1.3/1.4 up front when starting
a new project.
> You should be using whatever jars are required by the target app server
This simplification is great, (but please clarify the compile/deploy
question above).
> or testing framework.
Whoops. Is this a monkey wrench?
> These will contain a complete implementation of the supported version of
> the J2EE API, plus any relevant additional API provided by that app server.
At the moment, I'll be happy to get the common api transparently working.
The only additional api I currently need relates to naming/jndi, and
should no be a real problem for my needs, at the moment.
> John Bollinger
> jobollin@indiana.edu
Thank you much.
-nat
| |
| John C. Bollinger 2005-02-01, 8:58 pm |
| natG wrote:
> John C. Bollinger wrote:
>
>
> Interesting. Suppose I compile (vanilla ejb's and servlets) against
> vendor A's jars, is it then ok to deploy in Vendor B's app server?
So long as you have not directly used any extensions to J2EE that may be
provided by vendor A, yes. This is a general Java binary compatibility
issue. Binary-level class compatibility is not a big portability issue
with J2EE, although there *is* the question of server-specific
deployment information.
>
> This simplification is great news! I do wonder why though, the ide
> wizards prompt for j2ee version, and include a *different api set*
> pending on this. They force me to specify 1.3/1.4 up front when starting
> a new project.
Because J2EE 1.4 offers API features not included in J2EE 1.3. If you
target J2EE 1.4 then you need an API definition that corresponds. On
the other hand, if you target 1.3 then using API definitions that
exclude all the new features of 1.4 is an easy way to ensure that you do
not inadvertently make use of any of those features.
>
> This simplification is great, (but please clarify the compile/deploy
> question above).
>
> Whoops. Is this a monkey wrench?
Probably not. I was think of a hypothetical standalone testing
framework for J2EE components (i.e. one that does not run inside a
separate J2EE server). Such a framework would need to provide its own
J2EE implementation just like a more typical J2EE container does, so
it's all the same thing. A test framework running inside a separate
J2EE container should expect the application under test to use the
container's J2EE implementation.
John Bollinger
jobollin@indiana.edu
| |
|
| John C. Bollinger wrote:
> natG wrote:
>
<snip>[color=darkred]
> John Bollinger
> jobollin@indiana.edu
Thank you very much.
-nat
|
|
|
|
|