<< Back to previous view

[WEBSOCKET_SPEC-201] @OnOpen @OnClose and @OnError annotations appear to be available for more than one method Created: 15/May/13  Updated: 15/May/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

In sections 4.4->4.6 there is an implication that these annotations could be applied to more than one method in a class. I suspect this is not correct and that the spec should be updated to say that one and only one method should be be allowed with this annotation attached.






[WEBSOCKET_SPEC-200] Inconsistent limitations on @PathParam types Created: 15/May/13  Updated: 15/May/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

In the JSR spec section 4.3 it states that @PathParam can be used on "parameters are String, any Java Primitive type, or boxed version thereof". But in sections 4.4->4.7 they say "zero to n String parameters annotated with @PathParam annotations".

Sections 4.4->4.7 should be updated to be consistent with section 4.3






[WEBSOCKET_SPEC-199] Add the ability to define filters and interceptors Created: 10/May/13  Updated: 13/May/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: reza_rahman Assignee: Unassigned
Resolution: Unresolved Votes: 8
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and reza_rahman

 Description   

In a future version of the WebSocket API, I would love to see the ability to specify filters and interceptors both on the client and server side. This could be very similar to how you can specify JAX-RS 2 filters and interceptors today (e.g. for encryption, compression, etc). Perhaps this could even be done via CDI interceptors somehow.

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.



 Comments   
Comment by gdavison [ 13/May/13 12:12 PM ]

Specific use case:

"In section 4.3 of the JSR 356 spec there is an example of using a @PathParam to map part of the path to a parameter, but as per RFC 6455 4.2.2. it should be possible to return a 404 status code without initiating a WebSocket interchange.

I can't find an obvious code path to do this as presumable onOpen is too late as a message has already been send down the connection. Is there a -RS like request filter available so we can intercept this?'





[WEBSOCKET_SPEC-185] RemoteEndpoint.Async methods could provide better connection back to the Session Created: 17/Apr/13  Updated: 17/Apr/13

Status: Open
Project: websocket-spec
Component/s: None
Affects Version/s: 1.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

In with the callback and the Future version of the RemoteEndpoint.Async there is no obvious way to discover what the original Session object was, this makes things a little bit more complicated when you are trying to broadcast to a number of listening clients.

Ideally the "SendResult" object should have a reference to the original Session that way the SendMessage object could be implemented with once instance rather than one for each Session. This would allow the broadcasting code to be able to check the state of the Session, perhaps dealing with a odd exception by checking to see if the Session is still open / or valid.

Having to write some kind of if/else code to deal with the Throwable parameter on SendResult also feels a little bit dirty particular as normally we are expecting SessionsException. Could we always get a SessionException instead that might have a more generic cause - this would make life a bit easier. I guess this would also be another way to get hold of the Session consistently.

It would also be nice for consistency if the Future returned by the polling version of the API instead of returning Future<Void> return Future<SendResult> for consistency. Although obviously the semantics might be different in a failure case - I suppose it could also return Future<Session> but it would be less flexible.






[WADL-66] Exception generating client for open trip planner Created: 14/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.3
Fix Version/s: current

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

When generating a client for:

http://opentripplanner.org/apidoc/application.wadl

We get an exception:

java.lang.AssertionError
at com.sun.tools.xjc.reader.internalizer.DOMForest.getOneDocument(DOMForest.
java:230)
at com.sun.tools.xjc.reader.internalizer.Internalizer.move(Internalizer.java:
431)
at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.
java:160)
at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.
java:109)
at com.sun.tools.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:
449)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.
java:231)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.
java:95)
at org.jvnet.ws.wadl2java.Wadl2Java.process(Wadl2Java.java:460)
at oracle.jdeveloper.webservices.rest.model.generator.GenerateClient$1.call
(GenerateClient.java:185)
at oracle.ide.xml.switchable.SwitchableTransformerFactory.
invokeWithJDKTransformerNewInstances(SwitchableTransformerFactory.java:122)
at oracle.jdeveloper.webservices.rest.model.generator.GenerateClient.action
(GenerateClient.java:116)
at oracle.jdeveloper.webservices.rest.model.generator.RESTGeneratorAction.run
(RESTGeneratorAction.java:116)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:603)
at java.lang.Thread.run(Thread.java:722)



 Comments   
Comment by gdavison [ 14/Mar/13 03:49 PM ]

Also fails for

https://familysearch.org/searchapi/application.wadl

Comment by gdavison [ 14/Mar/13 06:08 PM ]

Revision 372





[WADL-65] Cannot pass null to option query parameters Created: 14/Mar/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.3
Fix Version/s: current

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

I generated a WADL client for

http://www.fueleconomy.gov/ws/rest/application.wadl

And you can do the following:

WwwFueleconomyGov_WsRest.Vehicle.MenuModel menuModel = wwwfueleconomygov_wsrestvehicle.menuModel();
GenericType<List<MenuItem>> genericTypeMenuItemList = new GenericType<List<MenuItem>>() {
};
List<MenuItem> menus = menuModel.getAsXml("2012", "Honda", genericTypeMenuItemList);

for (MenuItem menu : menus) {

// Get hold of the ID for each
//

List<MenuItem> options = wwwfueleconomygov_wsrestvehicle.menuOptions().getAsXml("2012", "Honda", menu.getValue(),
genericTypeMenuItemList);

for (MenuItem option : options) { Vehicle item = wwwfueleconomygov_wsrestvehicle.id(option.getValue()).getAsVehicleJson();; System.out.println("Model " + menu.getText() + " Options " + option.getText() + " City08u " + item.getCity08U()); }
}

But if I try to pass null in as an option parameter then:

List<MenuItem> menus = menuModel.getAsXml("2012", null, genericTypeMenuItemList);

Then I get a null pointer in the client, the generated client should check to see if optional parameters are null.



 Comments   
Comment by gdavison [ 14/Mar/13 06:09 PM ]

Revision 372





[WADL-62] Add Support for WADL Binding Customizations Created: 13/Dec/12  Updated: 12/Mar/13

Status: Open
Project: wadl
Component/s: None
Affects Version/s: 1.1.3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fribeiro Assignee: gdavison
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: fribeiro and gdavison

 Description   

It would be nice if the plugin supported WADL binding customizations, like the JAX-WS Maven plugin does for WSDL, to support changing generated class names, for example.



 Comments   
Comment by gdavison [ 12/Mar/13 12:29 PM ]

You can control the class names using parameters to the Maven plugin, I had shied away from creating this external format from experience with WSDL it always seemed to go wrong.

Could you give examples of what you want to control?





[WADL-61] Trunk does not work with JDK 1.6 Created: 11/Dec/12  Updated: 12/Mar/13

Status: Open
Project: wadl
Component/s: www
Affects Version/s: not determined
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jkidd Assignee: Pavel Bucek
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Program Files\apache-maven-3.0.4\bin\..
Java version: 1.6.0_37, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_37\jre
Default locale: da_DK, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"


File Attachments: Text File build.log    
Tags:
Participants: gdavison, jkidd and Pavel Bucek

 Description   

T



 Comments   
Comment by jkidd [ 11/Dec/12 08:45 AM ]

The description should have said: See attached build log from maven

Comment by gdavison [ 12/Mar/13 12:27 PM ]

You will need to put jax-api.jar into the endorsed directory to run and run under JDK 6. This is because we have moved up to a later version of the JAX-B API.





[WADL-54] No method to close the client on JAX-RS 2.0 clients Created: 20/Nov/12  Updated: 20/Nov/12

Status: Open
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1.4

Type: Bug Priority: Minor
Reporter: gdavison Assignee: gdavison
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

We don't expose a method to close the client for a JAX-RS 2.0 proxy:

http://jersey.java.net/nonav/apidocs/snapshot/jersey/javax/ws/rs/client/Client.html#close()

I guess we should really allow this.






[WADL-51] Add getter and setter method to rest server IP address Created: 28/Jun/12  Updated: 09/Aug/12  Resolved: 09/Aug/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Dolcezeus Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Dolcezeus and gdavison

 Description   

As i wrote on the mailing list i'd like to have as improvement the getter and setter method on server's IP because i don't have a normal use case, i have to switch my rest calls between many servers that have the same wadl.
Thank you in advance.



 Comments   
Comment by gdavison [ 09/Aug/12 09:47 AM ]

I have added methods to provide the URI at various levels, the classes have been changed to be immutable also to make this safer. This is available in 1.1.3-SNAPSHOT





[WADL-50] WADL tools doesn't check to see if resources base is a relative path Created: 21/May/12  Updated: 22/May/12  Resolved: 22/May/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: current

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

If you have a WADL where the base URI is relative to the WADL location, this isn't explicitly disallowed in the spec, then the client tools doesn't correctly generate valid URI's

There also needs to be a way to override the original location for the cases where the WADL is copied locally.



 Comments   
Comment by gdavison [ 22/May/12 03:06 PM ]

Check in revision 329, which contains fixes to correctly process relative paths in the base property of resources. This allows WADLs to use relative paths on servers.

In order to make use of this I have update the mojo to take a new target element to reference the remote URI:

<configuration>
<targetDirectory>${basedir}/target/test-harness/open-patent-example/generated-sources/wadl</targetDirectory>
<packageName>test</packageName>
<targets>
<param>wadl://example/open-patent-services/wadl/ops-hacked.wadl</param>
</targets>
<customizations>
<customization>${basedir}/src/test/resources/open-patent-services/customization-hacked.xjb</customization>
</customizations>

<autoPackaging>true</autoPackaging>
<failOnError>false</failOnError>
</configuration>





[WADL-49] Fail building java classes if the "base" attribute of a resources element in the wadl file starts with a number Created: 14/May/12  Updated: 22/May/12  Resolved: 22/May/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: current

Type: Bug Priority: Major
Reporter: ihasan Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Debian (2.6.30)
Java version "1.6.0_22"


Tags:
Participants: gdavison and ihasan

 Description   

When trying to compile the services of OPS wadl (http://www.epo.org/searching/free/ops.html), wadl2java fails with the following errors (I tried both 1.1.1 and 1.1.2 versions)

Version 1.1.1:
Exception in thread "main" java.lang.IllegalArgumentException: JClass name 262RestServicesPublishedData contains illegal character for beginning of identifier: 2
Version 1.1.2:
Exception in thread "main" java.lang.NullPointerException

I think this happens because the base attribute of the resources element of the wadl starts with a number. It follows the related excerpt of the wadl file:

<resources base="/2.6.2/rest-services/published-data/">
<!-- GET -->
<resource path="{ref-type}/{ref-format}/{number}/{constituents}" id="publishedDataRetrievalGET">
<doc xml:lang="en" title="Published document retrieval GET interface"/>
<param href="#ref-type"/>
<param href="#ref-format"/>
<param href="#number"/>
<param name="constituents" href="#published-data-constituents"/>

<method name="GET" href="#wpdGETPOST"/>
</resource>
......



 Comments   
Comment by gdavison [ 22/May/12 03:04 PM ]

The root of the problem is that the original WADL was invalid, but the tool wasn't able to correctly communicate this.

I have put in place a bunch of validation and committed this as version 329, in generation missing method names, id properties on top level elements and anything other than href on reference nodes will all be flagged up to the user. The missing will result in an exception, the others a warning. I guess we should consider upgrading some of these to warning.s





[WADL-48] Output from Schema generation is written to SOP Created: 05/Mar/12  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: current

Type: New Feature Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

The output of the schema generation is written to the SOP so it can be hard for a client to know whether the process has
failed or not. We need to extend the Parameter object to allow the passing of a ErrorListener or similar interface.



 Comments   
Comment by gdavison [ 16/Mar/12 03:18 PM ]

New inteface, MessageListener, provided to allow IDE tools to collect output.

http://java.net/projects/wadl/sources/svn/revision/327





[WADL-47] When we have separate complexType and element definition code generated is incorrect. Created: 05/Mar/12  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: current

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

If you have a schema which look like this:

<xs:schema>
<xs:element name="foo" type="bar" />
<xs:complexType name="bar" />
</xs:schema>

Then the code needed to be generated for parameters, not returns, will be default require the enclosing JAXBElement, more on this here:

http://weblogs.java.net/blog/kohsuke/archive/2006/03/why_does_jaxb_p.html

So the user can work around this by specifying the xjc:simple binding file, which are are probably going to do by default in JDeveloper - this won't cover all cases.

So we need to test in the case of a parameter; but not a return type, whether the type in question is XmlRootElement or XmlType so in order to generate the right parameter wrapped with a JAXBElement, I guess we are going to have to create a GenericType for this also.



 Comments   
Comment by gdavison [ 16/Mar/12 03:20 PM ]

In the case of a file with only @XmlType on it we generat ea JAXBElement to wrap
the element before we invoke the Client method.

http://java.net/projects/wadl/sources/svn/revision/327

This removed the need for the simple binding.





[WADL-46] Instead of having duplicate get methods when there is no id, use the path Created: 06/Dec/11  Updated: 08/Mar/12

Status: Open
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sirgeek Assignee: gdavison
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Tags:
Participants: gdavison and sirgeek

 Description   

Instead of generating multiple stubs/interfaces with just "Response get" methods, generate something more useful using the @Path

I.E:
Instead of:
@GET
@Produces({"application/xml", "application/json" })
@Path("/current/locationType/{locationType}")
Response get(@PathParam("locationType") String locationType);

Generate:
@GET
@Produces({"application/xml", "application/json" })
@Path("/current/locationType/{locationType}")
Response getCurrentLocationType(@PathParam("locationType") String locationType);



 Comments   
Comment by gdavison [ 08/Mar/12 04:46 PM ]

Fair comment, I will look into it.





[WADL-44] Need a programatic way of overriding the base URL of the generated class. Created: 21/Nov/11  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: aroller, dattatre263 and gdavison

 Description   

There needs to at least be a programatic way of overriding the base URL of the generated class in the instance of moving from a development to a production system.

Possibly we should consider using catalogs in the same way that JAX-WS to provide indirection in a way that can be modified using deployment plans.



 Comments   
Comment by gdavison [ 27/Jan/12 04:23 PM ]

I would suggest that we support a jax-rs-catalog file using the same catalog format as JAX-WS proxy clients for each.

http://jax-ws.java.net/nonav/2.1.5/docs/catalog-support.html

Comment by aroller [ 27/Jan/12 11:31 PM ]

For static WADL files:

Using Maven, this should be a fairly simple task using the maven resources filtering.

http://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

 
<build>
  <resources>
    <resource>
      <directory>src/main/wadl</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
...

 <properties>
   <api.url>http://localhost:8888</api.url>
 </properties>

with ${api.url} in the base attribute of ns2:resources in the wadl file.

 <ns2:resources base="${api.url}">

Unfortunately, the Maven Lifecycle generates sources before filtering resources.

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

So you have to change the lifecycle phase of either the wadl plugin or maven-resources-plugin. Changing the phase of the wadl plugin to process-resources seems to successfully filter the wadl file, copy it to the output directory and then generate resources from the filtered wadl file.

You'll need to configure the wadl plugin to use the output directory as the source of the wadl file.

 
 <plugin>
	<groupId>org.jvnet.ws.wadl</groupId>
	<artifactId>wadl-maven-plugin</artifactId>
	<version>${wadl.version}</version>
		<executions>
  		    <execution>
*<!-- this is the necessary phase change -->*
			<phase>process-resources</phase>
				<goals>
					<goal>generate</goal>
				</goals>
		    </execution>
		</executions>
	<configuration>
		<packageName>com.example</packageName>
		<autopackaging>true</autopackaging>
*<!-- must change the source directory to use the filtered wadl resource -->*
		<sourceDirectory>${project.build.outputDirectory}</sourceDirectory>
		<customClassNames>
			<property>
				<name>http://localhost:8080</name>
				<value>MyApi</value>
			</property>
			<property>
				<name>http://example.com/api</name>
				<value>MyApi</value>
			</property>
		</customClassNames>
	</configuration>
</plugin>
 

Comment by aroller [ 27/Jan/12 11:36 PM ]

You can generate the WADL dynamically using the similarly named maven-wadl-plugin. There is a configuration with that plugin for the base URL which can be controlled with an environment variable.

<baseUri>${api.host.url}</baseUri>

The procedure to deploy to production would be something like:

mvn install -Dapi.host.url=http://example.com/api 
Comment by dattatre263 [ 28/Feb/12 09:10 PM ]

Hello,

Could you please explain what the following is actually doing ?

<customClassNames>
			<property>
				<name>http://localhost:8080</name>
				<value>MyApi</value>
			</property>
			<property>
				<name>http://example.com/api</name>
				<value>MyApi</value>
			</property>
		</customClassNames>
Comment by gdavison [ 16/Mar/12 03:19 PM ]

Added support for a jax-rs-catalog.xml file to allow the overriding of the base URI for a resource.

http://java.net/projects/wadl/sources/svn/revision/327
and a example
http://kingsfleet.blogspot.com/2012/03/catalog-support-for-wadl-client.html





[WADL-43] Need a way to control the name of the generated class Created: 21/Nov/11  Updated: 12/Jun/13

Status: Open
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Java Source File MyApi.java     Java Source File Wadl2JavaMojo.java    
Issue Links:
Duplicate
is duplicated by WADL-37 No way to rename entry point Closed
Tags:
Participants: aroller, gdavison and sirgeek

 Description   

The generation API should provide a way for the client to specify the name of the class being generated, currently this can only be defaulted from the URL.

A static API that allows the development tools to generate an API should be provided.



 Comments   
Comment by aroller [ 25/Jan/12 06:03 AM ]

Changes to the Maven Mojo that will allow configuration of the custom class names (see attached file).

/**

  • A list of key/value pairs with the key being the Base URL in the WADL file. The value is the
  • desired name of the resulting class.
  • <pre>
  • <customClassNames>
  • <property>
  • <name>http://localhost:8080</name>
  • <value>MyApi</value>
  • </property>
  • <property>
  • <name>http://example.com/api</name>
  • <value>MyApi</value>
  • </property>
  • </customClassNames>
  • </pre>
  • Properties used instead of map because colon is not allowed in xml element name.
  • @parameter expression="${customClassNames}"
    */
    private Properties customClassNames;
Comment by aroller [ 25/Jan/12 06:08 AM ]

The resulting Generated file

Comment by gdavison [ 26/Jan/12 01:07 PM ]

Merged proposed fix from Aaron, only remaining problem now is the command line interface before I can close this bug.

Comment by sirgeek [ 07/Jun/13 07:43 PM ]

Couldn't something as simple as -r [STRING] be done as a parameter (if it is present, use it else use exactly what you use now.

i.e. something like:

wadl2java -r WebServices -p com.isone.testing.webservices.v1_0a -o ../../../workspace/webservices/src ../../../sqaCVS/www/src-bind/wadl_1.31.xml

Comment by gdavison [ 10/Jun/13 11:00 AM ]

Unfortunately in the above examples you can have multiple root resources in a WADL so you need to be able to enter names for each URI, hence the complication.

Comment by sirgeek [ 12/Jun/13 02:02 PM ]

what about using something like the jax-rs-catalog.xml ?

<uri name="WsProjectDomainCom_ApiV10" uri="WebServices" />
<uri name="WsSandboxDomainCom_ApiV10" uri="WebServices" />

Would that work ?





[WADL-42] Generator fails if the URL is an IP Address Created: 21/Nov/11  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: current

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

If the URL if the service is an IP address then the name of the wrapping class is invalid as generated it will start with a number. The code needs to deal with the following cases:

IP4 127.0.0.1
IP6 ::1

And others, perhaps in this case just providing a prefix of IP would be enough?



 Comments   
Comment by gdavison [ 16/Mar/12 03:17 PM ]

IP based addresses are prefixed with "IP" to prevent a naming problem in Java.

http://java.net/projects/wadl/sources/svn/revision/327





[WADL-41] Duplicate methods generated when return type of method is void Created: 05/Aug/11  Updated: 09/Aug/11  Resolved: 09/Aug/11

Status: Closed
Project: wadl
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified

File Attachments: Text File WADL-41.patch    
Tags:
Participants: gdavison

 Description   

I was testing the following service:

@Path("/put")
public class PutResource {
@GET
@Produces("application/xml")
public Bean get() { return new Bean(); }

@PUT
@Consumes("application/xml")
public void put(Bean bean) {

}
}

And I forgot to turn on XML Schema generation and I went to generate a client and it came up with code that has duplicate methods and doesn't actually invoke the service in question. Possibly two issues here.

package example;

import java.util.HashMap;
import javax.annotation.Generated;
import javax.ws.rs.core.UriBuilder;
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.WebResource;

/**

  • */
    @Generated(value = "http://localhost:7201/Project1/jersey/application.wadl", comments = "wadl2java")
    public class HttpLocalhost7201Project1Jersey {

public static class Put {

private Client _client;
private UriBuilder _uriBuilder;
private HashMap<String, Object> _templateAndMatrixParameterValues;

/**

  • Create new instance using existing Client instance
  • */
    public Put(Client client) { _client = client; _uriBuilder = UriBuilder.fromPath("http://localhost:7201/Project1/jersey/"); _uriBuilder = _uriBuilder.path("/put"); _templateAndMatrixParameterValues = new HashMap<String, Object>(); }

/**

  • Create new instance
  • */
    public Put() { this(Client.create()); }

public void getAsvoid() { UriBuilder localUriBuilder = _uriBuilder.clone(); WebResource resource = _client.resource(localUriBuilder.buildFromMap(_templateAndMatrixParameterValues)); WebResource.Builder resourceBuilder = resource.getRequestBuilder(); return ; }

public void get() { UriBuilder localUriBuilder = _uriBuilder.clone(); WebResource resource = _client.resource(localUriBuilder.buildFromMap(_templateAndMatrixParameterValues)); WebResource.Builder resourceBuilder = resource.getRequestBuilder(); return ; } }

public void get() { UriBuilder localUriBuilder = _uriBuilder.clone(); WebResource resource = _client.resource(localUriBuilder.buildFromMap(_templateAndMatrixParameterValues)); WebResource.Builder resourceBuilder = resource.getRequestBuilder(); return ; }

public void putApplicationXmlApplicationXml(Object input) { UriBuilder localUriBuilder = _uriBuilder.clone(); WebResource resource = _client.resource(localUriBuilder.buildFromMap(_templateAndMatrixParameterValues)); WebResource.Builder resourceBuilder = resource.getRequestBuilder(); resourceBuilder = resourceBuilder.type("application/xml"); return ; }

public void putApplicationXmlApplicationXml(Object input) { UriBuilder localUriBuilder = _uriBuilder.clone(); WebResource resource = _client.resource(localUriBuilder.buildFromMap(_templateAndMatrixParameterValues)); WebResource.Builder resourceBuilder = resource.getRequestBuilder(); resourceBuilder = resourceBuilder.type("application/xml"); return ; } }

}
}



 Comments   
