|Re: [wtp-dev] Re: Annotated bean/servlet creation work for M3|
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!
Software Engineer, IBM Rational
"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
01/28/2005 02:13 PM
ToNaci Dai <naci.dai@xxxxxxxxxxxxx>
ccDavid M Williams/Raleigh/IBM@IBMUS, John Lanuti/Raleigh/IBM@IBMUS, Arthur Ryman <ryman@xxxxxxxxxx>
SubjectRe: [wtp-dev] Re: Annotated bean/servlet creation work for M3Link
My responses are below.....
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Phone: 919-254-1848 (T/L: 444)
Naci Dai <naci.dai@xxxxxxxxxxxxx>
01/28/2005 12:21 PM
ccArthur Ryman <ryman@xxxxxxxxxx>, John Lanuti/Raleigh/IBM@IBMUS, David M Williams/Raleigh/IBM@IBMUS
SubjectRe: [wtp-dev] Re: Annotated bean/servlet creation work for M3
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.
<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>
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)
Back to the top