This basically has me at a loss, and has for almost a week. I'm working on a part of company architecture, trying to get REST all set up. There are two methods that are not in the javax.ws.rs package - SEARCH and PATCH. I've created the following interface in our project to implement SEARCH: (mostly a copy/paste from examples)
/** imports and such as appropriate **/
#Target({ElementType.METHOD})
#Retention(RetentionPolicy.RUNTIME)
#HttpMethod("SEARCH")
public #interface SEARCH {
}
The code using this works flawlessly if called against it directly. However, the web service that talks to the main service fails every time with 500 Invalid HTTP method: SEARCH. So, to be clear, there are two web-enabled services. The first that uses the above code works fine. The second, which is supposed to be nothing but a proxy to the first service fails.
The second service that is having the problem runs on jetty. The servlet that is doing the proxying is an extension of org.mortbay.servlet.ProxyServlet - the only overrides are on init and proxyHttpUrl to do a little bit of URL tweaking. I know that the second service doesn't pass the response into the first because I can shut down the first and the second still gives me that error back.
My question is, am I missing configuration pieces to enable "custom" (i.e. not in the javax.ws.rs package) http methods?
First off, that proxy servlet code is very old, from jetty-6 unless I am mistaken. We have released jetty-9 now, and the last three versions of jetty have come from eclipse so the ProxyServlet you ought to be using is the org.eclipse.jetty.servlets.ProxyServlet class.
Now, from jetty-7 on we added some customization to that proxy servlet so you could modify much more of the client exchange...and you might need to make use of that to get additional http methods working. It could be that the http-client only excepts standard http methods in which case we would have to fix that up for your use case (open a bug at bugs.eclipse.org under RT/Jetty if that is the case).
Related
I'm going crazy here.
I have a local project setup in intellij that makes many different service calls. All I'm trying to do is route those service calls through Fiddler so that I can see headers/bodies for requests/responses easily.
I've read countless posts saying to set the VM options of the intellij configuration to the Fiddler defaults aka
-DproxySet=true
-DproxyHost=127.0.0.1
-DproxyPort=8888
Been there, done that, I've put these arguments is so many different VM option places but nothing seems to work
The Fiddler config settings are all set to default with the only thing I've changed being setting up HTTPS decryption.
The intellij project is Spring Framework running with Maven
I'm fairly new to the Java/Intellij world, but this should be simple. What am I missing, are there any other settings that would step on top of what I'm trying to do?
Edit: Here is the where the code actually makes the service call.
public RxWebTarget getWebTarget(int divisionId) {
ClientHolder clientHolder = this.clients.get(EnumWarehouse.Division.fromId(divisionId));
RestClientFactory.JaxRSClientPool bagRestClient = clientHolder.pool;
RxClient rxClient = bagRestClient.getRxClient(clientHolder.poolName);
return rxClient.target(bagRestClient.getHostName()).path(bagRestClient.getBasePath());
}
That call will only work if divisionId is 71 or 72. 76 and 77 aren't supported yet.
The issue lied within the client we were using to actually make the service call. We were using a JaxRS client. I setup a simple example using an HttpUrlConnection and things worked just fine.
I am writing a restlet client that will invoke some Resteasy coded rest services (cannot change the server code, hence cannot use the Restlet way of annotating resources).
Resource Interface is using JAX-RS annotations and have more than one #POST method (one of the biggest problems of Restlet when dealing with this).
I was trying to do my implementaion this way:
IAppLoginResource resource = JaxRsClientResource.createJaxRsClient("http://localhost:9090/rest", IAppLoginResource.class);
final GetLoginAppInfoResponse response = resource.getLoginAppInfo( getLoginAppInfoRequest );
The problem is that the request by default is GET, I didn't find a way to specify the request method like when using ClientResource (which I can't use because I need to deal with JaxbRepresentation and Jaxb problems).
Any sample/snippet of code that implement a Restlet client using JAX-RS annotated resources?
Any ideas?
Thanks,
I've entered an issue for this topic:
https://github.com/restlet/restlet-framework-java/issues/1081
I've tested a sample application based on your code, and it works properly using the current 2.3 branch (future 2.3.3). I wonder if the fix for this issue https://github.com/restlet/restlet-framework-java/issues/1072 helps.
Regarding the documentation, I 'll complete the current page (http://restlet.com/technical-resources/restlet-framework/guide/2.3/extensions/jaxrs), cf this issue: https://github.com/restlet/restlet-framework-java/issues/1084.
You can also have a look at the org.restlet.test project, especially in this package https://github.com/restlet/restlet-framework-java/tree/2.3/modules/org.restlet.test/src/org/restlet/test/ext/jaxrs.
I need to invoke a GWT RPC service from simple Java code. Yes, I read this
Invoke a GWT RPC service from Java directly
However, my issue is that I do not have access to the web application code (though I could ask and obtain some parts of it), so I cannot just add it to the build path of my Java project. All the info I read from the internet is not clear on what exactly needs to be imported.
The question is: what is the minumum that I should include in my project in order to make the call to the service work (using syncproxy gwt for example)? Will it be enough to redefine the client interfaces inside my code or should I do some compiling work as well?
EDIT: I've done some testing locally with the default web app running on localhost. I created a new java project, imported the sync and async service interfaces and the RPC serialization policy I found in the WAR folder of the web app. This is my testing code
import com.gdevelop.gwt.syncrpc.SyncProxy;
public class serviceCall {
private static final String MODULE_BASE_URL = "http://127.0.0.1:8888/gwttestapp/";
private static final String SERVICE_NAME = "greet";
public static void main(String[] args) {
GreetingService rpcService = (GreetingService) SyncProxy.newProxyInstance(GreetingService.class, MODULE_BASE_URL, SERVICE_NAME, "CB32CC2E454EE7E1088B2E29CEB44F84");
String result = rpcService.greetServer("SyncProxy");
}
}
However the server seems not to recognize the RPC policy, since I get the following exception:
Exception in thread "main" com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: This application is out of date, please click the refresh button on your browser. ( Blocked attempt to access interface 'GreetingService', which is not implemented by 'com.apptesting.server.GreetingServiceImpl'; this is either misconfiguration or a hack attempt )
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.gdevelop.gwt.syncrpc.SyncClientSerializationStreamReader.instantiate(SyncClientSerializationStreamReader.java:746)
at com.gdevelop.gwt.syncrpc.SyncClientSerializationStreamReader.deserialize(SyncClientSerializationStreamReader.java:816)
at com.google.gwt.user.client.rpc.impl.AbstractSerializationStreamReader.readObject(AbstractSerializationStreamReader.java:119)
at com.gdevelop.gwt.syncrpc.RemoteServiceSyncProxy.doInvoke(RemoteServiceSyncProxy.java:204)
at com.gdevelop.gwt.syncrpc.RemoteServiceInvocationHandler.invoke(RemoteServiceInvocationHandler.java:193)
at com.sun.proxy.$Proxy0.greetServer(Unknown Source)
at serviceCall.main(serviceCall.java:11)
Anybody can help?
Try initiating the rpcService without the .gwt.rpc policy specified. IE, just make the call:
GreetingService rpcService = (GreetingService) SyncProxy.newProxyInstance(GreetingService.class, MODULE_BASE_URL, SERVICE_NAME);
You generally do not need to specify the exact serialization policy as the RPC system should automatically figure it out. In fact, it's better not to specify it because the deployed site will change the serialization policy file as the back-end changes. Take a look at the source and testing wiki (https://code.google.com/p/gwt-syncproxy/wiki/SourceAndTesting) for some guidance on on setup need needs. The source code for the Android testing app may provide you some code guidance on creating a functional standalone (if you ignore the AsyncCallback implementations)
In general answer to your question, for deployment purposes, all you really are the interfaces you specified (*Service & *ServiceAsync). For testing purposes in your development environment, you can mock some *Impl files that will provide you some generic responses for testing (such as in the default web-app). Take a look at the Android Wiki in the sync-proxy project (https://code.google.com/p/gwt-syncproxy/wiki/Android) at the setup section for a quick overview on linking the needed files.
Disclaimer: I'm a developer for the Android syncproxy library
I have very perplexing issue that I'm encountering at the moment with Websphere 7.0.0.27 and a particular web service call using the org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean class (from spring-web either 3.2.3.RELEASE or 3.1.1.RELEASE). The service call is functioning perfectly fine when I start my server from scratch. I can call the service, get data back, and my app functions just fine. However, when I re-publish my application, subsequent calls result in the following:
javax.xml.ws.WebServiceException:
ServiceDescription.updateEndpointDescription: Cant do a getPort()
specifiying a different SEI than the previous getPort(). PortQN: {0};
current SEI: {1}; previous SEI: {2} at
org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:173)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:118)
at
org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.updateEndpointDescription(ServiceDescriptionImpl.java:557)
at
org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.updateEndpoint(DescriptionFactoryImpl.java:372)
at
org.apache.axis2.jaxws.description.DescriptionFactory.updateEndpoint(DescriptionFactory.java:178)
at
org.apache.axis2.jaxws.spi.ServiceDelegate.getPort(ServiceDelegate.java:584)
at
org.apache.axis2.jaxws.spi.ServiceDelegate.getPort(ServiceDelegate.java:507)
at javax.xml.ws.Service.getPort(Service.java:103) at
org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.getPortStub(JaxWsPortClientInterceptor.java:419)
at
org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.prepare(JaxWsPortClientInterceptor.java:337)
at
org.springframework.remoting.jaxws.JaxWsPortClientInterceptor.invoke(JaxWsPortClientInterceptor.java:484)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy109.search(Unknown Source) at ...
It happens to the service call only after an app publish. I can call the service over and over without issue, then publish, and then I start getting this issue. After I restart Websphere, the problem is gone until I publish again. Also important is that this seems to only occur when I run the sever setting "Run server with resources within the workspace". The option "Run server with resources on Server" doesn't have this happen, but I don't want to use that setting because I need to do an entire publish (as opposed to simply a file save) to get my JSP changes to show up, and that's a bigger waste of time. Also, I'm using Eclipse (4.2) and this also happens in RAD (7.5).
Has anyone else encountered this issue before, and were you able to resolve it? I'll try to provide any further detail as I come across it.
It would be appropriate that the fix is also obscure, but the portName property was being defined on the bean, and removing that property fixed the issue. Spring apparently would use that property to build a javax.xml.namespace.QName (via javax.xml.namespace.QName.QName(String namespaceURI, String localPart)), and without the portName property set it chooses to use the serviceInterface property instead.
The portName and serviceInterface properties were in fact different values. The portName was being set to the <port name=""/> that's defined in the WSDL, which may have been the incorrect thing to do. Using the interface class name for the QName localPart parameter was ultimately my fix, but it is possible that a better portName parameter would also fix the issue.
I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA.
Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to.
The data I need to get to the RA is
the port it's supposed to listen on,
the license used for the whole application (the feature the RA supplies requires extra licensing)
additional configuration data stored in a db
I've come up with four ideas:
Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that
Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.
But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)
Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.
The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.
Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!
Thanks and cheers,
Julius
In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.
The solution I finally came up with is to use the #ConfigProperty annotation. This means I use option one of my question above.
So my ResourceAdapter class looks like this:
public class Hl7ResourceAdapter implements ResourceAdapter {
#ConfigProperty
private Integer port = null;
// Rest from ResourceAdapter interface omitted here...
// Use port here to open socket...
}
The #ConfigProperty fields can now be set through either
a resource-adapter-config
the ra.xml deployment descriptor
Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)
A few additional notes:
We deploy the resource adapter's .rar file into the .ear of the application using it.
We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.
Hope this helps. kutuzof, will this get you any further?