Comment by gdavison [ 05/Aug/11 03:44 PM ]

The WADL for this case is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<application xmlns="http://research.sun.com/wadl/2006/10">
<doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8-SNAPSHOT 06/01/2011 07:09 PM"/>
<resources base="http://localhost:7201/Project1/jersey/">
<resource path="/put">
<method id="get" name="GET">
<response>
<representation mediaType="application/xml"/>
</response>
</method>
<method id="put" name="PUT">
<request>
<representation mediaType="application/xml"/>
</request>
</method>
</resource>
</resources>
</application>

Comment by gdavison [ 08/Aug/11 11:52 AM ]

Proposed patch

Comment by gdavison [ 09/Aug/11 01:03 PM ]

Revision 305





[WADL-40] IllegalArgumentException: JClass name empty Created: 10/Jan/11  Updated: 12/Mar/13

Status: Open
Project: wadl
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: akimran82 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows XP


Tags:
Participants: akimran82 and gdavison

 Description   

Hi,
I tried to do a wadl2java from SOAP UI.
Below is the error i get. I am not sure if its a bug or some settings issue.
could you help me with this please?

Exception in thread "main" java.lang.IllegalArgumentException: JClass name empty
at com.sun.codemodel.JDefinedClass.<init>(JDefinedClass.java:194)
at com.sun.codemodel.JDefinedClass.<init>(JDefinedClass.java:154)
at com.sun.codemodel.JDefinedClass._class(JDefinedClass.java:631)
at com.sun.codemodel.JDefinedClass._class(JDefinedClass.java:606)
at org.jvnet.ws.wadl2java.ResourceClassGenerator.generateClass(ResourceClassGenerator.java:132)
at org.jvnet.ws.wadl2java.Wadl2Java.generateSubClass(Wadl2Java.java:406)
at org.jvnet.ws.wadl2java.Wadl2Java.generateEndpointClass(Wadl2Java.java:384)
at org.jvnet.ws.wadl2java.Wadl2Java.process(Wadl2Java.java:146)
at org.jvnet.ws.wadl2java.Main.main(Main.java:120)



 Comments   
Comment by gdavison [ 12/Mar/13 12:37 PM ]

Can you provide some test steps?





[WADL-39] Duplicate JSON methods generated Created: 04/Nov/10  Updated: 12/Mar/13

Status: Open
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: matomira Assignee: wadl-issues
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 39
Tags:
Participants: gdavison, matomira and wadl-issues

 Description   

If the service supports both application/xml and application/json duplicate JSON
methods are generated.
I had to work around by disabling the JSON support in the service.



 Comments   
Comment by gdavison [ 12/Mar/13 12:32 PM ]

I know this is a really old issue; but do you have a test case for this still?





[WADL-38] @XmlRootElement annotations not generated Created: 04/Nov/10  Updated: 08/Mar/12  Resolved: 08/Mar/12

Status: Closed
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: matomira Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 38
Tags:
Participants: gdavison and matomira

 Description   

The @XmlRootElement annotations are not generated. I had to resort to
marshalling/unmarshalling workarounds.



 Comments   
Comment by matomira [ 11/Nov/10 02:07 AM ]

This ticket should be closed. The annotation is generated by providing a binding
file like:

<?xml version="1.0"?>
<jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc= "http://java.sun.com/xml/ns/jaxb/xjc"
jxb:extensionBindingPrefixes="xjc" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<jxb:bindings schemaLocation="path/to/myschema.xsd" node="/xs:schema">
<jxb:globalBindings>
<xjc:simple/>
</jxb:globalBindings>
</jxb:bindings>
</jxb:bindings>

The binding file should be referenced in the customizations section of the plugin.

Comment by gdavison [ 08/Mar/12 04:42 PM ]

Use the simple binding as suggested by the user





[WADL-37] No way to rename entry point Created: 04/Nov/10  Updated: 08/Mar/12  Resolved: 08/Mar/12

Status: Closed
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: matomira Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
duplicates WADL-43 Need a way to control the name of the... Open
Issuezilla Id: 37
Tags:
Participants: gdavison and matomira

 Description   

The class name generated for the entry point is a hardcoding of the service URL.
I found no way to rename this class with the maven plugin.



 Comments   
Comment by gdavison [ 08/Mar/12 04:41 PM ]

Fixed in duplicate issue WADL-43





[WADL-36] 1.1-SNAPSHOT unusable. Requests do not return results. Created: 04/Nov/10  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: matomira Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 36
Tags:
Participants: gdavison and matomira

 Description   

The code generated is wrong. No request returns a result.
I had to use 1.0-SNAPSHOT as a workaround.



 Comments   
Comment by gdavison [ 08/Mar/12 04:40 PM ]

Is this still true of the 1.1.1 version? You don't specify a test case.





[WADL-35] No way to get HTTP response code Created: 04/Nov/10  Updated: 08/Mar/12  Resolved: 08/Mar/12

Status: Resolved
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Major
Reporter: matomira Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 35
Tags:
Participants: gdavison and matomira

 Description   

There is no way to obtain an HTTP status code from the result of the request.
Only the HttpURLConnection error stream is returned when the request fails.



 Comments   
Comment by gdavison [ 08/Mar/12 04:39 PM ]

You can use the ClientResponse.class as a generic parameter in order to get hold of the entire response object,





[WADL-34] Invalid generated function signatures and arguments. Created: 07/Jul/10  Updated: 08/Mar/12  Resolved: 08/Mar/12

Status: Closed
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nexj Assignee: Unassigned
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 34
Tags:
Participants: gdavison and nexj

 Description   

Missing null checks for functions called with null values from generated code.
Duplicate identical methods generated causing collisions during compilation.
Mismatch in argument types for generated functions.

Patch:
— wadl-core/src/main/java/org/jvnet/ws/wadl/util/JAXBDispatcher.java Sun Jan
18 23:14:16 1970
+++ wadl-core/src/main/java/org/jvnet/ws/wadl/util/JAXBDispatcher.java Sun Jan
18 23:14:16 1970
@@ -142,14 +142,17 @@
h.setRequestMethod("POST");
h.setChunkedStreamingMode(-1);
DSDispatcher.setAccept(h, expectedMimeType);

  • h.setRequestProperty("Content-Type", inputMimeType);
    + if (inputMimeType!=null)
    + h.setRequestProperty("Content-Type", inputMimeType);
    for(String key: httpHeaders.keySet())
    h.setRequestProperty(key, httpHeaders.get(key).toString());
    h.setDoOutput(true);
    h.connect();
    OutputStream out = h.getOutputStream();
  • Marshaller m = jc.createMarshaller();
  • m.marshal(input, out);
    + if (input!=null) { + Marshaller m = jc.createMarshaller(); + m.marshal(input, out); + }
    out.close();
    mediaType = h.getContentType();
    if (h.getResponseCode() < 400)
    @@ -185,15 +188,18 @@
    HttpURLConnection h = (HttpURLConnection)c;
    h.setRequestMethod("PUT");
    h.setChunkedStreamingMode(-1);
    - DSDispatcher.setAccept(h, expectedMimeType);
    + if (expectedMimeType!=null)
    + DSDispatcher.setAccept(h, expectedMimeType);
    h.setRequestProperty("Content-Type", inputMimeType);
    for(String key: httpHeaders.keySet())
    h.setRequestProperty(key, httpHeaders.get(key).toString());
    h.setDoOutput(true);
    h.connect();
    OutputStream out = h.getOutputStream();
    - Marshaller m = jc.createMarshaller();
    - m.marshal(input, out);
    + if (input!=null) {+ Marshaller m = jc.createMarshaller();+ m.marshal(input, out);+ } }
    out.close();
    mediaType = h.getContentType();
    if (h.getResponseCode() < 400)
      • wadl-core/src/main/java/org/jvnet/ws/wadl2java/ResourceClassGenerator.java
        Sun Jan 18 23:14:16 1970
        +++ wadl-core/src/main/java/org/jvnet/ws/wadl2java/ResourceClassGenerator.java
        Sun Jan 18 23:14:16 1970
        @@ -50,6 +50,7 @@
        import java.io.IOException;
        import java.net.MalformedURLException;
        import java.util.HashMap;
        +import java.util.Iterator;
        import java.util.List;
        import java.util.Map;
        import javax.xml.bind.JAXBContext;
        @@ -71,6 +72,7 @@
        private JFieldVar $dsDispatcher;
        private JFieldVar $uriBuilder;
        private JFieldVar $jaxbContext;
        + private JFieldVar $objFactory;
        private JFieldVar $templateMatrixParamValMap;
        private JDefinedClass $class = null;
        private JavaDocUtil javaDoc;
        @@ -138,6 +140,7 @@
        $dsDispatcher = $impl.field(JMod.PRIVATE, DSDispatcher.class,
        "_dsDispatcher");
        $uriBuilder = $impl.field(JMod.PRIVATE, UriBuilder.class, "_uriBuilder");
        $jaxbContext = $impl.field(JMod.PRIVATE, JAXBContext.class, "_jc");
        + $objFactory = $impl.field(JMod.PRIVATE, pkg._getClass("ObjectFactory"),
        "_factory");
        JClass mapOfStringObject =
        codeModel.ref(HashMap.class).narrow(String.class, Object.class);
        $templateMatrixParamValMap = $impl.field(JMod.PRIVATE,
        mapOfStringObject, "_templateAndMatrixParameterValues");

