I am trying to do session management using tomcat modules in gemFire. Reference link we used is [https://gemfire.docs.pivotal.io/95/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html].
Application server that we are using is tomee 7.0.5. After making the changes mentioned in the link. When i tried to make the server up, we were getting an error "getContainer() method not found in class DeltaSessionManager".There is a module geode-modules-9.5.1.jar provided by gemFire(gfsh Client) which helps for session management. Inside that there is a class DeltaSessionManager which extends another class org.apache.catalina.session.ManagerBase . But the ManagerBase class in catalina.jar inside tomee 7.0.5 doesn't have this method. But when we downloaded tomcat catalina jar separately we were able to see this method. Is there any difference in the approach for tomee.
Any help would be appreciable
Looking at the tomee source code, I suspect tomee 7.0.5 is actually embedding Tomcat 8. In that case, you need to use Tomcat8DeltaSessionManager, which supports Tomcat 8 and above.
Related
This question already has an answer here:
Can't override java.util.logging.LogManager in a Spring Boot web application: Getting java.lang.ClassNotFoundException on already loaded class
(1 answer)
Closed 10 months ago.
I'm running Tomcat as an embedded server inside of a Springboot app, so all the additional functionality in JULI such as multiple class loaders etc is not needed and just gets in the way.
I just want my app to use java.util.logging directly without the extra complication of JULI. I want a flat configuration where everything just flows directly to java.util.logging and the way I have configured it.
How can I ditch JULI?
UPDATE
The actual problem I'm having is that I'm unable to load a custom Handler... getting a ClassNotFound. I initially thought this was caused by JULI but really seems to be related to Spring Boot's System Class Manager unwillingness to load classes from BOOT-INF.
JULI is just a logging facade used by Tomcat for its internal logging (cf. javadoc) based on Apache Commons Logging. It is not a logging framework and does not perform any logging by itself.
By default it uses java.util.logging plain and simple the way you configured it.
The additional functionality you can find in a standalone Tomcat (per classloader configuration, multiple handlers of the same class, etc.) is provided by ClassLoaderLogManager. In order to use it you need to set:
-Djava.util.logging.logmanager=org.apache.juli.ClassLoaderLogManager
as JVM parameter (anywhere else it will be probably ignored).
Tomcat's startup scripts add the above mentioned Java system property, but your Spring Boot application almost certainly does not. Hence your application is using java.util.logging plain and simple (unless you are using spring-boot-starter-logging in which case java.util.logging is redirected to LogBack).
TL;DR: by default Tomcat JULI simply forwards messages to java.util.logging. There are no complications.
I'm trying bootify my app, which is XML configured. I'd love to have an embedded tomcat server that I can just run through the main method.
The simplest way to do it is to bootstrap the app using the existing XML config through #ImportResource("classpath:app-servlet.xml").
I cannot use auto configuration. We have certain circular dependencies that are not trivial to fix at this point.
The problem is that the embedded tomcat server only gets automatically configured if you use #EnableAutoConfiguration.
Is there a way to only auto configure the embedded server? I tried looking that Spring Boot's sources, namely EmbeddedServletContainerAutoConfiguration, including extending it and "running" it through my setup, but it only runs the customizers, not the ServletInitializer, therfore I'm getting an error "Root context already initialized".
Any help would be greatly appreciated.
I have guvnor deployed on tomcat 7. Now need to deploy a wrapper webservice around the BRMS. The webservice is a spring-ws and uses #Autowired kbase dependency injection. kbase is configured in spring-context XML as (not literal):
<drools:resource id="xxx" source="http://localhost:8080/guvnor/.../<package>/LATEST
Now the problem is tomcat first loads the webservice which fails to initialize as the guvnor URL is not up yet.
I can work around this by first starting only guvnor along with tomcat startup and then copy the WS war to the webapps folder. This works but is painful to do everytime.
What is the best approach?
I have seen this thread, but not sure if it will work in this context: Is there a way to enforce a deployment order in tomcat6?
Tried the following ways to address this:
Tomcat brings up both services on starup. The initialization of webservice fails but bring up the webservice manually through tomcate admin interface.
Use a script to do the same as above to bring up the webservice after a delay.
Change the drools package initialization to load through drools API instead of through config files along with a retry logic.
All of these work, but retaining the last option in the production code.
I am trying to write a JAX WS client for a service exposed using Axis2, WebSphere8, Java 1.6.
Standalone client(i.e. client running in my local machine) works fine but when I deploy the client in a application running in same websphere server I get
java.lang.ClassCastException: Cannot cast class org.apache.axis2.jaxws.spi.Provider to class javax.xml.ws.spi.Provider
at line OpenPortType service = OpenService
.create(wsdlFile.toURL(),
new QName( "http://www.test.com/schemas/public/open-api/Open/","OpenService")).getPort(
OpenPortType.class);
When I tried to google I found similar problem existed in weblogic : https://wso2.org/jira/browse/CARBON-4835
When we see source of axis2.jaxws.spi.Provider class we come to know that it's a subclass of javax.xml.ws.spi.Provider !!
I'm wondering what could be wrong ? Any idea ?
Unless you are calling Axis2 capabilities directly, rather than simply using JAX-WS APIs, you do not want to package Axis into your EAR. WebSphere does provide its own JAX-WS implementation which I'm not surprised conflicts with another JAX-WS implementation you've deployed in your app. (In particular, note that WebSphere's own implementation is based on Axis2.)
If you do need to deploy a different implementation, you'll probably have to at least adjust your WebSphere classloader policy to parent_last. There might be more to do as well; it's been a while since we did this ourselves. But it's much easier and cleaner to use the built-in JAX-WS implementation, which means not deploying any of those jars at all.
Can someone please provide me or link for sample project with standard java rmi capabilities. I wish to deploy it in Glassfish 3 and I have just about tried everything to get a simple project running, but Glassfish does not register my objects. I see that the there is a standard JMX RMI registered on statrup on port 8686 for glassfish. I haven't found any tutorials or examples on this that work. If possible in JAR archive, simple hello world which I can call externally.
Thanks in advance
Ok basically it came down to the following:
Created simple main class within the EJB project.
Stating the class should be fired upon startup of the war from the manifest does not work.
Added the annotation #Startup right above my class declaration.
Added the annotation #PostConstruct above my main method, this invoked my method at start up and registered the RMI service.