Community
Participate
Working Groups
The Sample Web application JSPs emitted for a Java service class by the Web Service (JAX-RPC) Sample JSP generator will fail to compile and run if the Java service class' methods use, directly or indirectly, abstract beans or bean interfaces. The symptom appears as an HTTP 500 in the Results frame of the Sample Web app with this root cause: org.apache.jasper.JasperException: /sampleService/Result.jsp(27,8) The value for the useBean class attribute example.ThingInterface is invalid. The reason this occurs is that the Sample JSP generator does not verify that each bean it encounters while analyzing the service class is concrete and has a public default constructor. Ideally, the Sample JSP generator should search for viable concrete subclasses of any interfaces or abstract classes and emit JSPs that provide the user with a way to choose from possibly many such concrete classes and fill in their fields, however, this degree of dynamism is beyond the scope of the Sample JSP facility. Therefore, the generator should at minimum detect method parameters or bean properties whose types are abstract classes, interfaces or not in possession of a public default CTOR. In such cases, the generator should not emit an input form fragment for the type. Furthermore, if the unsupported type is used by a method parameter, the generator should emit a 'null' value for the parameter where the method is invoked.
Created attachment 62926 [details] Example of Java service using abstract classes and interfaces To reproduce the problem, insure you have Sample JSP friendly Web application server installed such as Apache Tomcat, import the attached jar into a Java project, right click on Service.java, and choose to Generate Sample JSPs.
Raised priority to P2. Targetted to 1.5.4.
Andrew, reassigned to you. Thanks for investigating.
Created attachment 63456 [details] Patch for jst.ws.consumption plugin This patch will detect types which cannot be instanstiated via the useBean jsp action and does not emit code fragments for them.
This patch is ready for review, thanks!
Andrew, thanks for the patch. Two observations: 1. JavaMofTypeVisitorAction.hasDefaultConstructor() is searching methods returned by JavaClass.getPublicMethods(). If I have a class with at least one non-public CTOR and zero public CTORs, then it looks like this method will incorrectly return 'true'. Shouldn't we be searching all methods for a class that either (A) has no CTORs of any access level or (B) has a public default CTOR? 2. The generator should produce a warning to the user that interfaces, abstracts, and otherwise non-public-default-constructable classes have been encountered, similar to what it does for other unsupported types. In part because of the impact to translatable properties, I consider this beyond the scope of a service release and the central issue of this bug (JSPs that don't compile). Would you please open a separate bug for the JSP generator to notify the user that non-constructable stuff was found? Either we can use the generator's existing mechanism for queueing up warning conditions and presenting them in a dialog, or we can generate a placeholder into the input form to tell the user their method or property was not forgotten, but has been wired to null and can only be changed by hand-customizing the JSPs.
Created attachment 63631 [details] updated patch Chris, you are quite right, we need to check for non-public default constructors as well. Here is an updated patch to do this. bug 182167 is opened re your second comment.
Thanks Andrew, the new patch looks good. PMC, please approve for WTP 1.5.4. This fix does the minimum to keep the JSP generator from spewing forth JSPs with unhealthy useBean tags.
+1 spewing unhealthy JSP's must be avoided. :)
+1
The fix for this defect has been committed and released to the 1.5.4 stream under v200704182024.
Verified on 1.5.4 RC1.
Thanks for the fix, Andrew. Closed.