@@ -168,6 +171,8 @@
$ctorBody.assign($jaxbContext,
codeModel.ref(JAXBContext.class).staticInvoke("newInstance").arg(JExpr.lit(generatedPackages)));
// codegen: jaxbDispatcher = new JAXBDispatcher(jc);
$ctorBody.assign($jaxbDispatcher,
JExpr._new(codeModel.ref(JAXBDispatcher.class)).arg($jaxbContext));
+ // codegen: factory = new ObjectFactory();
+ $ctorBody.assign($objFactory,
JExpr._new(pkg._getClass("ObjectFactory")));
}
// codegen: dsDispatcher = new DSDispatcher();
$ctorBody.assign($dsDispatcher,
JExpr._new(codeModel.ref(DSDispatcher.class)));
@@ -342,6 +347,27 @@
RepresentationNode outputRep, boolean isAbstract) {
generateDSMethodDecl(exceptionMap, method, includeOptionalParams,
inputRep, outputRep, isAbstract);
generateJAXBMethodDecl(exceptionMap, method, includeOptionalParams,
inputRep, outputRep, isAbstract);
+
+ JMethod[] methods = $class.methods().toArray(new JMethod[0]);
+
+ // search for identical declarations of methods and if found then
remove the duplicate declarations
+ for (int i = 0; i < methods.length; ++i) {
+ JMethod genMethod = methods[i];
+ JType[] genParamTypes = genMethod.listParamTypes();
+ for (Iterator<JMethod> itr = $class.methods().iterator();
itr.hasNext() {
+ JMethod jMethod = itr.next();
+ if (genMethod != jMethod &&
genMethod.name().equals(jMethod.name()) && genMethod.listVarParamType() ==
jMethod.listVarParamType()) {
+ JType[] paramTypes = jMethod.listParamTypes();
+ if (genParamTypes.length == paramTypes.length) { + boolean equal = true; + for (int j = 0; j < genParamTypes.length && equal; ++j) + equal = genParamTypes[j] == paramTypes[j]; + if (equal) + itr.remove(); + }
+ }
+ }
+ }
}

/**
@@ -593,7 +619,7 @@
$executeMethod.arg(JExpr._null());
$executeMethod.arg(JExpr._null());
} else { - $executeMethod.arg(JExpr.ref("input")); + $executeMethod.arg($objFactory.invoke("create"+getTypeFromElement(inputRep.getElement()).name()).arg(JExpr.ref("input"))); $executeMethod.arg(JExpr.lit(inputRep.getMediaType())); }
}



 Comments   
Comment by gdavison [ 08/Mar/12 04:48 PM ]

This code has now been removed, we rely on the Jersey client.





[WADL-33] Custom HTTP methods unsupported by Java but code still generated. Created: 07/Jul/10  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Closed
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: 1.2

Type: Bug Priority: Major
Reporter: nexj Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 33
Tags:
Participants: gdavison and nexj

 Description   

Custom HTTP methods unsupported by Java but code still generated.

Patch:
— wadl-core/src/main/java/org/jvnet/ws/wadl2java/Wadl2Java.java Sun Jan 18
23:14:16 1970
+++ wadl-core/src/main/java/org/jvnet/ws/wadl2java/Wadl2Java.java Sun Jan 18
23:14:16 1970
@@ -696,6 +696,23 @@
}

/**
+ * Check if the supplied method is supported by java.net.HttpURLConnection.
+ * Custom HTTP methods are not supported by java.net.HttpURLConnection, but
are supported by RFC2616.
+ * java.net.HttpURLConnection only supports: DELETE GET HEAD OPTIONS POST
PUT TRACE
+ * @param method the method to validate
+ */
+ protected boolean isSupportedMethod(Method method)
+ { + return "DELETE".equals(method.getName()) || + "GET".equals(method.getName()) || + "HEAD".equals(method.getName()) || + "OPTIONS".equals(method.getName()) || + "POST".equals(method.getName()) || + "PUT".equals(method.getName()) || + "TRACE".equals(method.getName()); + }
+
+ /**

  • Add a method to a resource.
  • Follow references to methods across WADL file boundaries
  • @param method the WADL method element to process
    @@ -710,7 +727,7 @@
    file = getReferencedFile(file, href);
    method = idMap.resolve(file, href, Method.class);
    }
  • if (method != null) {
    + if (method != null && isSupportedMethod(method)) {
    MethodNode n = new MethodNode(method, resource);
    Request request = method.getRequest();
    if (request != null) {


 Comments   
Comment by gdavison [ 08/Mar/12 04:43 PM ]

We now use the Jersey client which does support all the methods. (Using a reflection hack in my understanding.)

Comment by gdavison [ 12/Mar/13 12:31 PM ]

This is no longer an issue since we moved to use Jersey as the client





[WADL-32] Parent resources and headers inherited in contradiction to the spec Created: 07/Jul/10  Updated: 16/Mar/12  Resolved: 16/Mar/12

Status: Resolved
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: current

Type: Bug Priority: Major
Reporter: nexj Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 32
Tags:
Participants: gdavison and nexj

 Description   

Parent resources and headers inherited in contradiction to the spec.

Patch:
— wadl-core/src/main/java/org/jvnet/ws/wadl2java/ast/ResourceNode.java Sun Jan
18 23:14:16 1970
+++ wadl-core/src/main/java/org/jvnet/ws/wadl2java/ast/ResourceNode.java Sun Jan
18 23:14:16 1970
@@ -195,8 +195,7 @@
public List<Param> getQueryParams() { ArrayList<Param> completeList = new ArrayList<Param>(); completeList.addAll(getPathSegment().getQueryParameters()); - if (getParentResource() != null) - completeList.addAll(getParentResource().getQueryParams()); + // The spec explicitly forbids inheritance of query parameters @see "Resource" section return completeList; }

@@ -207,8 +206,7 @@
public List<Param> getHeaderParams() { ArrayList<Param> completeList = new ArrayList<Param>(); completeList.addAll(getPathSegment().getHeaderParameters()); - if (getParentResource() != null) - completeList.addAll(getParentResource().getHeaderParams()); + // The spec explicitly forbids inheritance of header parameters @see "Resource" section return completeList; }



 Comments   
Comment by gdavison [ 09/Mar/12 09:40 AM ]

The WADL spec explicitly exclude this in section 2.6, http://www.w3.org/Submission/wadl/#x3-120002.6

"Zero or more resource elements that describe sub-resources. Such sub-resources inherit matrix and template parameters from the parent resource since their URI is relative to that of the parent resource but they do not inherit query or header parameters specified globally for the parent resource."

Comment by gdavison [ 16/Mar/12 03:21 PM ]

Now consistent with the specification.

http://java.net/projects/wadl/sources/svn/revision/327





[WADL-24] allocating a new JAXBDispatcher on every request Created: 20/Aug/09  Updated: 08/Mar/12  Resolved: 08/Mar/12

Status: Closed
Project: wadl
Component/s: www
Affects Version/s: current
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: nira_amit Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 24
Tags:
Participants: gdavison and nira_amit

 Description   

in the generated code for my wadl file, a JAXBDispatcher is allocated in the
constructor of the Endpoint object. this seems to cost a lot in performance, and
i really only need one JAXBDispatcher for the class. i can't have just one
instance of the Endpoint object because the url has a parameter, which is kept
in the _templateAndMatrixParameterValues hash-map, so i will have thread safety
issues.

i don't want to manually change the generated code, can't the JAXBDispatcher be
a static member of the Endpoint class?

from the wadl file:

<resource path="categories/{categoryId}">
<method name="GET" id="getCategory">
<request>
<param name="locale" type="xsd:string" required="false"
style="query" default="en_US">
</param>
</request>
<response>
<representation mediaType="application/xml"
element="ofb:categories">
</representation>
<fault id="GetCategoriesFailed" mediaType="application/xml"
element="ofb:errors" />
</response>
</method>
</resource>

from the code:

public static class CategoriesCategoryId {

private JAXBDispatcher _jaxbDispatcher;
private DSDispatcher _dsDispatcher;
private UriBuilder _uriBuilder;
private JAXBContext _jc;
private HashMap<String, Object> _templateAndMatrixParameterValues;

public CategoriesCategoryId(String categoryid)
throws JAXBException
{
_jc = JAXBContext.newInstance("category");
_jaxbDispatcher = new JAXBDispatcher(_jc);
_dsDispatcher = new DSDispatcher();
_uriBuilder = new UriBuilder();
List<String> _matrixParamSet;
_matrixParamSet = _uriBuilder.addPathSegment("/catalog/rest/");
_matrixParamSet = _uriBuilder.addPathSegment("categories/{categoryId}");
_templateAndMatrixParameterValues = new HashMap<String, Object>();
_templateAndMatrixParameterValues.put("categoryId", categoryid);
}

...
...



 Comments   
Comment by gdavison [ 08/Mar/12 04:44 PM ]

We now use Jersey as the client, so this code is no longer valid.





[TYRUS-279] TyrusSession.broadcast should allow the client to provide a predicate Created: 06/Dec/13  Updated: 06/Dec/13

Status: Open
Project: tyrus
Component/s: core
Affects Version/s: 1.3.1
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

I feel that TyrusSession.broadcast should take a Predicate filter so that messages can easily be sent to sub sections of the connected clients.

So it should be possible to do something like this:

((TyrusSession)session).broadcast(message, s -> s.getUserProperties().conains("NAME"));

Ideally the interface should be serialisable so that the same expression could be used across the cluster as per bug TYRUS-278, you do need to be a little bit careful in this case as this blog shows:

http://kingsfleet.blogspot.co.uk/2013/12/lambda-will-it-serialize.html

Obviously the code will be written in a form that will work with JDK6 but can be more pleasant to use with JDK 8.






[TYRUS-278] Tyrus should be able to broadcast over a farm using JMS of other similar technology Created: 04/Dec/13  Updated: 04/Dec/13

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: 1.3.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison

 Description   

It would make a look simpler if Tyrus contains features natively to support using JMS queue or similar technology such as coherence to support sending messages to multiple nodes in the farm:

@ServiceEndpoint(...)
@TyrusCluster()
@TyrusJMSQueue(... something to configure a suitable queue ... )
public class MyClusteringEndpoint
{
}

This would probably only come into play if you make use of the new broadcast method on TyrusSession:

((TyrusSession)peer).broadcast(message)

The implication here is that is we were to allow filtering on the broadcast...

((TyrusSession)peer).broadcast(message, Session::isOpen)

.... this would probably require an interface that could be serialisable:

public interface SerializablePredicate<T>
extends Predicate<T>, Serializable {
}

You would have to be careful to not allow anonymous inner classes in this case as it would end up trying to serialise the entire outer object. I am not sure Lambda would be dealt with this incase, I guess you would have to make sure it doesn't capture too much of the containing state. I would get the ObjectOutput stream would fail in these cases.






[TYRUS-221] wss:// doesn't appear to function correctly via a http proxy. Created: 26/Jul/13  Updated: 05/Aug/13  Resolved: 05/Aug/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.2
Fix Version/s: 1.3

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Pavel Bucek

 Description   

So I have a fair simple example connecting to a wss:// service using a http proxy:

package project1;

import java.io.IOException;

import java.net.URI;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;

import javax.websocket.ClientEndpointConfig;
import javax.websocket.DeploymentException;
import javax.websocket.Endpoint;
import javax.websocket.MessageHandler;
import javax.websocket.Session;

import org.glassfish.tyrus.client.ClientManager;
import org.glassfish.tyrus.container.grizzly.GrizzlyClientSocket;
import org.glassfish.tyrus.server.Server;

public class TestUsingTyrusOnAdrs {
public static void main(String[] args) throws DeploymentException, IOException {

try {

System.setProperty("javax.net.debug", "all");

// Start the server

// Must do this on ADRS

//

ClientManager client = ClientManager.createClient();
client.getProperties().put(GrizzlyClientSocket.PROXY_URI, "http://localhost:8099");

final CountDownLatch latch = new CountDownLatch(2);

Endpoint beanClient = new Endpoint()
{
@Override
public void onOpen(Session session, javax.websocket.EndpointConfig endpointConfig) {

session.addMessageHandler(new MessageHandler.Whole<String>() {

@Override
public void onMessage(String message) { System.out.println(message); latch.countDown(); }
});

}
};

Session session =
client.connectToServer(beanClient, ClientEndpointConfig.Builder.create().build(),
URI.create("wss://localhost:7102/Project1/echo"));

session.getBasicRemote().sendText("Hello");
session.getBasicRemote().sendText("Hello");

// Await the message being echoed back

latch.await(20, TimeUnit.SECONDS);

// Close the session

session.close();

System.out.println("Everything is just dandy");

System.exit(0);

} catch (Exception ex) { ex.printStackTrace(System.out); System.exit(255); }

}
}

But rather than the expected CONNECT request to the proxy instead the data sent by the client is binary:

[0000..0015] 16 03 01 00 95 01 00 00 91 03 01 51 F2 8E 72 94
[0016..0031] 0B D3 08 D7 A0 E0 72 25 AE 9E D0 02 27 ED 37 F8
[0032..0047] 12 B4 6F 32 0E 2D 1C D4 B4 1C 04 00 00 2A C0 09
[0048..0063] C0 13 00 2F C0 04 C0 0E 00 33 00 32 C0 07 C0 11
[0064..0079] 00 05 C0 02 C0 0C C0 08 C0 12 00 0A C0 03 C0 0D
[0080..0095] 00 16 00 13 00 04 00 FF 01 00 00 3E 00 0A 00 34
.... etc

The output from the java client is as follows:

javax.websocket.DeploymentException: Handshake response not received.
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:305)
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:168)
at project1.TestUsingTyrusOnAdrs.main(TestUsingTyrusOnAdrs.java:57)
Process exited with exit code 255.



 Comments   
Comment by Pavel Bucek [ 26/Jul/13 03:30 PM ]

seems like Tyrus client tries to connect via SSL to the local proxy, which is clearly not correct.

Thanks for the report, will try to fix as soon as possible (but this one actually might need some support on Grizzly side, so it could take a while). Will keep this updated.

Comment by Pavel Bucek [ 29/Jul/13 02:09 PM ]

Initial fix is in the trunk (1.3-SNAPSHOT).

I need to discuss my approach with Grizzly team, but it would be nice if you can verify the fix - I tried to access wss://echo.websocket.org via internal proxy and it works fine..

thanks!
Pavel

Comment by gdavison [ 31/Jul/13 02:39 PM ]

It appears to be doing there right thing now, I can't see it working properly though do apparently to a bug in our proxy code. I will update you when I finally have it working.

Comment by gdavison [ 31/Jul/13 04:55 PM ]

Just work out the problem on my end, you can consider this bug resolved from my end.

Comment by Pavel Bucek [ 31/Jul/13 09:52 PM ]

great, thanks for evaluation!

Comment by Pavel Bucek [ 05/Aug/13 11:53 AM ]

fix merged to the master branch (commit a3a3f52edda6062d6e9e2a418776fbd081cf6b6d)





[TYRUS-181] WebSocket client ignores the ProxySelector Created: 17/May/13  Updated: 24/Jun/13  Resolved: 24/Jun/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-rc3
Fix Version/s: 1.1

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Tags:
Participants: gdavison and Pavel Bucek

 Description   

When you are running the client, it seems like the java.net.ProxySelector is not invoked or used so the normal proxy selection mechanism is not used.

For example in this very simple self-serving case, the select method is never called.

public static void main(String[] args) throws DeploymentException, IOException {


        final ProxySelector defaultPS = ProxySelector.getDefault();
        ProxySelector.setDefault(new ProxySelector() {

            @Override
            public List<Proxy> select(URI uri) {
                return defaultPS.select(uri);
            }

            @Override
            public void connectFailed(URI uri, SocketAddress sa, IOException ioe) {
                defaultPS.connectFailed(uri, sa, ioe);

            }
        });



        try {
            Server server = new Server("localhost", 7101, "/Project1", EchoService.class);
            server.start();

            // Right now we have to create a client


            ClientManager client = ClientManager.createClient();

            EchoBeanClient beanClient = new EchoBeanClient();

            Session session =
                client.connectToServer(beanClient, ClientEndpointConfig.Builder.create().build(),
                                       URI.create("ws://localhost:7101/Project1/echo"));

            // Wait until things are closed down

            while (session.isOpen()) {
                System.out.println("Waiting");
                TimeUnit.MILLISECONDS.sleep(10);
            }

            //

            //

            System.out.println("Client session closed, presume we have a result " + session);


        } catch (Exception ex) {

            ex.printStackTrace(System.out);
        }


    }

This is the standard method of configuring a proxy in the JDK and should be observed.



 Comments   
Comment by Pavel Bucek [ 22/May/13 03:38 PM ]

Tyrus client currently does not support proxies at all. Targeted for 1.1 release.

Comment by Pavel Bucek [ 04/Jun/13 05:19 PM ]

Some simple proxy support is currently in the trunk:

ClientManager client = ClientManager.createClient();
client.getProperties().put(GrizzlyClientSocket.PROXY_URI, "http://my.proxy.org:80");
client.connectToServer( ... );

There is no ProxySelector support yet (I would need to introduce some kind of properties to have the possibility to disable it and so on, so it was simpler to make a single property to be able to enable proxy per client instance).

Can you please try current trunk (rev 657+) and let me know whether it works for you?

Thanks!

Comment by Pavel Bucek [ 24/Jun/13 12:55 PM ]

resolving as fixed for Tyrus 1.1; further improvements may be discussed in TYRUS-204.

Thanks Gerard for verifying and testing





[TYRUS-176] connectToServer returning before connection is complete Created: 30/Apr/13  Updated: 11/Jun/13  Resolved: 11/Jun/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-rc3
Fix Version/s: 1.1

Type: Bug Priority: Critical
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.7u10


Tags:
Participants: gdavison and Pavel Bucek

 Description   

If you run the following code:

for (int i = 0; i < 100; i++) {
               ClientManager client = ClientManager.createClient();
               EchoBeanClient beanClient = new EchoBeanClient();

               Session session = client.connectToServer(
                       beanClient, 
                       ClientEndpointConfig.Builder.create().build(),
                       URI.create("ws://localhost:8025/echo"));

               session.getBasicRemote().sendText("OtherHello");

               // Wait until things are closed down

               if (false)
               {
                   while (session.isOpen()) {
                       System.out.println("Waiting");
                       TimeUnit.MILLISECONDS.sleep(10);
                   }
               }
               else {
                   beanClient.latch.await();
                   session.close();
               }

               //

               System.out.println("Client session closed, presume we have a result "  + session);
           }

You will find that it will fail around 6/1000 times with the following exception:

INFO: WebSocket server started.
Server connected SessionImpl{uri=/echo, id='b101e686-b40b-4c93-8f60-b06c8040a18d', endpoint=EndpointWrapper{endpointClass=null, endpoint=org.glassfish.tyrus.core.AnnotatedEndpoint@7da150, uri='/echo', contextPath='/'}} javax.websocket.server.DefaultServerEndpointConfig@1e98b70
java.lang.RuntimeException: Socket is not connected.
	at org.glassfish.tyrus.container.grizzly.GrizzlyClientSocket.send(GrizzlyClientSocket.java:229)
	at org.glassfish.tyrus.server.TyrusRemoteEndpoint.sendText(TyrusRemoteEndpoint.java:101)
	at org.glassfish.tyrus.core.RemoteEndpointWrapper.sendSyncText(RemoteEndpointWrapper.java:187)
	at org.glassfish.tyrus.core.RemoteEndpointWrapper$Basic.sendText(RemoteEndpointWrapper.java:86)
	at websocket.EchoBeanMain.main(EchoBeanMain.java:42)

This would suggest there is some kind of race condition going on.



 Comments   
Comment by gdavison [ 30/Apr/13 02:27 PM ]

I can provide test data; but the link to attach files appears to be missing.

Comment by Pavel Bucek [ 11/Jun/13 03:53 PM ]

fixed in the trunk





[JERSEY-2472] jersey-tests-integration-servlet-2.5-mvc-3 module tests fail on English machine. Created: 08/Apr/14  Updated: 22/Apr/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 2.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, OEL 5, JDK 1.7u45, Maven 3.11


Tags:
Participants: gdavison, Jakub Podlesak and Libor Kramolis

 Description   

The test appears to contain an accented name that is causing the test to fail unnecessarily on my english machine:

Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.111 sec - in org.glassfish.jersey.tests.integration.servlet_25_mvc_3.BookstoreITCase

Results :

Failed tests: 
  ItemITCase.testResourceAsHtmlUtf8:67->TestSupport.assertResponseContains:82 Response should contain Ha?ek but was: 






<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <title>Book</title>
    </head>
    <body>

        <h1>Svejk</h1>

        Book from Jaroslav Ha?ek

        
<p>
<a href="../../">Back</a>
<hr>
<div align="right">
    Common footer (title Svejk)
</div>


    </body>
</html>


Tests run: 8, Failures: 1, Errors: 0, Skipped: 0

I work around this by just running the tests in the next module; this is the only jersey test to fail on my machine.



 Comments   
Comment by Libor Kramolis [ 19/Apr/14 04:53 PM ]

Could explain you environment in more detail? We do not have a problems to build it.

Check your MAVEN_OPTS, LANG and other LC_* linux system environments. You can also attach result of mvn --version execution.

Comment by gdavison [ 22/Apr/14 01:25 PM ]

It is the default OEL 5 used internal to build Oracle VM in the US: I can provide you access if you are internal to Oracle.

LC_ALL=en_GB
LANG=en_GB.UTF-8
MAVEN_OPTS=-Xmx1g -XX:MaxPermSize=500m

And maven is the 3.2.1

Comment by Jakub Podlesak [ 22/Apr/14 02:47 PM ]

Hi Gerard, could you please provide me access to the machine? Please e-mail me to jakub.podlesak at ..., thanks!

Comment by Jakub Podlesak [ 22/Apr/14 04:54 PM ]

Thanks for the access, i am able to reproduce.





[JERSEY-2467] ResourceModel not complete for sub resources Created: 01/Apr/14  Updated: 19/Apr/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.6
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, JDK 7


File Attachments: Zip Archive SubResourceModelMoreSpecific.zip    
Tags:
Participants: gdavison

 Description   

So I am trying to vist the model provided by ExtendedResourceConfig; but I am finding that the information for sub resources is missing. The example attached to this issue is suppose to create a map of Resource class to path to aid the delcarative linking code; but it only iterates down one level.

This means that the output of the code is:

GET ..../root
class project1.SubResource : /root/{sub}

rather than the expected

GET ..../root
class project1.SubResource : /root/{sub}
class project1.SubSubResource : /root/{sub}/{subsub}

Note that the single resource method for the GET operation is also missing from the SubResource Resource instance. This may or may not be part of the same issue; but would ideally be fixed at the same time.






[JERSEY-2369] Cannot access any resourced when deploying Jersey 2.5.1 to WLS 12.1.2 Created: 28/Jan/14  Updated: 11/Feb/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.5.1
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive JerseyIn1212.zip    
Tags: wls
Participants: gdavison

 Description   

I tried to deploy a simple Jersey 2.x application to WLS 12.1.2 and while it deploys fine and the application.wadl can be accessed - we found that the service itself wouldn't find any resources. They do appear to be there though as trying to register a resource at the same location results in a failure.

The weblogic.xml we are using is as follows - this resolves the basic class loading issues at startup.

<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd"
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<container-descriptor>
<prefer-application-packages>
<package-name>com.google.*</package-name>
<package-name>com.sun.jersey.*</package-name>
<!-- jsr311*.jar -->
<package-name>javax.ws.rs.*</package-name>
<package-name>META-INF/services</package-name>

</prefer-application-packages>

</container-descriptor>
</weblogic-web-app>

I have attached a JDeveloper project with example code which will require the attached libraries to be modified to point at all three directories taken from:

http://repo1.maven.org/maven2/org/glassfish/jersey/bundles/jaxrs-ri/2.5.1/jaxrs-ri-2.5.1.zip



 Comments   
Comment by gdavison [ 28/Jan/14 02:55 PM ]

Sorry I should say that the application.wadl lists not resources but it is definitely coming from Jersey 2.5.1:

<?xml version="1.0" encoding="UTF-8"?>
<ns0:application xmlns:ns0="http://wadl.dev.java.net/2009/02">
<ns0:doc xmlns:ns1="http://jersey.java.net/" ns1:generatedBy="Jersey: 2.5.1 2014-01-02 13:43:00"/>
<ns0:doc xmlns:ns2="http://jersey.java.net/" ns2:hint="This is simplified WADL with user and core resources only. To get full WADL with extended resources use the query parameter detail. Link: http://localhost:7203/Project1/application.wadl?detail=true"/>
<ns0:grammars/>
<ns0:resources base="http://localhost:7203/Project1/"/>
</ns0:application>

And when you send a request to the expected paths 404 is returned.





[JERSEY-2290] Extended WADL could be greatly simplified using standard WADL features Created: 20/Dec/13  Updated: 10/Jan/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 2.4.1
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File original.wadl     File simplified.wadl    
Tags: wadl
Participants: gdavison and Miroslav Fuksa

 Description   

It is possible to simplify the the new "expanded" WADL as generated by default in Jersey 2.x.

In particular there is a lot of repetition of the OPTIONS element, this can be solved by externalising a method object and referencing it in each place it is used. Also there is no need to multiple OPTIONS method as they can just have one with multiple representations.

The resource_type used to reference the application.wadl is refactored out into resource_type, this allows a clearer visual separation of user resources and system meta resources.

See attached original.wadl and the hand editing simplified.wadl



 Comments   
Comment by Miroslav Fuksa [ 10/Jan/14 02:29 PM ]

I am moving this issue to backlog now. I think the most useful part of this request would be to aggregate all OPTIONS methods into one method and list all representations (of course make it general for all method). This would save lot of XML code in WADL. Extracted from attached example:

<ns0:method id="options" name="OPTIONS">
<ns0:response>
<ns0:representation mediaType="application/vnd.sun.wadl+xml"/>
<ns0:representation mediaType="text/plain"/>
<ns0:representation mediaType="/"/>
</ns0:response>
</ns0:method>

instead of having 3 OPTIONS methods.





[JERSEY-2271] wadl published by trivial class incorrectly also described interface for getting hold of the wadl Created: 12/Dec/13  Updated: 04/Feb/14  Resolved: 21/Dec/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.4.1
Fix Version/s: 2.5.1

Type: Improvement Priority: Critical
Reporter: gdavison Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 17 hours, 6 minutes
Original Estimate: Not Specified
Environment:

Linux


Tags: 17942392 bdb wls
Participants: gdavison and Miroslav Fuksa

 Description   

If you run this following simple service under Jersey 2.4.1:

@Path("project1")
public class GenericResource {

@GET
@Produces("text/plain")
public String getData() { return "Hello"; }

public static void main(String[] args) { HttpServer d = JdkHttpServerFactory.createHttpServer( URI.create("http://localhost:8101/project1"), new ResourceConfig().register(new GenericResource())); }

}

And then perform a get on "http://localhost:8101/project1/application.wadl" then you get the following WADL back:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<application xmlns="http://wadl.dev.java.net/2009/02">
<doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 2.4.1 2013-11-08 12:08:47"/>
<grammars/>
<resources base="http://localhost:8101/project1/">
<resource path="project1">
<method id="getData" name="GET">
<response>
<representation mediaType="text/plain"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="application/vnd.sun.wadl+xml"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="text/plain"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="/"/>
</response>
</method>
</resource>
<resource path="application.wadl">
<method id="getWadl" name="GET">
<response>
<representation mediaType="application/vnd.sun.wadl+xml"/>
<representation mediaType="application/xml"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="text/plain"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="/"/>
</response>
</method>
<resource path="{path}">
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="path" style="template" type="xs:string"/>
<method id="geExternalGrammar" name="GET">
<response>
<representation mediaType="application/xml"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="text/plain"/>
</response>
</method>
<method id="apply" name="OPTIONS">
<request>
<representation mediaType="/"/>
</request>
<response>
<representation mediaType="/"/>
</response>
</method>
</resource>
</resource>
</resources>
</application>

Rather than the expected:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<application xmlns="http://wadl.dev.java.net/2009/02">
<doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 2.4.1 2013-11-08 12:08:47"/>
<grammars/>
<resources base="http://localhost:8101/project1/">
<resource path="project1">
<method id="getData" name="GET">
<response>
<representation mediaType="text/plain"/>
</response>
</method>
</resources>
</application>

It appears that this is because Jersey is not longer ignoring the special resource classes put in for this, this is a serious regression because the client generation tools and testing tools built into Jdeveloper now have a number of ext ran resources that we will have to present to the user with no method of filtering them.

A fix for this should be pushed to WLS 12.1.3 where it was originally seen.



 Comments   
Comment by Miroslav Fuksa [ 12/Dec/13 04:16 PM ]

Application contains resource which were registered by the user and resources which were added by Jersey (by ModelProcessors). However, at the end, application contains all resources and all resources are available to be requested. Therefore WADL contains all resources. It looks like correct behaviour for me.

We can implement the option to return only user defined methods in wadl. This would be controlled for example by query parameter (so, you will send GET request to application.wadl?onlyUserResources=true).

I think the current behaviour should be still the default one (means we should still show all resources by default).

Comment by Miroslav Fuksa [ 21/Dec/13 09:44 AM ]

After discussion the solution is the following:

Now the WADL generated by default is the limited WADL which means it contains only user resource and not additional resources like OPTIONS methods. If full WADL with all resources is requested then query parameter "detail" should be used. For example:

http://localhost:8080/restApp/application.wadl?detail
(or http://localhost:8080/restApp/application.wadl?detail=true).

See the new updated documentation of WADL for more details.





[JERSEY-2207] OAuth filter fails to use proxy when using Apache HTTP Client Created: 08/Nov/13  Updated: 12/Nov/13  Resolved: 12/Nov/13

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 1.17
Fix Version/s: 1.18

Type: Bug Priority: Major
Reporter: gdavison Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: Not Specified

Tags:
Participants: gdavison and Michal Gajdos

 Description   

We are using com.sun.jersey.client.apache.ApacheHttpClient along with the OAuthClientFilter to try to connect to the twitter 1.1 API via the Oracle proxy.

We found that this would fail to connect because the call to requestTokenUri is performed without a proxy even though one is correctly configured for the client. We tracked this down to this line, basically the properties that configure the proxy settings are not passed into this new client request.

ClientResponse cr = handle(ClientRequest.create().build(requestTokenUri, HttpMethod.POST));

This is easily fixed by replacing this code with the following change:

ClientRequest tokenRequest = ClientRequest.create().build(requestTokenUri, HttpMethod.POST);
tokenRequest.getProperties().putAll(request.getProperties());
ClientResponse cr = handle(tokenRequest);

This ensures that the new request inherits any properties from the parent request, this actually need to be done twice as show by the suggested patch:

--- OAuthClientFilter.java	2013-01-16 21:47:08.000000000 +0000
+++ OAuthClientFilter.java	2013-11-08 10:15:39.509943100 +0000
@@ -243,7 +243,9 @@
                         // put together a request token request
                         state = State.UNMANAGED;
                         try {
-                            ClientResponse cr = handle(ClientRequest.create().build(requestTokenUri, HttpMethod.POST));
+                            ClientRequest tokenRequest = ClientRequest.create().build(requestTokenUri, HttpMethod.POST);
+                            tokenRequest.getProperties().putAll(request.getProperties());
+                            ClientResponse cr = handle(tokenRequest);
                             // requestToken request failed
                             if (cr.getStatus() >= 400) {
                                 return cr;
@@ -272,7 +274,10 @@
                     }
                     state = State.UNMANAGED;
                     try {
-                        ClientResponse cr = handle(ClientRequest.create().build(accessTokenUri, HttpMethod.POST));
+                        ClientRequest tokenRequest = ClientRequest.create().build(accessTokenUri, HttpMethod.POST);
+                        tokenRequest.getProperties().putAll(request.getProperties());
+                        ClientResponse cr = handle(tokenRequest);
+                       
                         // accessToken request failed
                         if (cr.getStatus() >= 400) {
                             return cr;





[JERSEY-2061] Client can be forced to connect to a resource with a different set of credentials if previously accessed via HttpURLConnection Created: 22/Aug/13  Updated: 14/Jan/14  Resolved: 14/Jan/14

Status: Resolved
Project: jersey
Component/s: security
Affects Version/s: 1.17, 2.4.1
Fix Version/s: 2.6

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: 0 minutes
Time Spent: Not Specified
Original Estimate: 0 minutes
Environment:

JDK 7u17, Linux


File Attachments: Java Source File AuthenticatorClientTest.java    
Tags: client security
Participants: gdavison, Marek Potociar and Michal Gajdos

 Description   

The Java authenticator framework use by URL, HttpURLConnection and the like for user interface reasons will remember the credentials used to access a particular URI over the life of the VM until such time as this set of credentials return a 401 response.

Unfortunately this can mean that the default handler for the Client will inherit this pre-cached information. In this example the expected output should be:

username="authenticator",
username="jersey",

but instead when you run this code you see:

username="authenticator",
username="authenticator",

Here is the code that exercises the bug, if you modify the code to use Basic rather than Digest then it will pass; but that is because of JERSEY-2050.

package authenticatorissue;

import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.WebResource;
import com.sun.jersey.api.client.filter.HTTPDigestAuthFilter;
import com.sun.jersey.api.container.httpserver.HttpServerFactory;
import com.sun.jersey.api.core.ClassNamesResourceConfig;
import com.sun.net.httpserver.HttpServer;

import java.io.DataInputStream;

import java.net.Authenticator;
import java.net.PasswordAuthentication;
import java.net.URL;

import javax.ws.rs.GET;
import javax.ws.rs.HeaderParam;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

public class VerifyIssue {
    public static void main(String[] args) throws Exception {

        // Publish the REST endpoint

        HttpServer server =
            HttpServerFactory.create("http://localhost:8080/rest",
                                     new ClassNamesResourceConfig(GetResourceBasic.class));

        try {
            server.start();

            // Replace the VM default authenticator with one that just returns authenticator/authenticator

            Authenticator.setDefault(new Authenticator() {

                @Override
                protected PasswordAuthentication getPasswordAuthentication() {
                    return new PasswordAuthentication("authenticator", "authenticator".toCharArray());
                }
            });

            // Get that resource using just URL

            URL resource = new URL("http://localhost:8080/rest/get-basic");
            try (DataInputStream dis = new DataInputStream(resource.openStream())) {

                byte buffer[] = new byte[1024];
                int length = dis.read(buffer);
                System.out.println(new String(buffer, 0, length));

            }

            // Now get that resourece using a Jersey client

            Client client = Client.create();
            client.addFilter(new HTTPDigestAuthFilter("jersey", "jersey"));

            WebResource webResource = client.resource(resource.toURI());

            System.out.println(webResource.get(String.class));


            //

        } finally {
            server.stop(0);

        }

    }


    @Path("/get-basic")
    public static class GetResourceBasic {

        @GET
        public Response get(@HeaderParam("authorization") String authenticate) {

            if (authenticate != null) {
                // Dump out the user name
                return Response.ok(authenticate.split(" ")[1].split(", ")[0]).build();

            } else {
                return Response.status(Response.Status.UNAUTHORIZED).header("WWW-Authenticate",
                                                                            "Digest realm=\"example\", qop=\"auth,auth-int\", nonce=\"dcd98b7102dd2f0e8b11d0f600bfb0c093\", opaque=\"5ccc069c403ebaf9f0171e9517f40e41\"").build();
            }
        }
    }

}


 Comments   
Comment by Michal Gajdos [ 05/Dec/13 05:14 PM ]

Targeting for 2.6 although I don't thing this has a solution. When authentication mechanism is being negotiated (401 from server + WWW-Authenticate header) the HttpUrlConnection will send authorization header itself (since it has an instance of Authenticator set) without delegating into digest filter. Based on the code ([1]) I don't see a way how to override it.

[1] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/net/www/protocol/http/HttpURLConnection.java

Comment by Michal Gajdos [ 05/Dec/13 05:16 PM ]

Test-Case attached.

Comment by Marek Potociar [ 14/Jan/14 10:18 AM ]

There does not seem to be a viable solution for the issue. Closing as won't fix.





[JERSEY-2050] HTTPBasicAuthFilter doesn't check for challenge/response as per HTTPDigestAuthFilter Created: 20/Aug/13  Updated: 18/Dec/13  Resolved: 18/Dec/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.17
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: gdavison Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 1 day, 1 hour
Original Estimate: 2 hours
Environment:

1.17.1 on JDK 7u17


Tags:
Participants: gdavison and Miroslav Fuksa

 Description   

If you add both the Basic and Digest filters to a client then you will find that the Basic always overrides the response even though the response specifies a particular authorisation style:

It is possible work around this by copying over code from HTTPDigestAuthFilter; but obviously a more comprehensive fix would be to share the relevant code between the two classes.

--- HTTPBasicAuthFilter.java	Tue Aug 20 14:13:05 2013
+++ HTTPBasicAuthFilter.java	Tue Aug 20 14:13:05 2013
@@ -49,2 +47,0 @@
-import java.io.UnsupportedEncodingException;
-import java.nio.charset.Charset;
@@ -52,2 +48,0 @@
-import javax.ws.rs.core.HttpHeaders;
-
@@ -56,0 +52,2 @@
+import com.sun.jersey.api.client.ClientResponse.Status;
+import com.sun.jersey.api.client.filter.ClientFilter;
@@ -58,0 +56,12 @@
+import java.io.UnsupportedEncodingException;
+
+import java.nio.charset.Charset;
+
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.regex.Matcher;
+
+import java.util.regex.Pattern;
+
+import javax.ws.rs.core.HttpHeaders;
+
@@ -70,0 +80,6 @@
+     * Pattern to parse key value pairs like: 'foobar="foo bar",toto=titi,...'
+     */
+    static private final Pattern TOKENS_PATTERN = Pattern.compile("(\\w+)\\s*=\\s*(\"([^\"]+)\"|(\\w+))\\s*,?\\s*");
+
+
+    /**
@@ -108 +123,15 @@
-        if (!cr.getHeaders().containsKey(HttpHeaders.AUTHORIZATION)) {
+        ClientResponse response = getNext().handle(cr);
+
+        // The server asked for authentication ? (status 401)
+        if (response.getClientResponseStatus() == Status.UNAUTHORIZED
+          && !cr.getHeaders().containsKey(HttpHeaders.AUTHORIZATION)) {
+
+            // Parse the www-authentication headers
+            HashMap<String, String> map = parseHeaders(response.getHeaders().get(HttpHeaders.WWW_AUTHENTICATE));
+
+            // No basic authentication request found ? => We can do nothing more
+            if (map == null) {
+                return response;
+            }
+            
+            // Add new headers
@@ -109,0 +139,3 @@
+            
+            //
+            return this.handle(cr);
@@ -111 +143,2 @@
-        return getNext().handle(cr);
+
+        return response;
@@ -113 +146,65 @@
-}
+
+
+    /**
+     * Parse the "authenticate" header of the server response.
+     * Key/Value pairs are filled.
+     * If several schemes are found, only the DIGEST one is returned.
+     * If no www-authenticate field is found with the "Digest" scheme, null is returned
+     *
+     * @param lines All www-authenticate lines of the header.
+     * @return parsed headers, null when "Digest" scheme not present.
+     */
+    static HashMap<String, String> parseHeaders(Collection<String> lines) {
+
+        // Loop on lines
+        for (String line : lines) {
+
+            // Split spaces
+            String[] parts = line.trim().split("\\s+", 2);
+
+            // There should be 2 parts
+            if (parts.length != 2) {
+                continue;
+            }
+
+            // Check the scheme
+            if (!parts[0].toLowerCase().equals("basic")) {
+                continue;
+            }
+
+            // Parse the tokens
+            Matcher match = TOKENS_PATTERN.matcher(parts[1]);
+
+            // Create map
+            HashMap<String, String> result = new HashMap<String, String>();
+
+            // Find next pair
+            while (match.find()) {
+
+                // Defensive check, we should have 4 groups (key)=("(val)" | (val))
+                int nbGroups = match.groupCount();
+                if (nbGroups != 4) {
+                    continue;
+                }
+
+                // Key without quotes
+                String key = match.group(1);
+                String valNoQuotes = match.group(3);
+                String valQuotes = match.group(4);
+
+                // Put pairs in maps
+                result.put(key, (valNoQuotes == null) ? valQuotes : valNoQuotes);
+
+            } // End of loop on pairs
+
+            return result;
+
+        } // End of loop on lines
+
+        // No line with scheme "digest" found
+        return null;
+    }
+
+
+}
+


 Comments   
