JSR88Minutes8Nov2006

Vince: Ideally want full GUI editor that we have now

Peter W: Java EE 5 is technically a superset of J2EE 1.4, however many things in Java EE 5 are less important than in J2EE 1.4

Pavel: Use-case driven approach, for server-specific editing minimal UI may be sufficient

Vince: Zero configuration is one of the use cases that needs to be supported

Pavel: Agreed, no dispute about that, but this is separate from server-specific editing UI

Peter W: At some point configuration needs to be summarized and presented as a merged model from annotations + XML

Pavel: With Retouche we can not maintain the current model 2 options: keep J2EE 1.4 untouched or do the same as Java EE 5

Pavel: JSR 88 is not a requirement, it is an implementation detail (not used by other plugins)

Petr J: We do have a merged model at the level of DD APIs, we just want to drop the JSR 88 wrapper and the events

Stepan: Can not use JSR 88 way and the fine grained events, performance hit

Petr J: Listening on changes never really worked, because JMI has unfixable issues. Retouche acknownedges this and does not even try.

Peter W: JSR 88 is not required, agree that it does not need to be used, the issue is that rewriting the UI is a lot of work.

Stepan: No other solution than nuking the events is possible

Pavel: Is it possible to wrap classes into JSR 88 and don't do the events? What effort would it be on the plugin side to keep JSR 88 model but change the event approach?

Peter W: Going away from the event model is the bigger part of the work.

Stepan: Wrapping the DD model by JSR 88 would be expensive. Whole model would need to be built from scratch every time.

Petr J: How often would you need to build the wrapped model? Currently on every keystroke, but could it be done less often?

Stepan: Don't know, would need to investigate.

Pavel: Do we need to have the auto-synch of standard and server-specific data. Do we need this? Can we synchronize after e.g. switching to Sun AS from JBoss?

Vince: Need synchronization, that's the whole point of the plugin.

Stepan: Rather than automatic synchronization, would prefer something like tasklist

Stepan: Proposes to synchronize automatically after high level actions such as Create EJB. After hand-editing, there is no automatic

Petr J: Let's look at the individual use cases in Stepan's document and go through them one by one and see which ones are controversial. Is there a counterproposal to Stepan's proposal?

Peter W: Preserving the J2EE 1.4 case would save work on the Appserver side. Is the model itself changing?

Stepan: Propose to use DD API as the model.

Peter W: Could possibly throw away DConfigBean model on the Appserver plugin side, and use the underlying schema2beans model directly.

Pavel: We have DD APIs, whose implementation is generated by schema2beans. JSR 88 DDBean is just a wrapper around the DD API.

Peter W: J2EEModuleProvider currently provides merged tree of beans, will this be preserved?

Martin: Model will be the same, but will not fire events, it will be a snapshot of the current situation.

Peter W: No value in event of type "file changed". Would be useful to have a scope of events that "session bean changed".

Peter W: Tracking of events is done mainly because of J2EE 1.4 (webservices.xml, JNDI names). Not really a value of Java EE 5.

Martin/Pavel: Need to synchronize. Is it a big change to do that once in a while vs. on every keystroke?

Peter W: Can be done, not a huge change. J2EE 1.4 is more sensitive to this.

Peter W: Use case: change something on the annotated EJB. What exactly will the event say? Will it say the EJB name? XPath?

Martin: In EJB support, events are not really needed. Model will not be built immediately after every change.

Peter W: In that case, need a different model for J2EE 1.4, need to continue to have fine grained events. For Java EE 5, don't need the fine grained events.


Summary: Can drop DDBean wrappers, pending Peter W check. Will keep the same model (DD API/schema2beans) including events for J2EE 1.4, without the JSR 88 wrapper. Will have a model with merged XML+annotations for Java EE 5 - snapshot only, without events.


AI: Peter W to check how exactly DDBean/DDBeanRoot wrappers + DeployableObject are used and whether we can drop them.
AI: Stepan to check performance of rebuilding the whole model from scratch.
AI: Peter, Vince, Martin to review Stepan's document on use cases of how things happen.
AI: Petr J to involve HIE to review the change of the user model, preferably also of the UI itself.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo