Right now I'm getting this exception from a simple JMS client I wrote to just test to see if I can connect to the JBoss JMS. Here is the snippet of my code below:
Properties props = new Properties();
props.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
props.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
props.setProperty("java.naming.provider.url", url_);
Context context = new InitialContext(props);
System.out.println("performing lookup...");
Object tmp = context.lookup("/ConnectionFactory");
System.out.println("lookup completed, making topic");
TopicConnectionFactory tcf = (TopicConnectionFactory) tmp;
conn = tcf.createTopicConnection();
topic = (Topic) context.lookup(name_);
session = conn.createTopicSession(false, TopicSession.AUTO_ACKNOWLEDGE);
conn.start();
TopicSubscriber recv = session.createSubscriber(topic);
recv.setMessageListener(this);
I have the following jars:
jms.jar (I got this from outside the JBoss distro)
jbossall-client.jar
log4j.jar
jboss-logging.jar
javax.jms.jar (I got this from outside the JBoss distro)
jnpserver.jar
jboss-common-core.jar
I get the following exception:
javax.naming.CommunicationException [Root exception is java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: org.hornetq.jms.referenceable.SerializableObjectRefAddr (no security manager: RMI class loader disabled)]
This is being run locally, also it seems it's connecting to the JBoss server just that it's throwing this exception.
To anybody interested I was able to solve this by adding a few more jar files to my classpath. Also the problem was that I didn't have a security manager in place.
hornetq-jms.jar
hornetq-logging.jar
hornetq-bootstrap.jar
hornetq-core.jar
hornetq-jboss-as-integration.jar
jboss-as-hornetq-int.jar
netty.jar
This jar files can be found with the JBoss distribution.
This resolved exactly the same issue for me.
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-aop-jdk50-client</artifactId>
<version>4.2.2.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.netty</groupId>
<artifactId>netty</artifactId>
<version>3.2.3.Final</version>
</dependency>
<dependency>
<groupId>org.hornetq</groupId>
<artifactId>hornetq-jms-client</artifactId>
<version>2.2.5.Final</version>
</dependency>
<dependency>
<groupId>org.hornetq</groupId>
<artifactId>hornetq-core</artifactId>
<version>2.2.5.Final</version>
</dependency>
Related
Have a JDK7 app running on Tomcat and it does have the following env settings:
-Dhttps.protocols=TLSv1.1,TLSv1.2
The above setting ensures that we don't use TLS 1.0 when connecting over HTTPS while making API calls etc.
We also use the org.springframework.mail.javamail.JavaMailSenderImpl class to send outgoing SMTP email, and use these props:
mail.smtp.auth=false;mail.smtp.socketFactory.port=2525;mail.smtp.socketFactory.fallback=true;mail.smtp.starttls.enable=true
The problem is that the connection to the SMTP email server is failing when it's upgraded to TLS1.2.
javax.net.ssl.SSLHandshakeException: Remote host closed connection
during handshake
Is there a settings or code change that will force the TLS1.2 protocol?
I did some searching and it looks like these env settings are only for applet and web clients, not for server side apps
-Ddeployment.security.SSLv2Hello=false -Ddeployment.security.SSLv3=false -Ddeployment.security.TLSv1=false
This is the fix for the next guy looking:
mail.smtp.starttls.enable=true;
mail.smtp.ssl.protocols=TLSv1.2;
It didn't work for me in one pretty old app and I couldn't realize why. After some research I found that the javax.mail version in the app dependencies was 1.4. You must upgrade to at least 1.5.
I needed both Vojtech Zavrel and Sunny's answer in my case. I was running Java 1.8 Spring Boot 1.2.5 and running on Big Sur 11.2.3 and spring version 4.2.1.RELEASE.
After I updated my dependency like this
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.5.0-b01</version>
</dependency>
and I updated my JavaMailSenderImpl with
Properties prop = new Properties();
prop.setProperty("mail.smtp.auth", "true");
prop.setProperty("mail.smtp.starttls.enable", "true");
prop.setProperty("mail.smtp.ssl.protocols", "TLSv1.2"); // Added this line
prop.setProperty("mail.smtp.ssl.trust", mailUri.getHost());
mailSender.setJavaMailProperties(prop);
I saw the Received fatal alert: protocol_version error resolve.
An update to the most recent version (1.6.2.) of Java Mail also fixes the issue. In my case I upgraded from:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<version>1.5.0-b01</version>
</dependency>
to:
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<version>1.6.2</version>
</dependency>
This fixed the error
javax.mail.AuthenticationFailedException: 421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2
I was getting from an Outlook SMTP-Server. No property changes needed.
Please help,
I have a Java Spring MVC application (Tomcat 7) on OpenShift which is trying to use a resource lookup in Context.xml. I keep getting 500 errors when it tries to create the session session = (Session) envContext.lookup("mail/Session"); ( see code below ). There are no exceptions in the logs in app-root/logs/jbossews.log, e.printStackTrace(); doesn't print anything in the catch block. Do exceptions get logged somewhere else perhaps? I'm used to having a access.log and error.log in apache/tomcat, jbossews.log doesn't see to tell me anything (FYI I am not using RHC tools, I'm just tailing the log over ssh).
My project runs fine on my local system in eclipse with no issues.
Please help,
Thanks
Session session = null;
Context initalContext = new InitialContext();
Context envContext = (Context) initalContext.lookup("java:comp/env");
try{
// Blows up here with a 500 error
session = (Session) envContext.lookup("mail/Session");
}
catch (Exception e) {
// No StackTrace printed
e.printStackTrace();
}
Here is my resource located in jbossews/conf/context.xml
<Resource
name="mail/Session"
type="javax.mail.Session"
auth="Container"
mail.smtp.host="smtp.gmail.com"
mail.smtp.socketFactory.port="465"
mail.smtp.socketFactory.class="javax.net.ssl.SSLSocketFactory"
mail.smtp.auth="true"
mail.smtp.port="465"
mail.from="XXXXXX#mailserver.com"
mail.user="XXXXXX#mailserver.com"
password="XXXXXX"
/>
I tried adding the following to my web.xml to see if that would fix the problem (It didn't).
<resource-ref>
<description>Resource reference to a factory for javax.mail.Session instances that may be used for sending electronic mail messages, preconfigured to connect to the appropriate SMTP server.</description>
<res-ref-name>mail/Session</res-ref-name>
<res-type>javax.mail.Session</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Figured out my issue was due to an issue in my pom.xml (Not related to accessing Context.xml after all). Annoyingly Exceptions weren't being logged in jbossews.log so I had to explicitly log them via Exception exception = (Exception) httpRequest.getAttribute("javax.servlet.error.exception");
exception.printStackTrace(); ( httpRequest being a HttpServletRequest Object)
The problem in my pom.xml was this, I tried using:
<dependency>
<groupId>javax.mail</groupId>
<artifactId>javax.mail-api</artifactId>
<version>1.5.1</version>
<scope>provided</scope>
</dependency>
Using the following dependency solved the issue.
<dependency>
<groupId>com.sun.mail</groupId>
<artifactId>javax.mail</artifactId>
<version>1.5.2</version>
</dependency>
Note: In order for the Context.xml "mail/Session" resource to work on OpenShift I had to create a lib folder in src/main/webapp/WEB-INF/ and place javax.mail-api.jar inside.
Hope this helps anyone else experiencing problems.
I have enabled overthereconnection's through Spring IDE, but when I try running my maven-built application via commandline, I get this error:
Exception in thread "main" java.util.ServiceConfigurationError: jar (Unknown file system scheme! May be the class path doesn't contain the respective driver module or it isn't set up correctly?)
at de.schlichtherle.truezip.fs.FsAbstractCompositeDriver.newController(FsAbstractCompositeDriver.java:33)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:95)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController(FsDefaultManager.java:78)
at de.schlichtherle.truezip.file.TFile.getController(TFile.java:1497)
at de.schlichtherle.truezip.file.TFile.parse(TFile.java:687)
at de.schlichtherle.truezip.file.TFile.<init>(TFile.java:659)
at de.schlichtherle.truezip.file.TFile.<init>(TFile.java:601)
at nl.javadude.scannit.reader.TFiles.tFile(TFiles.java:23)
at nl.javadude.scannit.reader.ArchiveEntrySupplier.withArchiveEntries(ArchiveEntrySupplier.java:23)
at nl.javadude.scannit.Worker.scanFiles(Worker.java:59)
at nl.javadude.scannit.Worker.scanURI(Worker.java:53)
at nl.javadude.scannit.Worker.scan(Worker.java:46)
at nl.javadude.scannit.Scannit.<init>(Scannit.java:41)
at com.xebialabs.overthere.Overthere.boot(Overthere.java:74)
at com.xebialabs.overthere.Overthere.<clinit>(Overthere.java:69)
at com.emc.ondemand.agent.core.discovery.AnalyzeSelf.constructODEnvironmentForSingleHost(AnalyzeSelf.java:172)
at com.emc.ondemand.agent.core.discovery.DiscoverEnvironment.discoverEnvironment(DiscoverEnvironment.java:85)
at com.emc.ondemand.agent.core.discovery.DiscoverEnvironment.main(DiscoverEnvironment.java:48)
My code call looks like:
// establish winrm connection to target host
ConnectionOptions options = new ConnectionOptions();
options.set(ADDRESS, myHost.getIP());
options.set(USERNAME, user);
options.set(PASSWORD, pass);
options.set(OPERATING_SYSTEM, WINDOWS);
options.set(CONNECTION_TYPE, WINRM_NATIVE); // was not able to get WINRM_INTERNAL to work with processes
connection = Overthere.getConnection("cifs", options);
This is the only dependency I have:
<dependency>
<groupId>com.xebialabs.overthere</groupId>
<artifactId>overthere</artifactId>
<version>4.2.1</version>
</dependency>
It does pull in the correct Truezip classes so I'm at a loss as to what it means exactly.
I guess your dependency is an uber-JAR? Please check if there is a file named META-INF/services/de.schlichtherle.truezip.fs.spi.FsDriverService on the class path. Among others, it needs to contain the following entry:
de.schlichtherle.truezip.fs.archive.zip.ZipDriverService
If that's not the case, then please contact the creator of the overthere artifact and tell them that they appear to have incorrectly assembled their artifact from the TrueZIP dependencies.
In all cases, you should be able to fix this problem by adding another dependency to your class path:
<dependency>
<groupId>de.schlichtherle.truezip</groupId>
<artifactId>truezip-driver-zip</artifactId>
<version>7.7.9</version>
</dependency>
I am working on a Jenkins plugin which manages the deployment of EAR files to Java EE containers using the Codehaus Cargo Java API, however I've hit an issue when using the API to deploy to a remote Wildfly container. The code works fine when deploying to other containers such as Glassfish, but when attempting to deploy the EAR file to a Wildfly container the error message XNIO001001: No XNIO provider found is returned.
I've spent several hours researching this problem but I cannot find anything that might resolve the problem. This issue occurs when trying to deploy to Wildfly 8.1 and 8.2 running on Windows and Ubuntu. I've also checked the Wildfly server log but it doesn't contain anything related to this issue.
My question is what can do I to prevent the XNIO001001: No XNIO provider found error when deploying to a Wildfly container whilst the code is part of a Jenkins plugin?
I know that Jenkins already has a similar plugin and that Cargo can be used with Maven to deploy to containers but neither option meets my specific requirements.
The code I've written to deploy the EAR file is as follows:
public void redeploy(String containerId, String deployFile, String hostname, String username, String password) {
DeployableFactory deployableFactory = new DefaultDeployableFactory();
Deployable deployable = deployableFactory.createDeployable(containerId, deployFile, DeployableType.EAR);
ConfigurationFactory configurationFactory = new DefaultConfigurationFactory();
Configuration configuration = configurationFactory.createConfiguration(containerId, ContainerType.REMOTE, ConfigurationType.RUNTIME);
configuration.setProperty("cargo.hostname",hostname);
configuration.setProperty("cargo.remote.username", username);
configuration.setProperty("cargo.remote.password", password);
ContainerFactory containerFactory=new DefaultContainerFactory();
Container container = containerFactory.createContainer(containerId, ContainerType.REMOTE, configuration);
DeployerFactory deployerFactory = new DefaultDeployerFactory();
Deployer deployer = deployerFactory.createDeployer(container);
deployer.redeploy(deployable);
}
When containerId is set to wildfly8x the error message XNIO001001: No XNIO provider found is returned along with the following stacktrace:
org.codehaus.cargo.util.CargoException: Cannot deploy deployable org.codehaus.cargo.container.deployable.EAR[hello-world-ear-0.0.1-SNAPSHOT.ear]
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:216)
at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:245)
at org.jenkinsci.plugins.cargo.CargoDeployer.redeploy(CargoDeployer.java:56)
at org.jenkinsci.plugins.cargo.DeployerRedeploy.perform(DeployerRedeploy.java:97)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1769)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:238)
at org.xnio.Xnio.getInstance(Xnio.java:193)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:101)
at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50)
at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79)
at org.codehaus.cargo.tools.jboss.JBossDeployer.executeAction(JBossDeployer.java:144)
at org.codehaus.cargo.tools.jboss.JBossDeployer.deploy(JBossDeployer.java:84)
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:212)
... 12 more
java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:238)
at org.xnio.Xnio.getInstance(Xnio.java:193)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:101)
at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50)
at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79)
at org.codehaus.cargo.tools.jboss.JBossDeployer.executeAction(JBossDeployer.java:144)
at org.codehaus.cargo.tools.jboss.JBossDeployer.deploy(JBossDeployer.java:84)
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:212)
at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:245)
at org.jenkinsci.plugins.cargo.CargoDeployer.redeploy(CargoDeployer.java:56)
at org.jenkinsci.plugins.cargo.DeployerRedeploy.perform(DeployerRedeploy.java:97)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1769)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
In the pom.xml file for my plugin I've included the following dependencies
<dependency>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-core-container-wildfly</artifactId>
<version>1.4.14</version>
</dependency>
<dependency>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-core-container-jboss</artifactId>
<version>1.4.14</version>
</dependency>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-controller-client</artifactId>
<version>8.2.0.Final</version>
</dependency>
Update: I've done some further investigation and have found this is only an issue when running my code as a Jenkins plugin. If I use the same code in a standalone application then Cargo is able to deploy the EAR file to Wildfly without any problems.
It looks like you have xnio-api.jar but no xnio-nio.jar in the classpath when you run your code as a Jenkins plugin. You can run mvn dependency:tree and look what XNIO version is used and then bundle it with your plugin.
You can add a xnio-nio.jar to your classpath with this dependency in you pom.xml:
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
<version>3.4.6.Final</version>
</dependency>
See also the version list here: https://mvnrepository.com/artifact/org.jboss.xnio/xnio-nio
Architecture:
Windows Client -> Wildfly JAX-RS Services -> JBoss 5.1.0.GA legacy system.
I am getting a java.lang.ClassCastException: javax.naming.Reference cannot be cast to com.interfaces.GroupBookingManagerRemote when communicating here between Wildfly JAX-RS Services and JBoss 5.1.0.GA legacy system.
As I am communicating from Wildfly to JBoss AS 5.1.0.GA I am attempting to connect using JNDI.
In my Wildfly Server Maven pom I include:
<dependency>
<groupId>jboss</groupId>
<artifactId>jnp-client</artifactId>
<version>4.2.2.GA</version>
</dependency>
This gives me access to the required org.jnp.* classes and interfaces.
I simply use the following code to connect to my remote machine and retrieve back a GroupBookingManager. However the issue appears when I attempt to cast the class to the interface GroupBookingManagerRemote.
Properties env = new Properties();
env.setProperty(Context.PROVIDER_URL, "jnp://myremoteserver:1099");
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
InitialContext initialContext = new InitialContext(env);
Object ref = initialContext.lookup("MyEARFile/GroupBookingManager/remote");
if (ref != null) {
bookingManager = (GroupBookingManagerRemote) ref; // java.lang.ClassCastException: javax.naming.Reference cannot be cast
}
I have a myclient.jar file which I have added to my Wildfly application that contains the remote interface GroupBookingManagerRemote.
Does anyone see any issue with what I have done?
Thanks,
Darren
Thanks for your help Gimby,
I found the answer myself after a bit more messing about.
From Wildfly 8.1.0 (client) -> JBoss AS 5
You do not require any JBoss 5 jars
Firstly you need a reference to the interface that you wish to use on the client side. This can be in a your-project-client.jar. If using Maven you can create a repository and build the Maven directory structure using mvn
mvn install:install-file -DlocalRepositoryPath=DirectoryName -DcreateChecksum=true -Dpackaging=jar -Dfile=Path-to-you-project-client.jar -DgroupId=YourGroupId -DartifactId=YourartifactId -Dversion=1.0
Then in order to connect to the remote machine and cast the interface back to your-interface, you use:
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, org.jboss.naming.remote.client.InitialContextFactory.class.getName());
env.put(Context.PROVIDER_URL, "remote://remoteserver:4447");
InitialContext initialContext = new InitialContext(env);
This uses Wildfly remote:// which is in remote naming and ejb in wildfly-ejb-client-bom
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>8.1.0.Final</version>
<scope>compile</scope>
<type>pom</type>
</dependency>
And I also required this dependency for communication
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
<version>3.2.2.Final</version>
<scope>compile</scope>
</dependency>
and this one for the remote naming.
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-remote-naming</artifactId>
<version>2.0.1.Final</version>
</dependency>
Also note the port is not the ususal port for JBoss 5 JNDI:1099 this is the Default Remoting Port : 4447
Object ref = initialContext.lookup("ejb:Your-EAR/YourClass/remote!" + YouClass.class.getName());
You can then cast your reference to your interface and use it as normal.
Hope this makes sense.