Comment by Miroslav Fuksa [ 14/Nov/13 04:22 PM ]

make the solution configurable (still allow preemptive authentication for basic http auth filter)





[JERSEY-1675] Inconsistent generation of WADL for parameterized sub resources. Created: 28/Jan/13  Updated: 07/Feb/14  Resolved: 24/Oct/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.16
Fix Version/s: 1.18

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: wadl
Participants: gdavison and Marek Potociar

 Description   

Consider this simple resource class:

package project1;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.WebApplicationException;
import javax.ws.rs.core.Response;

@Path("/")
public class RootResource {

@Path("sub/{id}")
public ChildResource getChild(@PathParam("id") int id) {
if (id < 10) { return new ChildResource(id); }
else { throw new WebApplicationException(Response.Status.NOT_FOUND); }
}


@Path("{id}")
@GET
public String getChildString(@PathParam("id") int id) {
if (id < 10) { return Integer.toString(id); }
else { throw new WebApplicationException(Response.Status.NOT_FOUND); }
}

}

package project1;

import javax.ws.rs.*;

public class ChildResource {

int _id;

ChildResource(int id) { _id = id; }

@GET
@Produces("text/plain")
public String getChild() { return Integer.toString(_id); }
}

The inconsistency here is that

OPTIONS http://127.0.0.1:7101/Application1-Project1-context-root/resources/20

