Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] [Fwd: WTP 1.5]

Dimitar these are excellent points, that is why I decided to put it to the attention of the greater WTP community.  

My current rough thoughts are:

  • EJB3 is part of JavaEE, and therefore, it is within the scope of WTP  we will have increasing levels of support for it with newer version of wtp.
  • This support will not be a part of 1.5 as we are now in the shutdown phases of this release.
  • Dali project addresses a portion of what was called EJB3, now JPA.  However, it makes sense to review how wtp can best use what is in Dali and what is already in wtp to build the next generation tools for EJBs.  Dali will exit incubation process soon.  At that point we can start discussions on who/how/what/when in the WTP management, planning and architecture groups.
  • XDoclet support will continue.  We will not drop support for earlier versions of J2EE.

Of course, we are always very open to contributions in this area if you have things to offer :-)

I am hoping that we can start addressing some of your concerns in the 2.0 time frame.

--- Begin Message ---
  • From: "Giormov, Dimitar" <dimitar.giormov@xxxxxxx>
  • Date: Fri, 21 Apr 2006 11:54:18 +0200
  • Delivery-date: Fri, 21 Apr 2006 11:59:02 +0200
  • Envelope-to: naci.dai@xxxxxxxxxxxxx
  • Thread-index: AcZlKY3dKc3drSJoTceXARHHCnLEmQ==
  • Thread-topic: WTP 1.5

Hi Naci,


Currently in WTP 1.5 there is no way to create EJB 3.0 beans (no wizards, we couldn’t find any models or adapters). In one of your mails it is said the Dali project will deal with it. However Dali project guys claim that they will deal with ejb persistency only.(see attachments)

So my questions are:

Is there going to be any generic support for EJB 3.0 beans in WTP?

And what is the statement about XDoclet, is it going to dropped for JEE 5.0?



If it is possible for you to share some information about Ejb 3.0 about how it is intended to work in WTP.


Best regards,




Dimitar Giormov
IDE Tools Sofia


Labs Bulgaria

136A Tsar Boris III Blvd.

Bulgaria, Sofia 1608
T +359/2 9157-525
F +359/2 9157-691


--- Begin Message ---
  • From: "Shaun Smith" <shaun.smith@xxxxxxxxxx>
  • Date: Wed, 29 Mar 2006 18:36:34 +0200
  • Thread-index: AcZTb0mw8T5zMdN6T4+AqYnb07jX/A==
  • Thread-topic: [dali-dev] Dali WTP model support for Ejb 3.0
Hi Dimitar,

   Dali is focused on developing EJB 3.0/Java Persistence API Entities which can be used both inside a container and outside in a Java SE environment.  EJB 3.0 Session and Message Driven Beans are going to be supported by WTP as Java EE 5 added.  That's why you're not finding any session bean deployment descriptor support in Dali.  We will be adding support for the JPA persistence.xml and orm.xml mapping files after our 0.5 milestone.

   FYI, I've been building simple EJB 3.0 stateless session beans by hand in WTP 1.0 and had no problems.  I just had to make sure the schema referenced in the ejb-jar.xml referenced the right EJB 3.0 schema and then WTP performs the syntactic validation.


Giormov, Dimitar wrote:

Hi all,


While evaluating Dali project and WTP 1.5 we encountered some difficulties finding information for EMF models for deployment descriptors. I have checked the latest Dali milestone and WTP 1.5. I could not find any information on how these models will be dealt with. How the annotations will be processed (read).

Where are the new EJB 3.0 model properties for example for session beans are?


Thanks and Best regards,




Dimitar Giormov
IDE Tools Sofia


Labs Bulgaria

136A Tsar Boris III Blvd.

Bulgaria, Sofia 1608
T +359/2 9157-525
F +359/2 9157-691


_______________________________________________ dali-dev mailing list dali-dev@xxxxxxxxxxx

--- End Message ---
--- Begin Message ---
Title: wtp-dev Digest, Vol 13, Issue 62

Send wtp-dev mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wtp-dev digest..."

Today's Topics:

   1. Re: WTP 1.5 and XDoclet support (Naci Dai)
   2. RE: Server API change proposal (Konstantin Komissarchik)


Message: 1
Date: Tue, 21 Mar 2006 21:17:53 -0800
From: Naci Dai <naci.dai@xxxxxxxxxxxxx>
Subject: Re: [wtp-dev] WTP 1.5 and XDoclet support
To: "General discussion of project-wide or architectural issues."
Message-ID: <4420DE01.60001@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed


XDoclet is not for EJB3.

Project DALI is dealing specifically with the EJB3 support.  You will
probably get a chance to try it very soon.  I am afraid it will not be
included with the 1.5 due to the short time available.  However, you
will be able to get it separately.  In the longer term, it will be
integrated into the wtp distribution.

> Hi all,
> I have few questions regarding WTP 1.5 and XDoclet support.
> How the XDoclet annotations will be handled in WTP1.5? If an
> application developer  generate EJB 3.0 bean he/she can use  just  JDK
> 5.0 annotations without  ejb-jar xml descriptor and therefore the
> XDoclet is not needed. How the bean wizard will look like in this case?
>         Where I can find what the plans in this direction are?
>         I  tried here 
> _ but found
> nothing relevant
> Thanks and Regards,
> Radoslav
> ------------------------------------------------------------------------
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx


Message: 2
Date: Wed, 22 Mar 2006 06:24:44 -0800
From: "Konstantin Komissarchik" <kosta@xxxxxxx>
Subject: [wtp-dev] RE: Server API change proposal
To: "Ted Bashor" <tbashor@xxxxxxx>, "Thomas Yip" <tyip@xxxxxxx>,
        "General discussion of project-wide or architectural issues."
Cc: Timothy Deboer <deboer@xxxxxxxxxx>, Gorkem Ercan
Content-Type: text/plain; charset="us-ascii"

"registered to module/facet id + server/runtime id"


We should probably utilize the eclipse expressions framework here. We
already have a project property tester for facets. We would have to
write one for the runtime.


For the ordering, I think we can do something similar to what we do for
facets. Each delegate could specify which delegates it depends on. We
could then sort the list in the dependency order. Such a system would be
a lot less fragile than doing it based on an ordinal number manually
assigned to each delegate.


- Konstantin




From: Ted Bashor
Sent: Tuesday, March 21, 2006 6:27 PM
To: Thomas Yip; 'General discussion of project-wide or architectural
Cc: Konstantin Komissarchik; 'Gorkem Ercan'; 'Sachin Patel'; 'Timothy
Subject: RE: Server API change proposal


One thing I would add is that the Publish process and the Archive Export
process should be very, very similar from an extension/api point of


For both processes, I'd suggest that the WTP framework should be based
on running an ordered list of delegates registered to module/facet id +
server/runtime id.  WTP would include some default/reference delegate
implementations - e.g. ones that assemble an EAR, WAR, or EJB in a
directory, ones that deploy to Tomcat, etc.





From: Thomas Yip
Sent: Monday, March 20, 2006 7:01 PM
To: General discussion of project-wide or architectural issues.
Cc: Ted Bashor; Konstantin Komissarchik; Gorkem Ercan; Sachin Patel;
Timothy Deboer
Subject: Server API change proposal



This proposal briefs the limitation we see with current server publish
API, and it suggests a solution. We had a short discussion during a
conference call on Mar 13th, 2006. (mainly around the
ServerBehaviourDelegate). The problem is also related to


Current API

We learned the original design was driven by a need of a very simply
publish mechanism.

1.      an adopter should able to implement a simply delegate and do the
publish work.
2.      publish tasks was intent to be simple task.
3.      most methods can be overridden.


BEA use-cases

We found the current API is not ideal for BEA needs.


We delay much of publish process until user do an explicit publish
action (menu item publish, or Run on Server).


1.      We generates *.java file based on annotation of Java file in
publish time. We trigger project rebuild during process.
2.      We insert information into application descriptors (web.xml,
application.xml) based on files on the project.
3.      Generated artifacts can cause changes to the EAR or other
modules in the same application.
4.      Publish application by application.
5.      Publish failure should be isolated between modules.


For us, the publish process is better described as a 3 steps process:
Assembly (artifact generation), Packaging (we package virtually), and
Distribution (calls JSR-88 to distribute the application to the server).


The current SPI was driven by the need of simple publishing. The publish
process iterates module by a flattend module list (not application by


Because that most methods can be overridden, we can achieve our goal
reasonably well. However, it incurs maintenance risk, because are not
really implementing the delegate's SPI. For example,

1.      if a fix or an enhancement is made to PublishOperation, our
server adapter lag behind, and enhancement will not be supported.
2.      We short circuit a few methods, such as publishModules() (which
is a violate the interface). If any of the methods is called by new code
that we haven't overridden, it causes unexpected behaviour.


Because of the different design goal, we don't implement the full spec
of ServerBehaviourDelegate. While such changes might not be likely, an
adopter should not be required to implement their delegate in a way to
violate the SPI contract.


Required changes

We can eliminate the problem by the following changes:


1.      Introduce another delegate. Let's call it
BaseServerBehaviourDelegate for now. The current ServerBehaviourDelegate
should make extended of BaseServerBehaviourDelegate. Most generic
methods can be push up. (such as state settings, module controls,
resource delta maintaince. But, it leaves out

        a.      code related to published module list, and the kind.
PublishOperation, and
        b.      all the publish methods. Introduce an adapter interface
to indicate PublishOperation is supported.


The changes will maintain compatibility for all current adopter, and the
original design goal. It enables adopter with different needs to have
full control of the publish process.



        a.      Either, makes publish operation optional. Push down
PublsihOperation related code to the original ServerBehaviour Delegate.
        b.      Or, factors out PublishOperation into utility class or
        c.      Or, made PublishOperation not depends on the flatten
module path (IModule[] representing the sub module and its parents).

3.      Introducing another extension point for UI to replace the
hard-coded publishTask page fragment. Move UI for publishOperation as an


A brief study of the code indicated that we should able to implement it
in a way that it doesn't affect existing adopter.


Optional changes

A few optional changes can be introduced to ease the work of an adopter.


1.      Publishing application-by-application is common to many servers.
We might want to introduce another BehaviourDelegate.
2.      Generic server is already use application-by-application
approach. We should look into merging the requirements.
3.      Going further, we can also introduce the 3 steps publish process
for adopter with complicated publish use-case.





Thomas Yip

Senior Software Engineer

BEA Systems

Email: tyip@xxxxxxx    YIM: thomasleaf    Phone: (206) 926-2906   Blog:


"The complexity you remove can never fail." Burt Rutan.





Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
-------------- next part --------------
An HTML attachment was scrubbed...


wtp-dev mailing list

End of wtp-dev Digest, Vol 13, Issue 62

--- End Message ---

--- End Message ---

Back to the top