Home » Language IDEs » ServerTools (WTP) » publishing single project
| publishing single project [message #199010] |
Mon, 27 August 2007 16:51  |
Eclipse User |
|
|
|
Originally posted by: natgross.gmailSNIP.com
Hi;
[3.3] Is there a way to publish just a single ejb project without
republishing all? If not why not? (In other words, is there a reason for
this or just a feature that has yet to be done?)
Thanks;
natG
|
|
|
| Re: publishing single project [message #199017 is a reply to message #199010] |
Mon, 27 August 2007 21:32  |
|
Typically J2EE projects are composed of EJB and Web projects.
Web project can act on their own(a JSP calling a Servlet who is doing the
database logic) now EJBs are a little different. EJB projects need a client
calling then in order to work.
Could you explain us why you need to publish only an EJB Project? We are
assuming that the server runtime supports just deploying a EJB project, I
haven't heard of any server runtime supporting this feature (but hey I
haven't traveled to the space yet either). So please let me know which
server runtime you are using.
natG <natgross@gmailSNIP.com> wrote in news:h1cbq4-3b6.ln1
@oldserver.633.oneeasysystem.com:
> a feature that has yet to be don
Regards,
--
Angel Vera
WTP Server Tools Developer
|
|
|
| Re: publishing single project [message #199025 is a reply to message #199017] |
Tue, 28 August 2007 00:15 |
| Eclipse User |
|
|
|
Originally posted by: natgross.gmailSNIP.com
On Mon, 27 Aug 2007 21:32:02 +0000, Angel Vera wrote:
> Typically J2EE projects are composed of EJB and Web projects.
>
> Web project can act on their own(a JSP calling a Servlet who is doing
> the database logic) now EJBs are a little different. EJB projects need a
> client calling then in order to work.
Yes. And that client can be:
1) either *another* web project
2) or a fat client
3) or *another* ejb project.
> Could you explain us why you need to publish only an EJB Project?
Many reasons; some are:
1. Simplicity. No need to package to ear, with another set of descriptors
to maintain, and to get tripped up on. (Especially with ejb 2.1)
1b. The same ejb project (all ejb's within it of course) can be called by
different client apps [mixture of different war's and rich clients]
*simultaneously*. Each of these clients can have a different scope as to
why it is accessing the ejb project.
2. Caching. Entity beans are in the original ejb project sharing the same
cache regardless of client. For apps that I do not want affect the cache,
I can still package the same ejb in an ear and it will have its own
cache. My choice.
3. I have experience on JBoss 4x with ejb 2.1 where I could NOT get an
ear to deploy, but when deployed as two distinct projects, ejb and a war,
it worked! The web.xml is much simpler, no need to tie the servlets to
the ejb's since they are not in the same ear. (The servlet uses jndi of
course to get to the ejb project.) The catch is; you need to deploy the
ejb project first. (ah, that's why I need that feature!)
4. [This might belong to 1 above] With ejb 3 and client injection it is
so eloquently simple. 1) Deploy ejb, 2) inject a call to it in any client
(war, rich, other ejb). Change (and redeploy)in any client front end,
does NOT require stopping or even interrupting (caching etc) the ejb
project on the server!
> We are assuming that the server runtime supports just deploying a EJB
project,
> I haven't heard of any server runtime supporting this feature (but hey I
> haven't traveled to the space yet either). So please let me know which
> server runtime you are using.
The following servers that I personally have done it on are:
1. Glassfish 2.
2. Oracle OC4j 10.x.(They also allow a complete parent-child hierarchy
between deployed projects with additional features like classpath.)
3. JBoss 4.0x
4. Jonas. (That was quite a while ago.)
Maybe the strongest point from all of the above is the continuous uptime
of the original ejb project, unaffected in any client changes and
deployments.
But again, usually one must deploy the projects in a sequence so that
called projects are already deployed when their callers get deployed.
(Hence, even the nice deploy cache of wtp 2, will not suffice.)
Hope this gets me this feature, um, by tomorrow<g>?
natG
|
|
|
| Re: publishing single project [message #199207 is a reply to message #199025] |
Thu, 30 August 2007 17:49 |
|
I suggest you open a bugzilla with this very useful information, to
track this item.
Thanks for the explanation. It helps me understand better what the
community is up to and how to improve our product.
natG <natgross@gmailSNIP.com> wrote in
news:u16cq4-u67.ln1@oldserver.633.oneeasysystem.com:
> On Mon, 27 Aug 2007 21:32:02 +0000, Angel Vera wrote:
>
>> Typically J2EE projects are composed of EJB and Web projects.
>>
>> Web project can act on their own(a JSP calling a Servlet who is doing
>> the database logic) now EJBs are a little different. EJB projects
>> need a client calling then in order to work.
>
> Yes. And that client can be:
> 1) either *another* web project
> 2) or a fat client
> 3) or *another* ejb project.
>
>> Could you explain us why you need to publish only an EJB Project?
>
> Many reasons; some are:
> 1. Simplicity. No need to package to ear, with another set of
> descriptors to maintain, and to get tripped up on. (Especially with
> ejb 2.1)
>
> 1b. The same ejb project (all ejb's within it of course) can be called
> by different client apps [mixture of different war's and rich clients]
> *simultaneously*. Each of these clients can have a different scope as
> to why it is accessing the ejb project.
>
> 2. Caching. Entity beans are in the original ejb project sharing the
> same cache regardless of client. For apps that I do not want affect
> the cache, I can still package the same ejb in an ear and it will have
> its own cache. My choice.
>
> 3. I have experience on JBoss 4x with ejb 2.1 where I could NOT get an
> ear to deploy, but when deployed as two distinct projects, ejb and a
> war, it worked! The web.xml is much simpler, no need to tie the
> servlets to the ejb's since they are not in the same ear. (The servlet
> uses jndi of course to get to the ejb project.) The catch is; you need
> to deploy the ejb project first. (ah, that's why I need that feature!)
>
> 4. [This might belong to 1 above] With ejb 3 and client injection it
> is so eloquently simple. 1) Deploy ejb, 2) inject a call to it in any
> client (war, rich, other ejb). Change (and redeploy)in any client
> front end, does NOT require stopping or even interrupting (caching
> etc) the ejb project on the server!
>
>> We are assuming that the server runtime supports just deploying a EJB
> project,
>> I haven't heard of any server runtime supporting this feature (but
>> hey I haven't traveled to the space yet either). So please let me
>> know which server runtime you are using.
>
> The following servers that I personally have done it on are:
> 1. Glassfish 2.
> 2. Oracle OC4j 10.x.(They also allow a complete parent-child hierarchy
> between deployed projects with additional features like classpath.)
> 3. JBoss 4.0x
> 4. Jonas. (That was quite a while ago.)
>
> Maybe the strongest point from all of the above is the continuous
> uptime of the original ejb project, unaffected in any client changes
> and deployments.
> But again, usually one must deploy the projects in a sequence so that
> called projects are already deployed when their callers get deployed.
> (Hence, even the nice deploy cache of wtp 2, will not suffice.)
>
> Hope this gets me this feature, um, by tomorrow<g>?
> natG
>
Regards,
--
Angel Vera
WTP Server Tools Developer
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:13:24 GMT 2024
Powered by FUDForum. Page generated in 0.02472 seconds |
] 
Search
Help
Register
Login
Home