Will return a correctly defined WADL; but that the version that tried to access the sub resource returns a 404, page not found error.

OPTIONS http://127.0.0.1:7101/Application1-Project1-context-root/resources/sub/20

I think I would like the second URL to return a WADL as it make tooling so much easier to deal with.



 Comments   
Comment by Marek Potociar [ 24/Oct/13 12:43 PM ]

Not a critical issue. Will not fix in the sustained Jersey 1.x code.





[JERSEY-1663] UriBuilder doesn't enforce regex when built from path Created: 21/Jan/13  Updated: 29/Jan/13  Resolved: 28/Jan/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 2.0-m12
Fix Version/s: 2.0-m12, 2.0

Type: Bug Priority: Major
Reporter: gdavison Assignee: Marek Potociar
Resolution: Works as designed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison, Marek Potociar and Pavel Bucek

 Description   

If I run the following code I would expect a failure exception as the parameter doesn't match the reg-ex in the path:

UriBuilder b = UriBuilder.fromPath("http://127.0.0.1:7101/Application1-Client-context-root/resources/sub/{name: [a-zA-Z]+}");
URI uri = b.buildFromMap(new HashMap()
{{
put("name", "100");
}});
System.out.println(uri);

Instead the output is as follows:

http://127.0.0.1:7101/Application1-Client-context-root/resources/sub/100



 Comments   
Comment by Pavel Bucek [ 21/Jan/13 03:32 PM ]

Hi Gerard,

is this applicable to 1.17? (Or 2.0-m11?)

if so, can you please update "Affect version/s" field accordingly?

thanks,
Pavel

Comment by Marek Potociar [ 28/Jan/13 07:47 PM ]

See the JAX-RS 1.1 UriBuilder class-level javadoc (http://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/core/UriBuilder.html), which is very explicit about this case:

Template parameter regular expressions are ignored when building a URI, i.e. no validation is performed.





[JERSEY-1594] JSON-Schema generation doesn't take into account notation options Created: 19/Nov/12  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: 1.16
Fix Version/s: 1.18

Type: Bug Priority: Minor
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

The JSON-Schema feature doesn't take into account the notation selected in the JSON configuration:

http://jersey.java.net/nonav/documentation/latest/json.html#d4e949

This will result in inconsistent schema's from the data in the messages.



 Comments   
Comment by Marek Potociar [ 28/Jan/13 08:52 PM ]

Hi Gerard, since you asigned the issue to yourself, do you have any ETA on fixing it? Or was the assignment by mistake?

Comment by gdavison [ 27/Mar/13 04:14 PM ]

In SVN revision 5840





[JERSEY-1593] JSON-Grammar generation format is altered by POJOMappingFeature Created: 19/Nov/12  Updated: 27/Mar/13  Resolved: 27/Mar/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.16
Fix Version/s: 1.18

Type: Bug Priority: Major
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

If you set the POJOMappingFeature then the format of the JSON version of the WADL is quite different

<init-param>
<param-name>com.sun.jersey.api.json.POJOMappingFeature</param-name>
<param-value>true</param-value>
</init-param>

The format of the WADL should be the same no matter what this setting is.



 Comments   
Comment by Marek Potociar [ 28/Jan/13 08:53 PM ]

Any ETA or is this issue mis-assigned?

Comment by gdavison [ 27/Mar/13 04:14 PM ]

In SVN revision 5840





[JERSEY-1370] Problem invoking service with nested matrix parameters Created: 14/Aug/12  Updated: 21/Oct/13  Resolved: 18/Oct/13

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: Jakub Podlesak
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JERSEY-408 Get Matrix Parameter from current pat... Open
Tags:
Participants: andrewg95, gdavison and Jakub Podlesak

 Description   

I am working on a Matrix related bug; but I am not 100% sure that the correct behaviour is, so I have two classes:

@Path("/matrix")
public class MatrixParent {

   @MatrixParam("matrixParent")
   private String matrix;


   @Path("child")
   public MatrixExample get() {
       return new MatrixExample(matrix);
   }

   public void setMatrix(String matrix) {
       this.matrix = matrix;
   }

   public String getMatrix() {
       return matrix;
   }
}

and

public class MatrixExample {

   @MatrixParam("matrix")
   private String matrix;
   private String matrixParent;



   public MatrixExample(String matrix) {
       matrixParent = matrix;
   }


   @POST
   @Path("updateEmployee")
   @Produces("text/plain")
   public String updateEmployee() {
       return  matrix + " " + matrixParent;
   }

   public void setMatrix(String matrix) {
       this.matrix = matrix;
   }

   public String getMatrix() {
       return matrix;
   }
}

This results in a WADL that looks like this:

<ns0:application xmlns:ns0="http://wadl.dev.java.net/2009/02">
  <ns0:doc xmlns:ns1="http://jersey.java.net/" ns1:generatedBy="Jersey: 1.13-b01 03/09/2012 03:52 PM"/>
  <ns0:grammars/>
  <ns0:resources base="http://localhost:7101/SubResources_REST-WebService-context-root/resources/">
     <ns0:resource path="/matrix">
        <ns0:param name="matrixParent" style="matrix" xmlns:ns2="http://www.w3.org/2001/XMLSchema" type="ns2:string"/>
        <ns0:resource path="child">
           <ns0:param name="matrix" style="matrix" xmlns:ns3="http://www.w3.org/2001/XMLSchema" type="ns3:string"/>
           <ns0:resource path="updateEmployee">
              <ns0:method id="updateEmployee" name="POST">
                 <ns0:request>
                 </ns0:request>
                 <ns0:response>
                    <ns0:representation mediaType="text/plain"/>
                 </ns0:response>
              </ns0:method>
           </ns0:resource>
        </ns0:resource>
     </ns0:resource>
  </ns0:resources>
</ns0:application>

This all seems reasonable; but I doesn't seem to clear what the resultant URI should be, some sources suggest that matrix parameters could occur anywhere in the URI, so this should be valid:

http://..../matrix;matrixParent=X/child;matrix=X/updateEmployees

But this results an output of "null null null", but if you place all the matrix parameters at the end as is suggested by the WADL sepc

http://..../matrix/child/updateEmployees;matrix=X;matrixParent=X

only "matrixParent" value is populated.

The final bit of information is if I build the URI using UriBuilder then I get the first form of the URL which would suggest that the URL is correct, but that perhaps Jersey is parsing the parameters in correctly. I though I would check quickly before raising a bug because it was not clear just what is the correct format as this area appears to be poorly specified.



 Comments   
Comment by andrewg95 [ 25/Sep/12 01:38 AM ]

I believe this is the same issue as mentioned in JERSEY-408.
The bug appears to be caused by the implementation of MatrixParamInjectable.getValue() in MatrixParamInjectableProvider.java (Jersey 1.14). The code is always looking at the last path segment. It doesn't look like this method has access to the "current" path segment, so fixing this might be non-trivial.

Comment by Jakub Podlesak [ 18/Oct/13 03:19 PM ]

Indeed, this is a duplicate of JERSEY-408





[JERSEY-1369] UriBuilder doesn't deal with Matrix parameter properly when there is a path sub element Created: 14/Aug/12  Updated: 10/Oct/12  Resolved: 10/Oct/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: 2.0-m09

Type: Bug Priority: Major
Reporter: gdavison Assignee: Miroslav Fuksa
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 20 minutes
Original Estimate: Not Specified

Tags:
Participants: gdavison, Martin Matula and Miroslav Fuksa

 Description   

Consider these two tests along with the current test failures, it seems like UriBuilder doesn't deal with matrix parameters at multiple levels of the URI properly.

package client2;

import javax.ws.rs.core.UriBuilder;

import org.junit.Assert;
import org.junit.Test;

public class UriBuilderMAtrix {


    @Test
    public  void sameName() {
        UriBuilder first = UriBuilder.fromUri("http://www.com/").replaceMatrixParam("example", "one", "two");
        first = first.path("/child");
        System.out.println(first.build());
        first = first.replaceMatrixParam("example", "another");
        
        Assert.assertEquals(
            "http://www.com/;example=one;example=two/child;example=another", first.build());
        // java.lang.AssertionError: expected:<http://www.com/;example=one;example=two/child;example=another> but was:<http://www.com/;example=another>
    }

    @Test
    public  void different() {
        UriBuilder first = UriBuilder.fromUri("http://www.com/").replaceMatrixParam("example", "one", "two");
        first = first.path("/child");
        System.out.println(first.build());
        first = first.replaceMatrixParam("other", "another");

        Assert.assertEquals(
            "http://www.com/;example=one;example=two/child;other=another", first.build());
        // java.lang.AssertionError: expected:<http://www.com/;example=one;example=two/child;other=another> but was:<http://www.com/;other=another;example=one;example=two/child>
    }
}

Note that the documentation for UriBuilder.replaceMatrix states:

"Note that the matrix parameters are tied to a particular path segment; subsequent addition of path segments will not affect their position in the URI path."

So it should be possible to modify matrix parameters at different levels of the path without affecting the others



 Comments   
Comment by Martin Matula [ 21/Aug/12 12:06 PM ]

Pavel, please look into this. You may want to sync up with Marek if any clarifications need to be added to the spec.

Comment by Miroslav Fuksa [ 10/Oct/12 09:25 AM ]

Fixed by JERSEY-1415.

Comment by Miroslav Fuksa [ 10/Oct/12 09:26 AM ]

Fixed by JERSEY-1415.





[JERSEY-1368] UriBuilderImpl.clone doesn't function correctly for matrix and query parameters if build has not been called Created: 14/Aug/12  Updated: 13/Sep/12  Resolved: 21/Aug/12

Status: Closed
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: 1.13

Type: Bug Priority: Major
Reporter: gdavison Assignee: Martin Matula
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Martin Matula

 Description   

Consider the following snipped of code:

UriBuilder first = UriBuilder.fromUri("http://www.com/").replaceMatrixParam("example", "one", "two");
UriBuilder second = first.clone();
System.out.println(first.build());
System.out.println(second.build());

If you ran this code you would expect the following output:

http://www.com/;example=one;example=two
http://www.com/;example=one;example=two

But instead you get:

http://www.com/;example=one;example=two
http://www.com/

The problem is that the copy constructor doesn't copy the state of the matrixParams and queryParams, if you perform a build before the clone then the values are written throught to the path.



 Comments   
Comment by Martin Matula [ 21/Aug/12 12:10 PM ]

This looks like a duplicate of http://java.net/jira/browse/JERSEY-1081 which is fixed in 1.13. Are you sure 1.13 is the version you are working with??

Comment by gdavison [ 13/Sep/12 09:22 AM ]

I must have been using an interim build, now works fine.





[JERSEY-1337] Boolean Matrix Parameters are interpreted differently from the WADL specification Created: 02/Aug/12  Updated: 08/Aug/13  Resolved: 23/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Pavel Bucek

 Description   

As per section http://www.w3.org/Submission/wadl/#x3-130002.6.1 of the WADL specification a boolean matrix parameter is represented either by the presence of absence of the property rather than the =X notation.

Interestingly the original MatrixURI proposal doesn't have anything to say on the matter:

http://www.w3.org/DesignIssues/MatrixURIs.html

This could be a problem with the WADL specification; but if you invoke the following Jersey service:

package project1;

import javax.ws.rs.GET;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.Path;

@Path("/matrix")
public class MatrixExample {

private String con;

public MatrixExample() {
}

@GET
public String matrixExample(@MatrixParam("param") String param, @MatrixParam("boolean") boolean flag) { return param + " " + con + " " + flag; }

@MatrixParam("con")
public void setCon(String con) { this.con = con; }

public String getCon() { return con; }
}

With the URI http://..../matrix;boolean;param=X;con=X then the result is "X X false" rather than the "X X true" as would be expected by the WADL specification.

I checked and the JSR311 spec doesn't say anything specific on the interpretation of this value.



 Comments   
Comment by gdavison [ 02/Aug/12 03:15 PM ]

Not that UriBuilder is consistent so that

UriBuilder.fromUri("http://...").matrixParam("boolean", true).build()

Returns "http://...;boolean=true" and not "http://...;boolean"

Comment by Pavel Bucek [ 23/Aug/12 02:21 PM ]

looks like WADL spec issue as you pointed out. I don't think there is anything we should change in Jersey. Closing as won't fix for now, feel free to add comment/reopen.





[JERSEY-1336] WADL for Matrix parameters are in contravention of the WADL specification Created: 02/Aug/12  Updated: 23/Aug/12  Resolved: 23/Aug/12

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.13
Fix Version/s: 1.14

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Pavel Bucek

 Description   

Section 2.12 of the WADL specification states that a matrix parameter can only exist on a resource element:

http://www.w3.org/Submission/wadl/#x3-250002.12

But if you run this trivial example:

package project1;

import javax.ws.rs.GET;
import javax.ws.rs.MatrixParam;
import javax.ws.rs.Path;

@Path("/matrix")
public class MatrixExample {

private String con;

public MatrixExample() {
}

@GET
public String matrixExample(@MatrixParam("param") String param) { return param + " " + con; }

@MatrixParam("con")
public void setCon(String con) { this.con = con; }

public String getCon() { return con; }
}

Then you end up with the following WADL which is in contravention of the specification:

<?xml version="1.0" encoding="UTF-8"?>
<ns0:application xmlns:ns0="http://wadl.dev.java.net/2009/02">
<ns0:doc xmlns:ns1="http://jersey.java.net/" ns1:generatedBy="Jersey: 1.13-b01 03/09/2012 03:52 PM"/>
<ns0:grammars/>
<ns0:resources base="http://localhost:7101/Application1-Project1-context-root/resources/">
<ns0:resource path="/matrix">
<ns0:param name="con" style="matrix" xmlns:ns2="http://www.w3.org/2001/XMLSchema" type="ns2:string"/>
<ns0:method id="matrixExample" name="GET">
<ns0:request>
<ns0:param name="param" style="matrix" xmlns:ns3="http://www.w3.org/2001/XMLSchema" type="ns3:string"/>
</ns0:request>
<ns0:response>
<ns0:representation mediaType="/"/>
</ns0:response>
</ns0:method>
</ns0:resource>
</ns0:resources>
</ns0:application>

The second matrix parameter should be added at the resource level, this shouldn't be a problem for other methods as parameter are optional by default.



 Comments   
Comment by Pavel Bucek [ 23/Aug/12 01:58 PM ]

fix submitted to review





[JERSEY-1312] Explore and determine what we should bring over from Jersey 1.x jersey-server-linking project Created: 25/Jul/12  Updated: 11/Feb/14  Resolved: 06/Feb/14

Status: Resolved
Project: jersey
Component/s: extensions
Affects Version/s: None
Fix Version/s: 2.6

Type: Task Priority: Major
Reporter: Martin Matula Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Martin Matula




[JERSEY-1259] Array out of bounds error when you specify an empty list of @Produces annotation Created: 28/Jun/12  Updated: 16/Jul/12  Resolved: 16/Jul/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 1.14

Type: Bug Priority: Major
Reporter: gdavison Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 2 hours
Original Estimate: Not Specified

File Attachments: File ProducesNothingPatch.diff    
Tags:
Participants: gdavison and Michal Gajdos

 Description   

If you try to specify that a method doesn't produce anything:

@PUT
@Produces({})
public Response putObject()

{ return Response.create(new URI(....)).build(); }

You end with an array out of bounds error HttpHeaderReader.readQualitySourceMediaType when building up the WADL.

I have supplied a proposed patch and a unit test. The change means that in the above case an empty response element is created in the WADL as not representations are specified.



 Comments   
Comment by gdavison [ 28/Jun/12 03:42 PM ]

Workaround it to have the method return void, so the WADL is correct, and then throw an exception on the last line.

throw new WebApplicationException(Response....);

Comment by Michal Gajdos [ 10/Jul/12 09:35 AM ]

Can you describe your use case for using @Produces with no value specified? Because I think this may be violating the spec:

An implementation MUST NOT invoke a method whose effective value of @Produces does not match
the request Accept header.

Comment by gdavison [ 10/Jul/12 09:47 AM ]

So you might have a method that just returns a status code of 202, for example when performing some kind of asynchronous action.:

<method name="POST">
<request>
<representation xmlns:t="urn:example" mediaType="application/xml" element="t:object"/>
<representation mediaType="application/xml"/>
</request>
<response status="202"/>
</method>

In this case there is not content body; but if you don't add a @Produces annotation that the response content type will default to / which is misleading in this case.

Comment by Michal Gajdos [ 10/Jul/12 01:59 PM ]

You can try to create a custom WadlGeneratorConfig with WadlGeneratorResourceDocSupport defined (see extended-wadl-webapp for an example). Then you can add a javadoc to your method like:

/**
  * @response.representation.202.id
  */

to generate a response element with empty representation subelement in the WADL:

<response status="202">
   <representation/>
</response>
Comment by Michal Gajdos [ 12/Jul/12 02:33 PM ]

There is an inconsistency with the spec (section 3.8) - when a resource method is annotated with @Produces({}) then the producible media type of a response is not determined correctly ("/") and the HTTP 406 is returned which is wrong.

Comment by Michal Gajdos [ 16/Jul/12 02:08 PM ]

Fixed for 1.14.





[JERSEY-1057] SAXParserContextProvider fail inconsistenly for missing XML parser features Created: 30/Mar/12  Updated: 07/Oct/13  Resolved: 07/Oct/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.13

Type: Bug Priority: Major
Reporter: gdavison Assignee: Michal Gajdos
Resolution: Fixed Votes: 0
Remaining Estimate: 0 minutes
Time Spent: 3 hours
Original Estimate: Not Specified
Environment:

Using the Oracle XDK


Tags: 1_13-blocker
Participants: gdavison, Martin Matula and Michal Gajdos

 Description   

The oracle xml parser has a different set of features that most normal parsers, this is a problem because it causes the client to fail to start:

if (!disableXmlSecurity) {
try { f.setFeature("http://xml.org/sax/features/external-general-entities", Boolean.FALSE); } catch (Exception ex) { throw new RuntimeException("Security features for the SAX parser could not be enabled", ex); }

try { f.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, Boolean.TRUE); } catch (Exception ex) { LOGGER.log(Level.WARNING, "JAXP feature XMLConstants.FEATURE_SECURE_PROCESSING cannot be set on a SAXParserFactory. " + "External general entity processing is disabled but other potential security related" + " features will not be enabled.", ex); }
}

