JEE Status Meetings/2010-03-04
Java EE 6
- EJB 3.1 bugs of note: 241670 299086
- Web 3.0 bugs of note: 304595
- Glassfish Java EE 6 wizards
- Java EE Tools plan
- EJB Tools plan
- List of Java EE 6 bugs that need to be rolled into the WTP 3.2 plan
- Replace Existing JavaEE Dependencies page - bugs of note: 303600 303706 304654
- Bugs marked with the Flexible Modules whiteboard entry
Modules always synchronized 304673
Server Tools Enhancements:
|293742||Discussion continue. Not in plan, yet|
|286699||Need to review. Not in plan, yet|
Carl: First, bugs 241670 and 304595 were committed last night. Let's go through the Java EE 6 bugs and see where we stand.
Jason: bug 258191 is mostly done. Still need to do singleton support. However, now without DDs, it is a little tricky to do import to choose the facet level. Perhaps we should just pick the latest?
Chuck: I know traditionally we chose the latest as the default, but that might cause problems if you intend to target a server that doesn't support that level.
Jason: I think that from now forward, we ought to select the highest facet supported by the runtime that is selected.
Angel: Do users have an option to select what version they want to import it as?
Jason S: No, we've never had that.
Carl reviewed other bugs in the Java EE 6 list and the Java EE Tools plan.
Rob: What did you get into M6?
Chuck: The scenario that I was mostly concerned with- any Java EE module being able to add a utility jar. When you open up the preference page on those projects, there are two views- the second shows the derived references. I worked hard to get add/remove references working fine. You can also add/remove multiple projects at once. Because of my testing, I found some inconsistencies in how we were creating references... the biggest one is EJB clients. The reference to the EJB client should only be added to the manifest and the .component of the EAR, not in the .component of the EJB project.
Rob: I investigated this before- the generic server was coded such that EJB modules cannot have child modules.
Jason S: Jason P and I were talking about different problems in the flat component that we have. We don't have the notion of a reference that is just a peer dependency.
Rob: IVirtualComponent now has the option to pass in a map to getReferences that can filter out things like derived references. I don't think we need a lot more API, we just need some constants that are JavaDoc-ed.
Chuck: But once you get into the FlatComponent model, you lose the ability to find out what type of references they are.
Rob: Right, the FlatComponent is supposed to hide the component. You don't care what other references there are, unless you need to bring it in. If we have a constant of "Only those that need to be published", then the FlatComponent passes that in.
Jason P: I think we are talking about the same thing- you just want to move it up to a higher level.
General discussion about exactly what level the reference types should be exposed at. We can't make a generic exporter without surfacing these reference types.
Rob: As a long term goal, we should never call getReferences() without an options map. We should really tailor this for what we need, if we can.
Chuck: I am worried about stability, I know we are past DCUT, but we need to review these bugs and get them into M6, if possible.
Rob: Have you looked at the UI picture? (Bug 304654)
Chuck: I wish this had come earlier. It is so late. I am worried about making things so generic. I just need more time to take a look.
Rob: Once you get rid of that button, and move it to the bottom, you can reduce everything else down to Add/Edit/Remove.
Chuck: This would be great, if we can get sign off. But I am really thinking this is too much to shove in this next week.
Carl: We can always seek PMC approval.
Jason S: I think that this is worth the effort. The current UI is quite cluttered.
Rob: When is the cut off for M7?
Carl: April 26th should be the DCUT for M7.
Rob: Also, there is the deploy issue. In the getModules method, it blatantly caches the IModules.
Angel: What are we getting out of this new caching that was added?
Rob: In a typical publish, there will be 3-4 calls to members. If you have a big project, it is traversing the tree 3-4 times with no gain. So I figured it would be smart to cache it in the Module object, but only reset it if there is a Workspace change. This works fine until a ModuleFactory looses its instance. The problem is, the Server object is keeping the old one, so the old one stops uncaching itself.
Angel: The modules have the same ID, right?
Rob: Yes, but the Server caches it. Instead of calling out to the ModuleFactory to get a new copy, it keeps the old one that has stopped updating its cache.
Chuck: Is this just a problem where it doesn't have the right listener?
Carl: If the server asks for this module again, will it be quick?
Chuck: Should there be a way for the servers to be notified that the modules are out of date?
Angel: Wouldn't that indicate a change? And thus make it out of sync?
Rob: We're getting a bit of benefit here by not recomputing all of this every time.
Angel: I need to think about this for a bit- there may be some benefit, but changes would need to be made.
Chuck: There is some benefit to the server caching. There is also a need to be a way to inform the server that the cached objects are invalid.
Rob: We can set the boolean to false for now to stop the caching at my level.
Angel: I think that we should revert that until we have finalized this.
Rob: Can we get this done for M6?
Carl: This merits a respin.