Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Re: Annotated bean/servlet creation work for M3

Hi John,

I will chekin the EJB wizards and generator in the next couple of days. 

-I have been playing with the idea of using an incremantal project builder (i.e. form the scripts/run xdoclet).  The problem is that without introspecting the code, it is hard to tell if the delta is "annotated" ejb/servlet.  And if we do not introspect we endup doing lot of code generation when we really do not have to.  (i.e. when we save/insert/modify other java code)

-A manual action is fine but not very convenient and intuitive.  Developer always needs to run it and keep track of what has been changed, but it is easy to do.

-Finally, I have been trying to use the IBM Wizard Framework by example (subclassing from J2EEArtifact operations/models)   - it is slow learning.  Looking at the servlet wizard will help.


At 11:14 PM 2/3/2005, John Lanuti wrote:

Hey Naci,

Haven't heard from you in awhile...

I went ahead and finished up our end of the servlet wizard and annotated servlet creation.  For now, the only tagset we use is xdoc.  This code is
released to head.  So, you will see the servlet wizard and xdoc filled servlets being created for web projects.  The only thing we need to synchronize
is the addition of your xdoc builder. 



We need to figure out how we add this to a web project and if it it will really be a builder or an action you need
to invoke via a context menu.  So, let me know.  All of this should be in tonight's nightly build.  We should probably get with Chuck on deciding about
the module creation and addition of potential xdoc builder.  Once we have a scenario for consumers, we can post this function addition to wtp-dev.

Hope all is well!

John Lanuti
Software Engineer, IBM Rational
jlanuti@xxxxxxxxxx
t/l 441-7861

"Well, in the end, my friend, we will all be together again."  -Of A Revolution
"I'll be awful sometimes, weakened to my knees, but I'll learn to get by on the little victories."  - Matt Nathanson



Chuck Bridgham/Raleigh/IBM

01/28/2005 02:13 PM
To
Naci Dai <naci.dai@xxxxxxxxxxxxx>
cc
David M Williams/Raleigh/IBM@IBMUS, John Lanuti/Raleigh/IBM@IBMUS, Arthur Ryman <ryman@xxxxxxxxxx>
Subject
Re: [wtp-dev] Re: Annotated bean/servlet creation work for M3Link



Hi Naci,

My responses are below.....

Thanks - Chuck

Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)



Naci Dai <naci.dai@xxxxxxxxxxxxx>

01/28/2005 12:21 PM
To
Chuck Bridgham/Raleigh/IBM@IBMUS
cc
Arthur Ryman <ryman@xxxxxxxxxx>, John Lanuti/Raleigh/IBM@IBMUS, David M Williams/Raleigh/IBM@IBMUS
Subject
Re: [wtp-dev] Re: Annotated bean/servlet creation work for M3





Chuck,

thanks for the response.

a) Use MOFJ2EE instead of our EMF models. Chuck says we will access them from natures (i.e. nature.getEjbModule()...).
               My earlier example of Nature access to the model, was a simple example that could be used today without any of the flexible project support .
Eventually if multiple modules exist within a project, a ModuleCore nature will help identify and load the seperate EMF module models.


Chuck does this mean that we can support multiple models for an EJB?  How does ModuleCore nature will determine what EMF model to use (i.e. is there an extension point for this)?
<cdb>Maybe I'm not following here...   We currently have one EMF model that represent all the ejb.xml(DD) elements.  And one instance of these models per "Module".  To keep the models in sync we need to share this instance, and this model is serialized out to the ejb.xml file  Michael Elder sent out the current status of the flexible projects....   The actual api is still being worked out, the model does have a notion of "ModuleType" where specific visitor classes will be used to load EMF resource with the correct DD URI. </cdb>


Today, seperate Nature instances are used for each module project, and api exists for loading the EMF model from the deployment descriptor. So it is true before you process the java classes, and create a DD file, our model can't load.  We don't have a direct EMF model mapping to the annotations. -

I guess, WebSphere has xmi descriptions for EJBs :-).   Do you recommend that we make this our general approach (i.e. save the xmi model under the meta-inf as an xmi file)
<cdb> I was just stating that the annotations don't have an EMF model.  The xmi files mentioned above are for WAS specific extensions and bindings to the DD models.  Its not clear to me we need any additional metadata stored?</cdb>

The xdoclet tag sets are defined for UI purposes.  It gives us the ability to show the content assist in the java editor.
The ejb tag set is defined in org.eclipse.jst.j2ee.ejb and the servlet tag set is defined in org.eclipse.jst.j2ee.ejb.


[John]  I guess these have been hand-coded into the plugin.xml.  I would like to do the following things:

a) Create a new extension point to register alternate tag sets: (for ejbs/web/ o-r mapping etc.)  This will can be a step towards  JSR-175 support
b) Provide an API to choose the preferrred tag sets.
c) Xdoclet tag sets should be generated (plugin.xml that contains the tagset), or we should be able to this dynamically by choosing the xdoclet runtime (i.e. jars for module contain server runtime tags, and server runtime providers often change/update them).  
<cdb> The tagsets provided simply define the xdoclet sets for ejb and web.  Additional tagsets could be defined by anyone using the same extension points (especially if they are additive like o-r mapping).
Preferred/Alternate tagsets would be useful, but can probably wait until post R1...  I think we need to set the bar low, and target xdoclet only for R1.    
I'm not familiar with the possibility of dynamically loading the tagset definitions - that sounds like a cool idea, but maybe can be a lower priority? </cdb>


The tagsets API should not be statis we should be able generate and cache them for a workspace.  (i.e. choose an xdoclet version, create the tagsets for it and cache it to for a workspace for better performance).
<cdb>   I think the existing Tagset are sharable within the workbench...  but maybe you are referring to the dynamic tagset enhancement above?</cdb>

This is where I would like to go.

Any comments?

<cdb>How far are you with the EJB Creation wizard?  We would love to start testing, but we haven't seen any code committed?   Maybe we should start a weekly call(or Bi-weekly) to get some of this cleared up?

Also - Maybe a question for anyone....   Whats happening with JBOSS?    Without their server definintion for JBoss 4.x, we can't create any EJB's.   </cdb>



Naci Dai,
Managing Director

eteration a.s.

Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 81090
+90 (532) 573 7783 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com

mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx


Back to the top