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.
Related
As part of my JEE routine i run a JUnit test using Payara embedded and Maven.
But the process is not optimal.
I need to change the port from default 8080 to 8888 for instance.
Also I receive the following error when test is run:
Caused by: javax.naming.NamingException: Lookup failed for 'resource/frontPageDirectory' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.namin
I can probably use the following command line flag
-Ddeployment.resource.validation=false
but I don't know how to apply it in my maven file.
My maven file is simply:
<dependency>
<groupId>fish.payara.extras</groupId>
<artifactId>payara-embedded-all</artifactId>
<version>5.192</version>
<scope>test</scope>
</dependency>
So my question is how do I add these parameters to my maven pom file?
Kim
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.
I am trying to run my first websocket app and refered this link to get some sample code . I simply created CustomEndPoint , WSClient class , html file and then ran it on netbeans IDE and it was working like a charm.
I tried to deploy it on tomcat server whose url is accessible using https by changing ws:// with wss:// and it worked on my dev environment but when I deployed the same code on Production env its throwing below error in console:
WebSocket connection to 'wss://xxxxxx-xxx.xxxx.com/websoc/ratesrv' failed: Error during WebSocket handshake: Unexpected response code: 404
For dev environment I below WS call is working :
wsocket = new WebSocket("wss://dev_ip:8443/websoc/ratesrv");
For Prod I am using(note the .com in url):
wss://xxxxx-xxxxx.xx.com/websoc/ratesrv
Do I need to explicitly provide the port number as well in PROD ?
Does your Tomcat version includes Websockets Runtime?
If it does you must delete all the Websockets dependencies from your WAR. Ensure that you call mvn clean after change scope to provided.
If not, you should include it. If you want to use Tyrus just put
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-container-servlet</artifactId>
<version>1.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-client</artifactId>
<version>1.12</version>
</dependency>
And check that that there are no errors in the Tomcat console when deploy.
Try to use the latest version of tomcat.
tomcat8.5.20 worked for me.
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
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>