I'm starting to develop a new webapp, I have some past experience but this isn't my strongest area. In the past we've used Tomcat 8.5, Jersey for rest services and additionally atmosphere for websockets and realtime notifications configured through a web.xml.
Starting a new project I wanted to pick up the latest versions of everything. I have tomcat 10 and jersey running together without a web.xml and I was just wanting to add atmosphere in. As far as I understand atmosphere 3.0.2 should be fine with servlet-api 5.0.0. When tomcat starts I can see org.atmosphere.cpr.ContainerInitializer runs but it doesn't find the AtmosphereServlet.
Is there something extra that's needed to make this available? I can see it on the classpath but I'm not sure what is needed to make tomcat incorporate it into the ServletContext servlet registrations as atmosphere seems to expect.
Thanks for any help.
Possibly a Friday afternoon problem.
Annotating my extension of AtmosphereServlet as a #WebServlet and including a url pattern in the annotation causes everything to spark into life.
Related
I got completely stuck. I want to use CDI2 with Servlets to write a simple web app. However, the beans not get loaded.
I get the following error in JBoss or Payara or Weld (if running as Main Application):
WELD-001524: Unable to load proxy class for bean Managed Bean [class MyBean] with qualifiers [#Any #Default]
Does anyone still use CDI2 or has a running modern example?
I compile with maven.
warm regards,
Alex
I found it out myself. I had the wrong dependencies. I got confused because of Jakarta. I used the CDI-2 maven dependency. So I updated to Jakarta. Right? This is the way to go, right?
I can deploy. Payara-Micro works. JBoss (WildFly should do the same)
However, Payara Micro does not get track of the URL patterns of simple Servlets, although still, one can call it over the client. (Intellij has a CDI tab, gives a nice overview itself)
...
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version>8.0.0</version>
<scope>provided</scope>
</dependency>
I hava met some problems .
I want to encrypt the war using Spring by a tool named ClassGuard ,but when I deploy it to Tomcat and started to launch it , some problems(seemed to be A fatal error has been detected by the Java Runtime Environment) arised .
have anyone used ClassGuard and met problems like this?
please help me...thanks in advance!
Although without the exception we can only speculate, the ClassGuard FAQ section clearly states that:
As of Version 1.5, ClassGuard supports Tomcat containers.
To use ClassGuard in combination with tomcat, you have to configure your web application for using the ClassGuard tomcat class
loader. This can be set in the context of the web application.
So make sure that:
You are using the latest stable version.
You are using the appropriate class loader.
A probably (although not sure if it is what you are after) easier way to discourage usage of your code would be through Obfuscation Tools such as these.
At the moment, the Hibernate Validator has released the latest version as 4.3.0.Final here. I have tried to upgrade it to my Glassfish 3.1.2 as the following step: -
1. Remove the GLASSFISH/glassfish/modules/bean-validator.jar
2. Copying the hibernate-validator-4.3.0.Final.jar to GLASSFISH/glassfish/modules
3. Restart the Glassfish
4. The Glassfish cannot start. It seems hang.
After searching via the Google, I've found that the file named "bean-validator.jar" was created by the Glassfish team as an OSGi version. Sadly, I cannot find how to create it. Could you please help to advise further? Thank you very much for your help in advance. I'm looking forward to hearing from you soon.
A (slightly outdated) description of how to build Glassfish's bean-validator.jar can be found here.
What's needed in general is an OSGi bundle which includes Hibernate Validator itself and the Bean Validation API. With this bundle you should be able to replace the original bean-validator.jar. Additionally you need the JBoss Logging bundle, which is used since release 4.3 by Hibernate Validator as logging API and already comes in form of an OSGi bundle.
If you're building a web application, you could also package HV 4.3 within your WAR and turn off class loader delegation by providing the file WEB-INF/glassfish-web.xml with the following contents:
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false" />
</glassfish-web-app>
That way the HV classes will be loaded from your application instead of from the module provided by Glassfish.
You might also be interested in the issue GLASSFISH-15648 which aims to provide a dedicated Glassfish update package for HV.
As my case was ear, rather than war, based on suggestion of Gunnar, I did a patched version of the module, that is deployable to Glassfish (My version is 3.1.1 OSE).
Someone might find it still useful, see my blog for my solution (including step-by-step approach): http://peter-butkovic.blogspot.de/2012/11/glassfish-311-oss-with-hibernate.html
In order to write servlets code I need servlet-api.jar.
Where do i get servlet-api.jar from ?
Make sure that you're using the same Servlet API specification that your Web container supports. Refer to this chart if you're using Tomcat: http://tomcat.apache.org/whichversion.html
The Web container that you use will definitely have the API jars you require.
Tomcat 6 for example has it in apache-tomcat-6.0.26/lib/servlet-api.jar
Grab it from here
Just choose required version and click 'Binary'. e.g direct link to version 2.5
You may want to consider using Java EE, which includes the javax.servlet.* packages. If you require a specific version of the servlet api, for instance to target a specific web application server, you will probably want the Java EE version which matches, see this version table.
You can find a recent servlet-api.jar in Tomcat 6 or 7 lib directory. If you don't have Tomcat on your machine, download the binary distribution of version 6 or 7 from http://tomcat.apache.org/download-70.cgi
I'm trying to evaluate CDI on Glassfish 3.1 and even though I have accomplished to make it work well, when I'm trying to split my code in separate deployment modules I get a weird error. More specifically:
I have two classes bundled in the same utility project (let's say the CommonLib.jar); the classnames are UserDatabase and UserDatabaseEntityManager and their definitions are as below (in the PS at the end of this message).
I also have an EAR with an EJB3.1 module in it.
When I choose to deploy the CommonLib.jar as a "Bundled Library" of the EAR, then I get the following error:
Error occurred during deployment: Exception while loading the app : WELD-001408 Unsatisfied dependencies for type [EntityManager] with qualifiers [#UserDatabase] at injection point [[field] #UserDatabase #Inject com.test.TestEJB.itemPersistenceEm]. Please see server.log for more details.
Same error as above I get also when I deploy the CommonLib.jar as a shared library (jar file copied under $glasshfish_installation_path/domains/domain1/lib)
BUT, if I choose to just have the two classes (UserDatabase and UserDatabaseEntityManager) in the EJB project (thus they are compiled within the EJB module), then the injection works fine.
Am I facing a classloader issue? Any ideas how I can get past this issue?
Just a guess, because I faced a very similar problem with Glassfish and CDI a few days ago: Do you have a beans.xml in every JAR, i.e. in the CommonLib.jar and the EJB JAR, so that CDI scans both of them?
My problem resulted from the fact that I thought placing a beans.xml into the EAR would be sufficient, which is not the case.
Sounds like you're running into some of the Glassfish CDI integration issues we've found while working on Seam 3. It could be a couple of them, so you'll have to take a look at see which one it may be. Try testing on JBoss AS7 or Apache TomEE and see if you still have problems.