Interesting the FEATURE_SECURE_PROCESSING is simple handled with a WARNING log message; but the former fails with a RunTimeException even. Would it be possible to make the former case log a SEVERE or WARNING message?

There are workaround for this; but it would be nice of Jersey would work out of the box with the Oracle XML parser.



 Comments   
Comment by Martin Matula [ 30/Mar/12 02:14 PM ]

We should fix this for 1.13. Michal, can you please look into this?

Comment by Michal Gajdos [ 11/Jun/12 07:50 AM ]

XDK does not support security features set by Jersey (http://xml.org/sax/features/external-general-entities and http://javax.xml.XMLConstants/feature/secure-processing) so when Oracle's XML parser is used in Jersey no security features are used for processing.





[JERSEY-1007] QueryParam and HeaderParam are inhereted which in inconsistent with the WADL specification Created: 09/Mar/12  Updated: 04/Nov/13

Status: Open
Project: jersey
Component/s: tools
Affects Version/s: 1.9
Fix Version/s: backlog

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 3 hours
Time Spent: 0 minutes
Original Estimate: 3 hours

Tags:
Participants: gdavison, Marek Potociar and Martin Matula

 Description   

So I have a very simple nested resource which looks like this:

@Path("/root")
public class RootResource {
    
    @Path("/sub")
    public SubResource get(@QueryParam("rootQ") String rootQ, @HeaderParam("rootH") String rootH) {
        return new SubResource (rootQ, rootH);
    }
}

and

public class SubResource {
    
    String rootQ, rootH;
    
    public SubResource(String rootQ, String rootH) {
        this.rootQ = rootQ;
        this.rootH = rootH;
    }
    
    
    @GET
    public String get(@QueryParam("subQ") String subQ, @HeaderParam("subH") String subH) {
        StringBuilder sb = new StringBuilder();
        new Formatter(sb).format(
         "rootQ %s, rootH %s\n" +
         "subQ %s, subH %s", rootQ, rootH, subQ, subH);
        return sb.toString();
    }
}

Now to be consistent with the WADL spec (See WADL-32) we wouldn't expect the query and header parameters to be inherited by the sub resource. Indeed the WADL generated would seem to agree with this:

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<application xmlns="http://research.sun.com/wadl/2006/10">
   <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8-SNAPSHOT 06/01/2011 07:09 PM"/>
   <resources base="http://localhost:7101/Nested/jersey/">
      <resource path="root">
         <resource path="/sub">
            <method id="get" name="GET">
               <request>
                  <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subQ" style="query" type="xs:string"/>
                  <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subH" style="header" type="xs:string"/>
               </request>
               <response>
                  <representation mediaType="*/*"/>
               </response>
            </method>
         </resource>
      </resource>
   </resources>
</application>

But when you send a suitably crafted message to the resource (http://localhost:7101/Nested/jersey/root/sub?subQ=sub&rootQ=root and with the HTTP headers) the response is as follows:

rootQ root, rootH rootH
subQ sub, subH subH

The root values should be null in all cases if we are going to be consistent with the WADL specification.



 Comments   
Comment by Martin Matula [ 09/Mar/12 10:48 AM ]

Marek, what does the JAX-RS spec say for this case (if anything)?

Comment by Marek Potociar [ 09/Mar/12 11:47 AM ]

My interpretation of the JAX-RS spec (section 3.2 + related javadoc) is that injection of header & query parameters are request scoped. Since root resource and sub-resource classes participate in satisfying the same request, the behavior of Jeresy in this case seems correct to me.

I guess this is an issue of the WADL specification or it's interpretation in context of JAX-RS resource classes, where the 1-1 mapping is not applicable in general. E.g. in the example above I would even argue that from REST (and WADL) point of view there is only one resource exposed - the one located at "/root/sub" URI. Trying to access just "/root" yields 404, since there are no resource methods on the root resource class. All the request-scoped parameters, including query and header ones, are thus targeted for the single exposed resource.

As for the WADL spec resource element definition , seems to me that there is no conflict. Indeed the WADL spec can construct resource trees that are not implementable via a combination of JAX-RS root resource - sub-resource classes, but that's all. The proper WADL generated for the JAX-RS resource construct above would be e.g.:

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<application xmlns="http://research.sun.com/wadl/2006/10">
    <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8-SNAPSHOT 06/01/2011 07:09 PM"/>
    <resources base="http://localhost:7101/Nested/jersey/">
        <resource path="root/sub">
            <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rootQ" style="query" type="xs:string"/>
            <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rootH" style="header" type="xs:string"/>
            <method id="get" name="GET">
                <request>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subQ" style="query" type="xs:string"/>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subH" style="header" type="xs:string"/>
                </request>
                <response>
                    <representation mediaType="/"/>
                </response>
            </method>
        </resource>
    </resources>
</application>

or

<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
<application xmlns="http://research.sun.com/wadl/2006/10">
    <doc xmlns:jersey="http://jersey.java.net/" jersey:generatedBy="Jersey: 1.8-SNAPSHOT 06/01/2011 07:09 PM"/>
    <resources base="http://localhost:7101/Nested/jersey/">
        <resource path="root/sub">
            <method id="get" name="GET">
                <request>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rootQ" style="query" type="xs:string"/>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="rootH" style="header" type="xs:string"/>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subQ" style="query" type="xs:string"/>
                    <param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="subH" style="header" type="xs:string"/>
                </request>
                <response>
                    <representation mediaType="/"/>
                </response>
            </method>
        </resource>
    </resources>
</application>

And vice-versa: In order to satisfy the WADL above, the JAX-RS resource structure would have to look e.g like this:

@Path("/root")
public class RootResource {
    @Path("/sub")
    public SubResource get() { 
        return new SubResource (); 
    }
}

public class SubResource {
    @GET
    public String get(@QueryParam("subQ") String subQ, @HeaderParam("subH") String subH) { 
        StringBuilder sb = new StringBuilder();
        new Formatter(sb).format("subQ %s, subH %s", subQ, subH);
        return sb.toString();
    }
}

Or simply:

@Path("/root/sub")
public class RootResource {
    @GET
    public String get(@QueryParam("subQ") String subQ, @HeaderParam("subH") String subH) { 
        StringBuilder sb = new StringBuilder();
        new Formatter(sb).format("subQ %s, subH %s", subQ, subH);
        return sb.toString();
    }
}

In summary, I believe the issue is in how the WADL is currently generated from the JAX-RS resource classes (resource class != resource).

Comment by Marek Potociar [ 09/Mar/12 11:51 AM ]

Seems that the real issue is in the way WADL is generated from the JAX-RS resources (see other comments). Reassigning the issue.





[JERSEY-796] OPTIONS doesn't work for sub resources on extended-wadl-webapp Created: 21/Oct/11  Updated: 24/Oct/11  Resolved: 24/Oct/11

Status: Resolved
Project: jersey
Component/s: examples
Affects Version/s: 1.8
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac server, 10.7, and Linux client using curl


Tags:
Participants: gdavison and Pavel Bucek

 Description   

I ran and deployed the service and could access the application.wadl; but I saw the following error when I tried to access the WADL for a particular resources:

curl -X OPTIONS http://localhost:8080/extended-wadl-webapp/issues

<Unable to render embedded object: File (//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>GlassFish Server Open Source Edition 3.1 - Error report</title><style type="text/css"><) not found.--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><hr/><p><b>type</b> Exception report</p><p><b>message</b></p><p><b>description</b>The server encountered an internal error () that prevented it from fulfilling this request.</p><p><b>exception</b> <pre>javax.ws.rs.WebApplicationException: javax.xml.bind.MarshalException

  • with linked exception:
    [javax.xml.bind.JAXBException: com.sun.jersey.server.wadl.generators.resourcedoc.xhtml.XhtmlElementType is not known to this context]</pre></p><p><b>note</b> <u>The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 3.1 logs.</u></p><hr/><h3>GlassFish Server Open Source Edition 3.1</h3></body></html>

The reason why this is important is that I am testing out a writing a GUI testing tool that needs to try to use options to look up the datatypes for a particular resource. If there is an obvious workaround then I would be very interested, also doesn't work in 1.9_SNAPSHOT I had lying about.



 Comments   
Comment by Pavel Bucek [ 21/Oct/11 01:20 PM ]

yeah, makes sense. I was actually little curious when I discovered that GET and OPTIONS requests for WADL are handled differently (they don't share same marshaller/jaxbContext) and was expecting similar issue to appear somewhere.

easiest "workaround" would be using just GET contextRoot/application.wadl for now, which shouldn't produce this exception.

Comment by Pavel Bucek [ 24/Oct/11 06:26 PM ]

fixed in the trunk





[JERSEY-794] resources base="..' in wsdl reflects that URI of the first request Created: 20/Oct/11  Updated: 10/Feb/12  Resolved: 21/Oct/11

Status: Closed
Project: jersey
Component/s: core
Affects Version/s: 1.9.1
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JERSEY-774 WADL caching may break WADL's /applic... Resolved
Tags:
Participants: gdavison and Pavel Bucek

 Description   

If you have a machine that can be accessed from multiple URL, the first request is then used from then on as the base of the root application.wadl as the value is cached.

For example:

GET http://localhost:7101/jersey/application.wadl
then
GET http://jdevws-gdavison:7101/jersey/application.wadl

The WADL will have a base that uses the localhost name from the first request onwards, it should some how reflect the current URI.



 Comments   
Comment by Pavel Bucek [ 21/Oct/11 07:41 AM ]

fixed in the trunk





[JERSEY-791] 10b3 jersey-archive is missing at least jersey-server...jar Created: 19/Oct/11  Updated: 25/Oct/11  Resolved: 25/Oct/11

Status: Resolved
Project: jersey
Component/s: None
Affects Version/s: 1.10
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Pavel Bucek

 Description   

I down loaded the latest jersey-archive and it appears to be missing jersey-server.jar and possibly a few other jars and when I downloaded this separately it stopped working.



 Comments   
Comment by Pavel Bucek [ 25/Oct/11 10:00 AM ]

fixed in the trunk





[JERSEY-680] Proxy based client generation Created: 16/Mar/11  Updated: 26/Feb/13  Resolved: 22/Feb/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 2.0-m13, 2.0

Type: Improvement Priority: Major
Reporter: gdavison Assignee: Marek Potociar
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: alwillha, gdavison, Marek Potociar and Pavel Bucek

 Description   

It is desirable to take a WADL or other IDL and be able to generate a skeleton client based on
java interfaces in the same way that JAX-WS works.

When we investigated this a while back we in JDeveloper team put together a proxing client
that could provide some input to this work.

http://kingsfleet.blogspot.com/2009/09/javalangreflectproxy-client-based-on.html
and
http://kingsfleet.blogspot.com/2009/10/proxy-client-based-on-jersey-with-bit.html

It should be possible to integration this with later work on link generation that Mark Hadley
had worked on.



 Comments   
Comment by alwillha [ 21/Mar/12 10:10 AM ]

See JAXRSClientFactory in CXF http://cxf.apache.org/docs/jax-rs-client-api.html

Comment by Pavel Bucek [ 21/Mar/12 10:17 AM ]

thanks for pointer.

very unfortunate naming though, this has nothing to do with JAX-RS Client API, see http://jcp.org/en/jsr/detail?id=339

Comment by Marek Potociar [ 22/Feb/13 08:55 PM ]

See the ext/proxy-client module in Jersey 2.x





[JERSEY-679] WADL generation should general XML Schema by default Created: 16/Mar/11  Updated: 10/Feb/12  Resolved: 08/Sep/11

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: None
Fix Version/s: 1.9

Type: Improvement Priority: Major
Reporter: gdavison Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Pavel Bucek

 Description   

One of the first steps in generating a reasonable client from a WADL would be to enable
XML Schema generation from JAXB types by default. This would make it much easier
to generate a client that can more directly consume the service without having to
take into account of our band information.



 Comments   
Comment by Pavel Bucek [ 08/Sep/11 11:58 AM ]

fixed in 1.9





[JERSEY-678] Design Time Validation of Jersey Annotation Created: 16/Mar/11  Updated: 04/Nov/13

Status: Open
Project: jersey
Component/s: None
Affects Version/s: 1.5
Fix Version/s: icebox

Type: New Feature Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: PNG File intellij-idea-jersey-validation.png    
Tags: jdeveloper
Participants: gdavison and Jakub Podlesak

 Description   

We want to have the ability to validate Jersey annotations at design time rather than waiting
for the application to be deployed.

Simple validation along the lines of GET with a body defined would be a good start but we
can also match up @PathParam with entries in the @Path annotation for example.

These needs to be done in a form that can be used in the code editors, IDE tools and
from the command line when using Ant Maven etc.

We are suggest something along the lines of this as a start:

http://kingsfleet.blogspot.com/2009/09/validating-annotations-at-compile-time.html

As we could easily integrate this into the JDevloper, Netbeans, and Eclipse tooling.



 Comments   
Comment by Jakub Podlesak [ 17/Mar/11 07:26 AM ]

IntelliJ IDEA already uses the BasicValidator utility in Jersey
in order to do resource validation. See attached snapshot on how it
looks for the end-user.

To get the issue list corresponding to a given resource class,
you will just:

AbstractResource ar = IntrospectionModeller.createResource(MyResource.class);
BasicValidator validator = new BasicValidator();
validator.validate(ar);
processIssueList(validator.getIssueList());

Is there any chance you can re-use this in JDeveloper?





[JERSEY-638] Extend WADL to support JSON response representation Created: 29/Jan/11  Updated: 20/Feb/13  Resolved: 20/Feb/13

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.5
Fix Version/s: 1.17

Type: New Feature Priority: Major
Reporter: Martin Matula Assignee: Jakub Podlesak
Resolution: Fixed Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File JERSEY-638.patch    
Tags:
Participants: anilgmaipady, berngp, gdavison, Jakub Podlesak and Martin Matula

 Description   

http://java.net/projects/jersey/lists/users/archive/2010-12/message/189

The extended WADL of Jersey has a nice feature for XML documentation, where you can say:
@response.representation.200.example {@link Examples#MY_SAMPLE_OBJECT}

The WADL generator will actually marshal the MY_SAMPLE_OBJECT to XML for the documentation. That way the documentation reflects the REAL way that object would be represented. Awesome!

Unfortunately, all of my services produce JSON. In JSON, the example is even more important because there is no equivalent of a schema for JSON. Is there anything similar available for JSON? Has anyone written anything custom that I could look at as an example?



 Comments   
Comment by anilgmaipady [ 05/Mar/11 08:30 AM ]

This patch will fix this bug. Example:

  • @response.representation.200.mediaType application/json
  • @response.representation.200.example {@link Examples#SAMPLE_ITEM}

    Will generate JSON of Examples#SAMPLE_ITEM

    * @response.representation.200.mediaType application/xml
    * @response.representation.200.example {@link Examples#SAMPLE_ITEM}

Will generate XML of Examples#SAMPLE_ITEM

Comment by berngp [ 16/Apr/12 09:43 PM ]

Are there any updates to support a WADL serialized to JSON?

Looking forward for this!
Cheers
Bernardo.

Comment by gdavison [ 20/Feb/13 02:54 PM ]

You can now request a JSON version of the WADL with the mime type "application/vnd.sun.wadl+json", if you want JSON-Schema to be generated you need to look at the jersey-wadl-json-schema contrib module which will generate them for you. (See http://kingsfleet.blogspot.co.uk/2012/11/json-schema-generation-in-jersey.html)





[JDEVELOPERAOP-1] Cannot re-open usecase diagrams with aspectj installed Created: 10/Aug/04  Updated: 12/Aug/04  Resolved: 12/Aug/04

Status: Resolved
Project: jdeveloperaop
Component/s: www
Affects Version/s: current
Fix Version/s: milestone 1

Type: Bug Priority: Critical
Reporter: gdavison Assignee: gdavison
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.oracle.com/forums/thread.jsp?forum=83&thread=258846&tstart=45


Issuezilla Id: 1
Tags:
Participants: gdavison

 Description   

If you install the aspectj addin you will find that you cannot re-open UML
diagrams. I think I need to defer initilialization of the ADJT until after the
IDE has finished loaded. This prevents the project request too early in the cycle.

Something like this would be a good idea:

// Make sure we only populate the model menu when all the addins have
// been loaded, this makes sure that all the addins are configred properly
//
Ide.addIdeListener(new IdeListener()
{
public void addinsLoaded(IdeEvent e)

{ initializeWhenIdeLoaded(); }

public void mainWindowOpened(IdeEvent e)
{ ; }

public void mainWindowClosing(IdeEvent e)
{ ; } }
});



 Comments   
Comment by gdavison [ 10/Aug/04 05:56 AM ]

Update priority

Comment by gdavison [ 12/Aug/04 12:31 AM ]

Fixed in 0.55B





[JAX_WS-1027] Patch required to properly integrate the WSImportTool into an IDE environment Created: 22/Nov/11  Updated: 05/Dec/11  Resolved: 05/Dec/11

Status: Closed
Project: jax-ws
Component/s: None
Affects Version/s: 2.2.6
Fix Version/s: 2.2.6

Type: Bug Priority: Major
Reporter: gdavison Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdeveloper


Tags: jdeveloper
Participants: gdavison and Iaroslav Savytskyi

 Description   

We are invoking the JAX-WS tools in an IDE, specifically JDeveloper, as we need a way to ensure that the files generates are written to a virtual file system in order that we can merge them with the developers existing work.

The WebServiceAp correctly uses a FilerCodeWriter but WSImportTool makes use of the WSCodeWriter which only writes to the file system. This patch modified the code very so slightly so that we can pass in a filer.

Index: tools/wscompile/src/com/sun/tools/ws/wscompile/WsgenOptions.java
===================================================================
— tools/wscompile/src/com/sun/tools/ws/wscompile/WsgenOptions.java (revision 12762)
+++ tools/wscompile/src/com/sun/tools/ws/wscompile/WsgenOptions.java (working copy)
@@ -40,7 +40,6 @@

package com.sun.tools.ws.wscompile;

-import javax.annotation.processing.Filer;
import com.sun.tools.ws.resources.WscompileMessages;
import com.sun.tools.ws.api.WsgenExtension;
import com.sun.tools.ws.api.WsgenProtocol;
@@ -101,9 +100,6 @@
*/
public boolean doNotOverWrite;

  • public Filer filer;
    -
    -
    /**
  • Tells if user specified a specific protocol
    */
    Index: tools/wscompile/src/com/sun/tools/ws/wscompile/WsimportTool.java
    ===================================================================
      • tools/wscompile/src/com/sun/tools/ws/wscompile/WsimportTool.java (revision 12762)
        +++ tools/wscompile/src/com/sun/tools/ws/wscompile/WsimportTool.java (working copy)
        @@ -418,7 +418,14 @@
        implFiles = JwsImplGenerator.generate(wsdlModel, options, receiver);
        }
  • CodeWriter cw = new WSCodeWriter(options.sourceDir, options);
    + CodeWriter cw;
    + if (options.filer!=null) { + cw = new FilerCodeWriter(options.sourceDir,options); + }
    + else { + cw = new WSCodeWriter(options.sourceDir, options); + }
    +
    if (options.verbose)
    cw = new ProgressCodeWriter(cw, out);
    options.getCodeModel().build(cw);
    Index: tools/wscompile/src/com/sun/tools/ws/wscompile/FilerCodeWriter.java
    ===================================================================
      • tools/wscompile/src/com/sun/tools/ws/wscompile/FilerCodeWriter.java (revision 12762)
        +++ tools/wscompile/src/com/sun/tools/ws/wscompile/FilerCodeWriter.java (working copy)
        @@ -59,7 +59,7 @@

private Writer w;

  • public FilerCodeWriter(File outDir, WsgenOptions options) throws IOException {
    + public FilerCodeWriter(File outDir, Options options) throws IOException { super(outDir, options); this.filer = options.filer; }
    Index: tools/wscompile/src/com/sun/tools/ws/wscompile/Options.java
    ===================================================================
      • tools/wscompile/src/com/sun/tools/ws/wscompile/Options.java (revision 12762)
        +++ tools/wscompile/src/com/sun/tools/ws/wscompile/Options.java (working copy)
        @@ -43,6 +43,8 @@
        import com.sun.tools.ws.resources.WscompileMessages;
        import com.sun.tools.ws.Invoker;

+import javax.annotation.processing.Filer;
+
import java.io.File;
import java.io.IOException;
import java.net.MalformedURLException;
@@ -88,7 +90,16 @@
*/
public File sourceDir;

+
+
/**
+ * The filer that can use used to write out the generated files
+ */
+ public Filer filer;
+
+
+
+ /**

  • -encoding
    */
    public String encoding;





[JAX_WS-1026] wgen no longer fails when generating wsdl if parameter is not seriazable as a XML element Created: 18/Nov/11  Updated: 30/Nov/11

Status: Open
Project: jax-ws
Component/s: wsgen
Affects Version/s: 2.2.6
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: Martin Grebac
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, JDeveloper/Command line


File Attachments: Zip Archive OpaqueTypes.zip    
Tags: jdeveloper metro2_2-waived
Participants: gdavison and Martin Grebac

 Description   

So we have a test class that looks as follows:

package service;

import javax.jws.Oneway;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

import javax.xml.ws.Holder;

@WebService
public class ServiceImpl {
public ServiceImpl() { super(); }

@WebMethod
public String echoString(@WebParam(name = "arg0")
String echo) { return echo; }

@WebMethod
public int add(@WebParam(name = "arg0")
int x, @WebParam(name = "arg1")
int y) { return x + y; }

@WebMethod
public Integer sub(@WebParam(name = "arg0")
Integer x, @WebParam(name = "arg1")
Integer y) { return new Integer(x.intValue() + y.intValue()); }

@WebMethod
public Person echoPerson(@WebParam(name = "arg0")
Person echo) { return echo; } }

@WebMethod
public Opaque echoOpaque(@WebParam(name = "arg0")
Opaque echo) { return echo; }

@WebMethod
@Oneway
public void setUnserializable(@WebParam(name = "arg0")
Unserializable echo) {
}

@WebMethod
public void mul(@WebParam(name = "arg0", mode = WebParam.Mode.INOUT)
Holder<Integer> x, @WebParam(name = "arg1")
int y) { x.value = x.value.intValue() * y; }

}

In particular the Opaque class looks like this:

package service;

import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

public class Opaque {

private int[] _internalData;

public Opaque(int[] internalData) { _internalData = internalData; }

/package/ Iterator internalData() { List l = Arrays.asList(_internalData); return l.iterator(); }
}

When generated with older versions of JAX-WS wsgen you would see a failure on this class are it doesn't present the required no-arg constructor making it impossible to desrialize it on the sever without intevention.

[gdavison@gbr10153 src]$ /ade/gdavison_lt/oracle/jdk/bin/wsgen -Xendorsed -cp ../classes service.ServiceImpl -wsdl
Exception in thread "main" javax.xml.ws.WebServiceException: Unable to create JAXBContext
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:153)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.postProcess(AbstractSEIModelImpl.java:83)
at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(RuntimeModeler.java:244)
at com.sun.tools.internal.ws.wscompile.WsgenTool.buildModel(WsgenTool.java:229)
at com.sun.tools.internal.ws.wscompile.WsgenTool.run(WsgenTool.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.tools.internal.ws.Invoker.invoke(Invoker.java:105)
at com.sun.tools.internal.ws.WsGen.main(WsGen.java:41)
Caused by: java.security.PrivilegedActionException: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
service.Opaque does not have a no-arg default constructor.
this problem is related to the following location:
at service.Opaque
at private service.Opaque service.jaxws.EchoOpaque.arg0
at service.jaxws.EchoOpaque
service.Unserializable does not have a no-arg default constructor.
this problem is related to the following location:
at service.Unserializable
at private service.Unserializable service.jaxws.SetUnserializable.arg0
at service.jaxws.SetUnserializable

at java.security.AccessController.doPrivileged(Native Method)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl.createJAXBContext(AbstractSEIModelImpl.java:140)
... 10 more
Caused by: com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2 counts of IllegalAnnotationExceptions
service.Opaque does not have a no-arg default constructor.
this problem is related to the following location:
at service.Opaque
at private service.Opaque service.jaxws.EchoOpaque.arg0
at service.jaxws.EchoOpaque
service.Unserializable does not have a no-arg default constructor.
this problem is related to the following location:
at service.Unserializable
at private service.Unserializable service.jaxws.SetUnserializable.arg0
at service.jaxws.SetUnserializable

at com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:436)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277)
at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1100)
at com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:143)
at com.sun.xml.internal.bind.api.JAXBRIContext.newInstance(JAXBRIContext.java:95)
at com.sun.xml.internal.ws.developer.JAXBContextFactory$1.createJAXBContext(JAXBContextFactory.java:97)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:148)
at com.sun.xml.internal.ws.model.AbstractSEIModelImpl$1.run(AbstractSEIModelImpl.java:140)
... 12 more

Now when I try the same action with a recent build of JAX-WS 2.2.6 branch I find that the WSDL generates without errors which appears to be incorrect and represents a regression as we use this failure to display to the user which methods are invalid.



 Comments   
Comment by gdavison [ 18/Nov/11 01:56 PM ]

Attached project is in JDeveloper format; but you can run the wsgen commands on the Project1/src and clasess directories.





[JAX_WS-1022] JSR 269 version of WebServiceAp contains potential null pointer exception Created: 14/Nov/11  Updated: 22/Nov/11  Resolved: 22/Nov/11

Status: Resolved
Project: jax-ws
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gdavison Assignee: Iaroslav Savytskyi
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Iaroslav Savytskyi

 Description   

If you look at line 151 in WebServiceAp on the 22 branch you will notice it tries to get hold of a system property without first checking to see if it is set:

http://java.net/projects/jax-ws/sources/sources/content/branches/jaxws22/jaxws-ri/tools/wscompile/src/com/sun/tools/ws/processor/modeler/annotation/WebServiceAp.java?rev=12761

options.verbose = System.getProperty("sun.java.command").contains("-verbose");

I was workaround this when invoke the Ap from inside of an IDE; but this code should be more careful about assuming the environment it is running in.






[JAX_WS-1012] WsimportTool override the Authenticator singleton Created: 22/Sep/11  Updated: 06/Mar/13  Resolved: 03/Jan/12

Status: Resolved
Project: jax-ws
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2.7

Type: Bug Priority: Major
Reporter: gdavison Assignee: Lukas Jungmann
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDeveloper


Tags:
Participants: gdavison and Lukas Jungmann

 Description   

When using WsimportTool within the same VM as JDeveloper we find that the Authenticator is replaced by the the "DefaultAuthenticator" even if no authentication options are provided.

This unfortunately either causes the generation to fail in the case of a strict SecurityManager or causes other unrelated functionality to fail in the case where the value is replaced.

You can obvious replace the authenticator after the generation is run; but this is obviously not optimal or thread safe. (And required evil reflection to get hold of the current Authenticator)

This should be some way to prevent the tool from messing with this value.



 Comments   
Comment by Lukas Jungmann [ 26/Sep/11 01:59 PM ]

this should have been already fixed within JAX_WS-1007 for 2.2.6, fix itself is @ http://java.net/projects/jax-ws/lists/cvs/archive/2011-09/message/9

Comment by gdavison [ 26/Sep/11 02:08 PM ]

This doesn't solve the problem which is that the Authenticator should get replaced. The IDE environment is providing it's own authenticator and should be left in place.

Comment by Lukas Jungmann [ 27/Sep/11 08:51 PM ]

I see, your use-case is a bit different hence reopening

Comment by Lukas Jungmann [ 03/Jan/12 03:24 PM ]

You can now use '-XdisableAuthenticator" to disable default behaviour.

http://java.net/projects/jax-ws/sources/sources/revision/12875





[JAX_RS_SPEC-360] It would be useful to have a standard annotation to indicate fault codes Created: 19/Feb/13  Updated: 12/Feb/14

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Bug Priority: Minor
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

At the moment here is no standard way using annotation to indicate what status code a method / or exception will produce, this makes it harder to generate complete WADL descriptions of the service.

For example:

@Status(200, 404)
@GET
@Path("{path}")
public String get(....) {}

Or even the more complicated:

@Status(404)
public NotFoundException extends WebApplicaitonException {...}

@GET
@Path("{path}")
public String get(....) throws NotFoundException {}

A generator tool could then output the correct WADL description along with the types in this case.



 Comments   
Comment by Marek Potociar [ 20/Feb/13 12:46 AM ]

Deferring to future consideration.





[JAX_RS_SPEC-359] It would be useful to have a UriTemplateParser as part of the spec Created: 19/Feb/13  Updated: 18/Jun/13

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Bug Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

UriTemplateParser is useful when generating client boilerplate as it allows a client to extra parameters from a URI that the user of the API has provided.

At the moment I have to rely on an internal implementation that is part of Jersey making the JAX-RS 2.0 client not cross platform.



 Comments   
Comment by gdavison [ 19/Feb/13 01:11 PM ]

I wonder if this could be as simple as adding a method to UriBuilder:

public boolean match(URI uri, Map<String,String> parameters);

This would greatly reduce the API impact of this request.

Comment by Marek Potociar [ 20/Feb/13 12:53 AM ]

Not sure what the method above is supposed to do. Can you please elaborate?

Comment by gdavison [ 20/Feb/13 09:58 AM ]

Sure, sorry the original bug was poorly written.

So the problem I am trying to deal with when generating a JAX-RS 2.0 client is that the user would like the client to be able to take in a URI:

http://example.com/name/Bob/age/41

And to understand and extract the parameters so they can be reset, so assuming the template looks like this:

http://example.com/name/{name}/age/{age}

So ideally the code would look like this:

String template = "http://example.com/name/{name}/age/{age}";
UriBuilder builder = UriBuilder.fromPath(template);
Map<String,String> parameters = new HashMap<>();
builder.match(uri, parameters);

Then you can change a parameter:

parameters.put("name", "Arnold");
builder.build(parameters);

Which would give the URI:

http://example.com/name/Arnold/age/41

The match method returns a boolean so it would return false if the URI didn't match what was being provided. I hope this is a lot clearer as to my intent.

Comment by Marek Potociar [ 20/Feb/13 02:39 PM ]

Ok, so what you are looking for is perhaps a method like:

Map<String, String> params = builder.parametersOf(uri);

Correct? Or do you prefer your version where you have to create the Map instance? (If yes, then why?)

FWIW, I'm releasing PFD today, but let me bring this up to EG - maybe we can add this before final release if EG agrees.

Comment by gdavison [ 20/Feb/13 03:10 PM ]

I think the reason behind having to pass the parameters in is that it allow the method to still return a boolean parameter which tells you if the URI matches at all. I guess the method could throw an exception in this case instead - don't have a suggestion of a suitable one though.

Also the conservative part of me always like to be able to pass in a Map just in case I want to be able to reuse an instance of an object. (I spend many a happy hour dealing with the fact that early versions of AWT would always create a Rectangle to get hold of size rather than allows you to pass one in as that did for Graphics2D)

It would be useful to have this as the JAX-RS 2.0 client generated for the moment is depending on the jersey UriTemplate class and I would like to have it removed of course.

Comment by Marek Potociar [ 20/Feb/13 04:52 PM ]

Thinking more about it, I'd really like to have a solution that does not mixes up a builder components with URI template matching ones...

So the proposed solution may look like:

  • introduce UriTemplate to represent, well, URI templates...
  • add ability to build UriTemplate instances from UriBuilder
  • expose the boolean UriTemplate.match(URI, Map<String, String>) method as part of the UriTemplate API.
Comment by Marek Potociar [ 06/Mar/13 02:07 PM ]

The proposal was discussed in EG and EG decided that it's too late to include this in 2.0 release unfortunately. We need to defer the issue for now.





[JAX_RS_SPEC-312] WebApplicationException doesn't default a message Created: 15/Nov/12  Updated: 18/Jun/13  Resolved: 09/Jan/13

Status: Resolved
Project: jax-rs-spec
Component/s: client
Affects Version/s: 1.1
Fix Version/s: 2.0

Type: Bug Priority: Minor
Reporter: gdavison Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

When a WebApplicationException is thrown it doesn't show a message at all, just any caused exception. This is really poor when trying to diagnose an issue in some cases:

Exception in thread "main" javax.ws.rs.WebApplicationException
at client2.Localhost_Basic_Auth_RESTProject1ContextRootResources$Project1.getAsXml(Localhost_Basic_Auth_RESTProject1ContextRootResources.java:124)
at client2.Localhost_Basic_Auth_RESTProject1ContextRootResourcesClient.main(Localhost_Basic_Auth_RESTProject1ContextRootResourcesClient.java:25)
P

It should at minimum display the Status code and message if this is available on the response. I would suggest replacing the contructor:

/**

  • Construct a new instance using the supplied response
  • @param response the response that will be returned to the client, a value
  • of null will be replaced with an internal server error response (status
  • code 500)
  • @param cause the underlying cause of the exception
    */
    public WebApplicationException(Throwable cause, Response response) { super(cause); if (response==null) this.response = Response.serverError().build(); else this.response = response; }

with at least this:

/**

  • Construct a new instance using the supplied response
  • @param response the response that will be returned to the client, a value
  • of null will be replaced with an internal server error response (status
  • code 500)
  • @param cause the underlying cause of the exception
    */
    public WebApplicationException(Throwable cause, Response response) { super(response!=null && cause==null ? Response.Status.fromStatusCode(response.getStatus()) : null, cause); if (response==null) this.response = Response.serverError().build(); else this.response = response; }

Ideally Response would be modified to make the StatusType object accessible so it is possible to get hold of this object directly. Also you might need a null check on the return of fromStatusCode.



 Comments   
Comment by Marek Potociar [ 09/Jan/13 04:35 PM ]

Fixed on the main trunk. A WAE with no custom error message will get the message generated from the response error status code and status phrase.





[JAX_RS_SPEC-231] Cannot extract template from UriBuilder Created: 16/Jul/12  Updated: 18/Jun/13  Resolved: 01/Aug/12

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Bug Priority: Major
Reporter: gdavison Assignee: Marek Potociar
Resolution: Fixed Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

If you construct a template using UriBuilder:

UriBuilder example = UriBuilder.fromUri("http://www.example.com/").path("{example}");

There is no way to extract the full template from the UriBuilder instance, if you call build then the {} are escaped.

So it would be nice to have a method as follows:

String example.toTemplate();

Or similar.



 Comments   
Comment by Marek Potociar [ 01/Aug/12 11:32 AM ]

Method introduced. See: http://java.net/projects/jax-rs-spec/sources/git/revision/9b26879091e85c33f33be76911ed036930531609





[JAX_RS_SPEC-226] Add support for jax-rs-catalog for client injection Created: 05/Jul/12  Updated: 18/Jun/13

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: New Feature Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

The new client injection specification is a big step forward in JAX_RS_SPEC-170; but to support real world system you need a method of being able to control service URI at deploy time so that it is easy to test services and to deploy to different environments.

The wadl.java.net project makes use of a catalog file for this, similar to what is implemented for the JAX-WS RI and is detailed here:

http://kingsfleet.blogspot.co.uk/2012/03/catalog-support-for-wadl-client.html



 Comments   
Comment by Marek Potociar [ 05/Sep/12 01:47 PM ]

Moving to ice-box for post-2.0 evaluation.





[JAX_RS_SPEC-121] Formalize the List<?> and Map<?> XML and JSON mappings Created: 10/Aug/11  Updated: 18/Jun/13

Status: Open
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: ice box

Type: Improvement Priority: Major
Reporter: gdavison Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gdavison and Marek Potociar

 Description   

Currently there is support for generically mapping List<?> types to XML document, and with less complication JSON documents. The contents are wrapped up in a XML element with no namespace with a local name that in some english cases are plural versions of the generic parameters localname.

This does present some problems, not least that the lack of namespaces means that any client side JAX-B classes will by default end up without a package.

The suggestion is to solve this problem in two way, first of all change the defaults for namespaces to follow the following rules:

1. Look at the method returning the collection object and see if there is a @CollectionType annotation

If so use the namespace and local name defined in this annotation. If no local name rule is defined use an agreed pluralization table to ensure inter-op between different implementations.

2. If no namespace look for a package-info definition for the package containing the resource and use any XML namespace defined here

3. If no package-info found then default using the standard JAX-B rule for converting packages to namspaces.

This results in sensible defaults and allow the user to override the settings with the @CollectionType annotation that would be as simple as:

public @interface CollectionType

{ String namespace(); String name(); }

 Comments   
Comment by gdavison [ 10/Aug/11 09:30 AM ]

For JSON types of course only the name would be significant.

Comment by gdavison [ 10/Aug/11 09:35 AM ]

If there is going to have to be generic mapping Map<Key,Value> then I guess it would be of the form:

<collectionName>
<entry>
<key>...</key>
<value>...</value>
</entry>
</collectionName>

We could go further and provide extra annotation properties to control the name and the namespace of the entry element in the same annotation. So:

public @interface CollectionType

{ String namespace(); String name(); String entryName(); }
Comment by Marek Potociar [ 05/Jun/12 03:07 PM ]

Deferred for a future revision. It should be probably moved to a JSON binding or JAXB3 spec once the JSRs are formed.





[JAX_RS_SPEC-119] Provide tidier API for GenericType and GenericEntity Created: 19/Jul/11  Updated: 18/Jun/13  Resolved: 08/Feb/13

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Improvement Priority: Minor
Reporter: gdavison Assignee: Marek Potociar
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAX_RS_SPEC-313 Improve usability of GenericType Open
Related
is related to JAX_RS_SPEC-156 Cannot pass in type information to In... Resolved
Tags:
Participants: gdavison and Marek Potociar

 Description   

Both of these classes use Grafter's gadget to avoid type erasure, it would be nice if we could provide tider methods of creation without having to create an anonymous inner class. In this blog entry I and Paul Sandoz discuss alternatives to creating GenericType instances:

http://kingsfleet.blogspot.com/2011/07/slightly-tidier-version-of-super-type.html

Ideally the basic static methods list(Class) and map(Class) would be added. The field() method is probably more controversial as it requires slightly less standard changes.



 Comments   
Comment by Marek Potociar [ 08/Feb/13 12:08 AM ]

Closing as duplicate.





[JAX_RS_SPEC-108] Response doesn't have a generic type Created: 03/Jun/11  Updated: 24/Feb/12  Resolved: 24/Feb/12

Status: Resolved
Project: jax-rs-spec
Component/s: None
Affects Version/s: 1.1
Fix Version/s: 2.0

Type: Bug Priority: Major
Reporter: gdavison Assignee: Marek Potociar
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAX_RS_SPEC-15 Response/ResponseBuilder should be Ge... Open
Tags:
Participants: gdavison and Marek Potociar

 Description   

Currently in 1.0 Jersey doesn't have a generic type parameter for the Response element so you are forced to use:
@GET
@Produces(MediaType.APPLICATION_JSON)
public JResponse<List<Bean>> get() {
Stock stock = new Stock();
stock.setQuantity(3);

return Response.ok(
new GenericEntity<List<Stock>>(Lists.newArrayList(stock)){}).build();
}

This is of course a hack of the JDK that creates a new inner class, Jersey has a subclass or Response, JResponse, which takes a generic parameter. So you are able instead to this this notation:

@GET
@Produces(MediaType.APPLICATION_JSON)
public JResponse<List<Bean>> get() { Stock stock = new Stock(); stock.setQuantity(3); return JResponse.<List<Bean>>ok(Lists.newArrayList(stock)).build(); }

This is much cleaner and probably faster, this also means that they type of the reponse can be know to the WADL XSD Schema generator without the user having to use extra annotations. There is one enhancement for this builder, any method that takes an entity currently just returns a builder of the same type. Ideally it should return JResponseBuilder<Entity> this would further simplify the code to be as follows:


@GET
@Produces(MediaType.APPLICATION_JSON)
public JResponse<List<Bean>> get() { Stock stock = new Stock(); stock.setQuantity(3); return JResponse.<List<Bean>>ok(Lists.newArrayList(stock)).build(); } }

