When my Felix (OSGi) starts it launches Felix Web Console bundle. This bundle uses Jetty which uses the felix property org.osgi.service.http.port to determine which HTTP port number to use.
One of my bundles on OSGi, developed by myself requires Grizzly to deal with WebSockets and so forth, therefore, one of the bundles that is also launched by OSGi is Grizzly OSGi HTTP Server bundle. Which attaches a web server to the HTTP port defined in org.osgi.service.http.port.
This causes a collision of HTTP ports. The dilema, I need both Felix Web Console and Grizzly. For what I'm concerned, Grizzly can run on a different por. But it seems to be lacking means to achieve this task.
Has anyone had this problem before? This issue from 2009 reflects this problem and it seems that Grizzly team fixed it, since I'm using the last release version 2.3.18, I can't see why I'm facing this problem.
After investigating on this HTTP port conflict problem. I got intrigued why Felix Web Console requires Jetty in particular. So I decided to remove Felix Web Console bundle from Felix, and I downloaded it from Maven Central along with it's dependencies.
During this process I haven't seen any dependency on Jetty, so my guess is that I was including Jetty to serve Felix Web Console by mistake.
After doing this, Felix Web Console seems to get along really well with Grizzly Http Service!
Just for curiosity, I decided to look into Felix Web Console code and on their code they have a class called OsgiManager. This clever class binds Felix Web Console to the first HTTP Service found.
This is why HTTP services look by default to the OSGi property org.osgi.service.http.port. There is supposed to exist only one HTTP Service at a time within Felix, which makes sense. Therefore, because I removed my Jetty bundles that I though to be related with Felix Web Console, everything started working because now Grizzly HTTP Service become the only HTTP Service available. That why this all worked in the first place!
Related
WebLogic 12c includes a Default JAX-RS resource (https://docs.oracle.com/cd/E24329_01/web.1211/e24983/configure.htm#RESTF191) that will register all classes annotated with JAX-RS annotations as resources.
I use the Jersey proxy client (http://blog.alutam.com/2012/05/04/proxy-client-on-top-of-jax-rs-2-0-client-api/), so my interface classes have all the JAX-RS annotations and are packaged in their own "API" jar. The API jar is then deployed to basically two different contexts: the service and the client. The Service provides an implementation of the API that is the actual business logic and is exposed as a JAX-RS web service. The client is just a consumer of the service and the implementations of the service interfaces in the API jar are Jersey Proxy Clients.
Unfortunately, WebLogic 12c is causing me two problems here:
1) It is automatically registering all the resources in my API jars and exposing them as web services from the client application (with the implementation being the (now literally) proxy client)! Which is extremely unintended.
2) Sometimes I want to use classes from an API without actually consuming the service, so I don't even provide implementations for the interfaces. This should be fine, but because WebLogic is attempting to automatically load the API resources, but not finding implementations for the annotated interfaces, it refuses to deploy the war.
I could hack around issue 1 with security policies or weird jax-rs configurations in the web.xml, but that doesn't solve issue 2. The best solution is just to turn off the Default Resource in WebLogic, but I can't find any documentation to do so.
Is there any way to turn off the Default Resource in WebLogic or turn off automatic Jersey scanning?
As far as I can tell, removing these files from weblogic 12.2.1.3 completely removes jersey from starting up and scanning the classpath for annotations:
wlserver/modules/weblogic.jaxrs.integration.jar
oracle_common/modules/com.sun.jersey.jersey-core.jar
oracle_common/modules/weblogic.jaxrs.portable.server.jar
The weblogic portable server is activated by the hk2 dependency injection system, which loads jersey as an OSGI bundle and activates it
Bit confused with Spring framework and what capabilities application server provides.
I was reading this answer on same site
There he says,
Additionally App Server have components and features to support
Application level services such as Connection Pooling, Object Pooling,
Transaction Support, Messaging services etc.
That means we can optionally use apis of application server to manage transaction in our web application (inject web application :()and I think spring also provides transaction apis. So whats the difference?
Please, help me to make it clear. Thanks you.
When you use app server resources (transactions, connection pools etc.) directly in your application code, you can only run it when it is deployed on an application server or even worse only on that syme type of application server.
Spring allows you to use those resources and configure your application for different environments. The application can be run on any application server or on a simple Tomcat, or on different servers in the cloud.
Spring also allows you to run your code in tests (unit tests) without the need to start up an application server. This is absolutely needed to write automated tests.
Everything that can be done with an application server, can be done with spring as well.
There is a whole world of spring libraries and framework that provide features that are not available directly on application servers.
I can really recomand to give spring a try.....
I need to do some processing on the endpoint classes before they can be deployed and then deploy them manually. However it seems simply having a class annotated with #ServerEndpoint in my war is enough to deploy the endpoint in Tomcat and when I try to manually deploy later obviously I can't because the URL has been deployed already. Is there any way to disable the autodiscovery of endpoints?
Looking at the source for the version I'm using - 8.0.28, there's no dedicated option. The code deploying the endpoints is in org.apache.tomcat.websocket.server.WsSci. The quickest 'shurest' hack is to put my endpoints into the javax.websocket package. I elected to use their ServerApplicationConfig hook instead which serves my purposes if with some minor issues.
I have a server running on tomcat exposing Spring services using HttpInvoker.
I have exposed the methods of 5 services using HTTPInvoker.
This works very well.
The spring configuration is described in a file named remoting-servlet.xml; and the remoting servlet (DispatcherServlet) is described in the web.xml.
I now have an additional need to expose one additional service using JAX-WS this time (I will have C# clients).
I will use Spring support to JAX-WS.
I have the option to use the default deployment, or to use JAX-WS RI's to deploy this additional service to the same server as the remoting servlet.
I would prefer this last solution, because I would have only one server providing the remote services (whether they are web services or httpinvokers).
My question is: is this possible?
I think that I can I put the 2 servlets on the same port. But my issue is that it seems to me that I will have to provide 2 different application contexts. One for the DispatcherServlet, and one for the WSSpringServlet.
Is that correct?
Is it possible to put the WSSpringServlet context definition to the same file as the one for the httpinvokers (remoting-servlet.xml)?
Many thanks
Gilles
I've developed a spring integration component that is to sit on a server and process messages coming in over an inbound RMI channel do some processing/filtering and then send out some messages over a different RMI channel.
Currently, for testing, I've been running it using a Main class that just loads the context, which sets up the inbound RMI gateway and it's working fine. But I don't think that this is appropriate for a production environment.
What is the best way to deploy this type of project to a server?
If I were working in a .Net I'd be deploying this type of application as a windows service, is that what I should be doing here?
The application that is sending me data is hosted in Tomcat, would it be a good idea to also run this application within the same Tomcat container (Current requirements are for both components to be on the same machine this may change)? And if so how?
I'm currently looking into Spring Boot, am I on the right path?
I think the best would be Spring Boot, as it's made to easily allow running different types of applications. Also, you don't need Tomcat if you can run the same component with a simple Main and not using UI. Spring Boot, also, has a sample using Spring Integration here, so you should be up and running in no time.