I am simulating multiple TomEE (1.7.1) instances using virtual-hosts.
I have multiple virtual-hosts that are deploying the same war with the same EJBs.
This leads to:
org.apache.openejb.DuplicateDeploymentIdException: Application cannot be deployed as it contains deployment-ids which are in use
Any suggestions on how to solve this?
did you try openejb.deploymentId.format = {appId}/{ejbJarId}/{ejbName} in conf/system.properties?
To make it even more portable coming 1.7.2 (release process in progress) and coming 2.x will support:
openejb.deploymentId.format = {host}/{appId}/{ejbJarId}/{ejbName}
and even
openejb.deploymentId.format = {hash}/{host}/{appId}/{ejbJarId}/{ejbName}
Related
I'm using mariadb-java-client 2.2.3 to connect to a MySQL server 8.0.11. I'm also using spring-boot 2.0.2. for the application.
On application startup, I'm getting the following execption:
java.sql.SQLException: (conn=9) Unknown system variable 'tx_isolation'
at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:198) ~[mariadb-java-client-2.2.3.jar:na]
at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110) ~[mariadb-java-client-2.2.3.jar:na]
at org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228) ~[mariadb-java-client-2.2.3.jar:na]
at org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334) ~[mariadb-java-client-2.2.3.jar:na]
at org.mariadb.jdbc.MariaDbStatement.executeQuery(MariaDbStatement.java:505) ~[mariadb-java-client-2.2.3.jar:na]
at org.mariadb.jdbc.MariaDbConnection.getTransactionIsolation(MariaDbConnection.java:859) ~[mariadb-java-client-2.2.3.jar:na]
According to the MySQL link below, the system variable 'tx_isolation' that was previously deprecated has now been removed. 'transaction_isolation' should be used instead.
https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-3.html
Is there a workaround for this issue?
Thanks.
There is no workaround for the moment. Issue has been created on https://jira.mariadb.org/browse/CONJ-604 to handle that for next version 2.2.5.
Currently, MySQL 8.0 is not supported (some tests even freeze the server), so waiting version to be more stable (and a working docker image to test properly with CI).
For people who switch from MySql to MariaDb on their existing SpringBoot project, and face the same issue:
Upgrading mariadb-java-client to 2.6.0+, in your pom.xml solve the issue (most tutorial on the net has 2.1).
I am just starting with Meteor and working on an existing project. I am running into an issue with one of the packages(observatory-apollo) that's has the following line:
__meteor_bootstrap__.app.use Observatory.logger #TLog.useragent
It is complaining that __meteor_bootstrap__.app is undefined.
What is __meteor_boostrap__ exactly? I can't seem to find a description of what it is but from threads, people seem to know how to use it. I can only see it defined in boot.js, but it doesn't really tell me much...
Meteor uses connect npm module under the hood for various reasons, to serve static files, for example. __meteor_bootstrap__.app was the reference to connect app instance.
Before it was __meteor_bootstrap__.app but it changed couple of releases ago and became WebApp.connectHandlers object and is part of WebApp package.
WebApp is a standard package of Meteor, core package for building webapps. You don't usually need to add explicitly as it is a dependency of standard-app-packages.
Example of usage the connectHandlers is to inject connect middlewares in the same way as you would use any connect middleware (or some express middlewares, express is built on top of connect):
WebApp.connectHandlers
.use(connect.query())
.use(this._config.requestParser(bodyParser))
You can look at meteor-router Atmosphere package and take it as an example: https://github.com/tmeasday/meteor-router/blob/master/lib/router_server.js
More about connect: https://npmjs.org/package/connect
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
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.