There is a limitation in the JResponse API in that the return type from methods such as ok and entity don't transmute the generic parameter, it should be possible with the right parameters to just be able to type:

@GET
@Produces(MediaType.APPLICATION_JSON)
public JResponse<List<Bean>> get() { Stock stock = new Stock(); stock.setQuantity(3); return JResponse.ok(Lists.newArrayList(stock)).build(); }

Here is some code to show how the API would look:

package webservice;

import com.sun.jersey.api.JResponse;

import java.util.List;

public class Test {
public JResponse<List<String>> get() { List<String> list = null; return JResponse.<List<String>>ok(list).build(); }

public GResponse<List<String>> get2() { List<String> list = null; return GResponse.ok(list).build(); }

public GResponse<List<String>> get3() { List<String> list = null; return GResponse.ok() .entity(list) .build(); }

public static class GResponse<Type> {

public static GResponseBuilder<?> ok() { return new GResponseBuilder(); }

public static <Param> GResponseBuilder<Param> ok(Param type) { return new GResponseBuilder<Param>(); }

}

public static class GResponseBuilder<Type> {

Type entity;

public <Param> GResponseBuilder<Param> entity(Param type) { @SuppressWarnings("unchecked") GResponseBuilder<Param> builder = (GResponseBuilder<Param>)this; builder.entity = type; return builder; }

public GResponse<Type> build() { return null; }
}

}



 Comments   
