Bug 717526 - Revert filtering in server/jar
Summary: Revert filtering in server/jar
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Build System
Version: 4.1
Hardware: Unspecified
OS: Unspecified
urgent
unspecified vote
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon3
TreeView+ depends on / blocked
 
Reported: 2011-06-29 06:41 UTC by Heiko W. Rupp
Modified: 2012-02-07 19:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 19:24:50 UTC


Attachments (Terms of Use)
screen shot of ws version still being correctly set after filter changes (77.21 KB, image/png)
2011-07-29 15:36 UTC, Simeon Pinder
no flags Details
Screenshot (200.87 KB, image/png)
2011-08-01 12:16 UTC, Sunil Kondkar
no flags Details

Description Heiko W. Rupp 2011-06-29 06:41:46 UTC
Currently in server/jar we filter on *each* build the sources into filtered-sources just to replace one property ( org.rhq.enterprise.server.system.ServerVersion#namespace ) with the pom version, so that webservices know the correct namespace.

This has several negative effects:
- IntelliJ sees target/filtered-sources as a source directory and complains about duplicated classes
- running 'mvn test' twice in a row to debug things, each time compiles all the sources in filtered-sources again, considerably slowing down debugging.

We should put the pom.version into a .properties file, that will just be included in server.jar and where the namespace code then gets its data.

Comment 1 Heiko W. Rupp 2011-06-29 06:48:54 UTC
Actually it turns out, that ServerVersion.namespace is used in a lot of places as a constant , so using a method to obtain the namespace may be no option.
A static class initializer may help here e.g.

    static {
        namespace = System.getProperty("pom.version");
    }

   public static final String namespace;

Comment 2 Ian Springer 2011-06-29 14:21:09 UTC
The CoreServer class in server-jar has an example of loading build properties from the classpath. There is also the MavenArtifactProperties class that I wrote, which provides the ability to load the standard maven build properties file for the specified Maven artifact, e.g.:

MavenArtifactProperties richFacesMavenProps = MavenArtifactProperties.getInstance("org.richfaces.framework", "richfaces-api");

Comment 3 Heiko W. Rupp 2011-06-30 09:19:31 UTC
The static initializer approach from comment#1 is failing:

modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/jaxb/WebServiceTypeAdapter.java:[25,46] attribute value must be constant

The compiler sees that the "public static final String namespace" is only initialized in that initializer and not  a real constant.

Can we perhaps use some sed mechanics on release builds to replace the version and otherwise keep the String constant with some "dummy" value -- much like we do with the pom versions?

Comment 4 Lukas Krejci 2011-07-20 14:03:24 UTC
Commit 6a75748bbe847d611f8ecdcf64b09134fde63340 makes this a bit less of an issue. Basically instead of doing resource filtering on the whole src/main/java, I split the code into "normal" and "filtered". The normal code lives under src/main/java and is your ordinary java sources with no special maven attention. The filtered sources live under src/filtered-sources/java and are subject to maven resource filtering. The filtered java files are put into target/filtererd-sources/java which is then set as an additional source directory. Effectively, the sources from src/main/java and target/filtered-sources/java then make up the full source tree and are compiled normally into target/classes.

The advantage of this approach is three-fold:

1) There is a clear separation of source files that need special treatment.
2) The build only recompiles the filtered sources each time it is invoked (even if there were no changes to the source files). This is a big improvement over the former implementation that had to recompile all the sources in server jar each time a build was invoked.
3) Increased compatibility with the Eclipse maven plugin (m2e) that wouldn't handle well the change of the source directory and would force the user to actually edit files in the source directory (that was redefined to be in target) and thus the user would loose changes everytime a maven build would commence. The only special case left are the filtered source files but because it is made explicitly an exceptional kind of a source file, the developer is more easily aware of special treatment needed for it.

--------------------------

To test this, we need to make sure the Web services still define the correct namespace. Simeon, could you please provide more feedback on how to actually do that? I know nothing about our web services infrastructure.

Comment 5 Mike Foley 2011-07-28 20:13:47 UTC
confirmed web services by following these steps:

http://www.rhq-project.org/display/JOPR2/RHQ+Web+Services+Installation

and then visiting this URL:

https://localhost:7443/jbossws/services

this page defines an endpoint as follows:

Endpoint Name 	jboss.ws:context=rhq-rhq-enterprise-server-ejb3,endpoint=WebservicesManagerBean
Endpoint Address 	http://foleymonsterbox1.foleyhomenetwork:7080/rhq-rhq-enterprise-server-ejb3/WebservicesManagerBean?wsdl

but ...

there is no WSDL at this location 
http://localhost:7080/rhq-rhq-enterprise-server-ejb3/WebservicesManagerBean?wsdl

(and I expect there would some WSDL)

Simeon ... could you confirm that this is the correct behavior for web services?

Comment 6 Mike Foley 2011-07-28 20:40:05 UTC
added BZ 726502  https://bugzilla.redhat.com/show_bug.cgi?id=726502 while trying to verify.  discussed with spinder.  verification of this BZ is blocked by BZ 726502.

Comment 7 Simeon Pinder 2011-07-29 15:36:52 UTC
Created attachment 515903 [details]
screen shot of ws version still being correctly set after filter changes

Comment 8 Simeon Pinder 2011-07-29 15:37:29 UTC
Fixed BZ 726502 and verified that Webservice version is still being correctly set.  See attached screenshot.  Nice work Lukas.

Moving to ON_QA.

Comment 9 Sunil Kondkar 2011-08-01 12:15:43 UTC
Verified on build#231 (Version: 4.1.0-SNAPSHOT Build Number: c4a82bc)

1. Followed the steps in:

http://www.rhq-project.org/display/JOPR2/RHQ+Web+Services+Installation

2. Visited this URL:  https://localhost:7443/jbossws/services

3.  Clicked on:
http://localhost:7080/rhq-rhq-enterprise-server-ejb3/WebservicesManagerBean?wsdl

4. Verified that the namespace in the WSDL is displayed as:

"http://www.rhq-project.org/4.1.0-SNAPSHOT/Webservices.xsd"

Please refer the attached screenshot.

Marking as verified.

Comment 10 Sunil Kondkar 2011-08-01 12:16:10 UTC
Created attachment 516123 [details]
Screenshot

Comment 11 Mike Foley 2012-02-07 19:24:50 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE


Note You need to log in before you can comment on or make changes to this bug.