Item |
Section |
Comment |
Response |
ludo-1 |
all |
With versioning (very good addition) we keep adding deployment capabilities to the CLI or Admin GUI (and possibly NetBeans) which is not exposed to JSR 88 or sun-XXX specific deployment descriptors. I think, as an RFE, it should be possible to also specify all the possible deployment CLI parameters and options inside the glassfish specific descriptors or a deployment plan file. |
Agreed. I have filed a RFE for this. Not sure if we have time to address it in this release. |
ludo-2 |
missing |
Performance goals: not sure if this is an exit criteria, but Deployment is one of the critical developer activity, and we need to at least not regress from GlassFish v3, and keep in mind any performance improvement which could be done in all the layers (DOLs, ClassLoader optimization, Annotation processing optimization -for example, work with the CDI team to make it aware of deployment performance issues there. Awareness of deploy performance for all the teams involved (CDI, Servlet, EJB JPA, REST...) is important. |
Yes, performance is a P1 requirement. We will certainly work with performance team to meet the exit criteria. |
ludo-3 |
performance |
Related to previous topic, as an RFE, we should start talking to the WebLogic team regarding hotswapping classes instead of doing a full redeployment, and see if it is a complex WebLo implementation or just something at the jrockit level and easy to implement for GlassFish as a nice value added for developers |
Filed a RFE for this. We should look into this, but don't think it will happen in this release. |
ludo-4 |
missing |
For GlassFish 3, we had some confusing by the teams regarding directory deployment: some did not fully implement a completely exploded archive, including for the included libraries in a web app or an ear file. Would be nice to specify this in this document to clear the confusion: all deployment that accept a zip or jar file should also accept an exploded directory for this entry |
Actually all the sub modules still need to be fully exploded like what we documented in the doc. The only difference is previously all the library jars need to be in unexploded form, but now for Eclipse support, the exploded library jars will also be supported. |
ludo-5 |
error reporting |
Error reporting for wrong artifacts should be enhance in general (maybe just filing bugs whenever users post deployment questions on forum, as it is sometimes not easy to understand the root cause of a failed deployment. More information is in the log file, but not returned as a report on CLI or Tools access (NetBeans and Eclipse). A list of all known deployment errors should also be maintained (wiki?) for reference. It is a team effort as each container team would know more (CDI, JPA, WS, etc) in the area of errors, but deployment team can supervise this, if time permits |
Good idea, but probably not something we can do in this release either. In this release, We will file bugs for user reported error and address them. Next release, we can probably start such wiki page to be more systematic. |