Bugzilla – Full Text Bug Listing
| Summary: | [API] Need a fourth DEFAULT_RUNTIME preference | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Roberto Sanchez Herrera <shr31223> | ||||
| Component: | wst.web | Assignee: | Roberto Sanchez Herrera <shr31223> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ccc, deboer | ||||
| Version: | 3.2.3 | Keywords: | api | ||||
| Target Milestone: | 3.2.4 | Flags: | ccc:
pmc_approved?
(david_williams) ccc: pmc_approved? (raghunathan.srinivasan) ccc: pmc_approved? (naci.dai) deboer: pmc_approved+ ccc: pmc_approved? (neil.hauge) ccc: pmc_approved? (kaloyan) ccc: pmc_approved? (cbridgha) cbridgha: review+ |
||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | PMC_approved | ||||||
| Attachments: |
|
||||||
|
Description
Roberto Sanchez Herrera
Currently, we have three DEFAULT_RUNTIME entries defined in IProductConstants. An adopter (IBM) wants that increased to four, to allow for proper sorting of its four highest priority runtimes. Note that this was already committed/released to WTP 3.3 M6. The adopter product is based on the WTP 3.2.x stream, as such we want this change backported to WTP 3.2.4. Created attachment 190568 [details]
patch
Note that, since IProductConstants is a public class, even though all we need to do is to add one public static final String to that interface, this bug will need a PMC Review requested due to API change. This is reasonable - I approve Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. We are requesting PMC approval due to API change- IProductConstants is a public API, and we are adding a static final String and hooking that into ProductManager for adopter usage Is there a work-around? If so, why do you believe the work-around is insufficient? There is no workaround for this scenario- currently, WTP provides 3 DEFAULT_RUNTIME entries, the adopter desires a fourth. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? I have successfully run the JUnit bucket against this patch. Give a brief technical overview. Who has reviewed this fix? Carl Anderson and Chuck Bridgham have reviewed this fix. The fix is to simply provide a DEFAULT_RUNTIME_4 in IProductConstants, and to add that into ProductManager's DEFAULT_RUNTIME_KEYS (which is private). What is the risk associated with this fix? The risk is extremely low. I think I already know the answers, but would like to include it here for completeness: 1) Are we aware of anyone implementing IProductConstants? 2) Why is it a public interface, and does it have any javadoc comments about what usage/extension is allowed by adopters? (In reply to comment #6) > 1) Are we aware of anyone implementing IProductConstants? > 2) Why is it a public interface, and does it have any javadoc comments about > what usage/extension is allowed by adopters? 1) We are not aware of any adopters implementing IProductConstants. It is really meant for usage by WTP code and adopters via IProduct.getProperty(). 2) It has javadoc. If I had read it, I might not have requested PMC approval, due to the fact that the javadoc declares this as provisional: * These constants define the set of properties that this pluging expects to * be available via <code>IProduct.getProperty(String)</code>. The status of * this interface and the facilities offered is highly provisional. * Productization support will be reviewed and possibly modified in future * releases. While it does not explicitly state the extension allowed by adopters, it is quite clear in the usage. It is a public interface because adopters can/should use the defined Strings in calls to IProduct.getProperty(String). It also clearly states that this interface can be modified in future releases. No, you were still right to request PMC approval. Any change that affects our public (provisional or not) signature should be approved, even if adopters would have to misbehave to be affected. +1. Change is minor, and I agree that adopters are highly unlikely to be implementing this particular class. Please also add a javadoc comment (in 3.3 is fine) that explicitly states that adopters may not implement the class. I think the standard is: * <p>This interface is not intended to be implemented by clients.</p> * * @noimplement Committed to R3_2_maintenance for WTP 3.2.4 Note that the desired comments were also committed to HEAD, under the original bug 338768 |