Comment by Marek Potociar [ 19/Sep/11 08:59 AM ]

One solution would be to make Request/Response generic. I am however worried that often Req/Resp are used to produce/consume arbitrary types based on the program flow, message header content or status code. Introducing generics would make such universal code more complicated IMO and would go against the spirit of Request/Response as a type-indifferent components.

Thoughts?





[GLASSFISH-19229] Fix deployment from JDeveloper issue described in GLASSFISH-3297 Created: 24/Oct/12  Updated: 18/Jan/13  Resolved: 18/Jan/13

Status: Resolved
Project: glassfish
Component/s: web_services
Affects Version/s: 4.0_b59
Fix Version/s: 4.0_b72_EE7MS4

Type: Bug Priority: Major
Reporter: gdavison Assignee: Lukas Jungmann
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File WebServices.war    
Issue Links:
Duplicate
duplicates GLASSFISH-3297 Simple war file doesn't appear to dep... Resolved
Tags:
Participants: gdavison and Lukas Jungmann

 Description   

So I am trying to deploy a simple war file generate by Oracle JDeveloper 11 (Technology Preview) by
placing it in the autodeploy directory.

This war file contains one class:

package org.kingsfleet;

@WebService
public class MathService {
public int thing(int a, int b) { return a^b; }
}

With the following web.xml:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<description>Empty web.xml file for Web Application</description>
<servlet>
<servlet-name>MathServicePort</servlet-name>
<servlet-class>org.kingsfleet.MathService</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MathServicePort</servlet-name>
<url-pattern>/mathserviceport</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>35</session-timeout>
</session-config>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

When copied to the autodeploy directory I quite quickly see the WebServices.war_deployed signal which
is good. When I try to test my web service using the management console though I get "404 - Resource
not avaliable" when I try to test or view the WSDL for the service. Interestingly I can view the deployment
descriptor okay.

If modify the web.xml to remove all the servlet mappings:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://
java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee">
<description>Empty web.xml file for Web Application</description>
<mime-mapping>
<extension>html</extension>
<mime-type>text/html</mime-type>
</mime-mapping>
<mime-mapping>
<extension>txt</extension>
<mime-type>text/plain</mime-type>
</mime-mapping>
</web-app>

The service deploys properly.

There is a bug GLASSFISH-3297 that is tracking the inconsistency with the reporting of the deployment status, and this bug is specifically to look at the failure to deploy in this case.



 Comments   
Comment by Lukas Jungmann [ 18/Jan/13 08:10 PM ]

as soon as load-on-startup element is removed from web.xml, application deploys fine and web service is responding to requests, so the best and the easiest fix would be on the JDeveloper side to not generate load-on-starup element.

problem of that element is that it forces servlet container to instantiate the class before webservice logic is in place and causes classcastexception - this is more a configuration error which is tracked in original GLASSFISH-3297 therefore marking this as a duplicate of that issue.





Generated at Thu Apr 24 12:52:51 UTC 2014 using JIRA 4.0.2#472.