I'm using Jetty and getting the following problem on my build server (I don't get it on my dev machine).
2013-07-22 14:19:20,647972350: WARN : org.apache.cxf.phase.PhaseInterceptorChain: Interceptor for {http://rs.rtiservice.esi.v21.xxxx.com/}RTIServiceRSI has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:64)
<SNIP>
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking http://localhost:25000/esi-rtiservice/ESI/RTIService/rs-rtiservice/addLineItem/: Read timed out
<SNIP>
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
... 104 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
<SNIP>
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1308)
... 107 more
2013-07-22 14:19:20,654681221: ERROR : [qtp23135205-124] com.xxx.v21.mpos.MPOSEndPoint: System error
javax.ws.rs.NotAuthorizedException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
<SNIP>
at java.lang.Thread.run(Thread.java:662)
2013-07-22 14:19:20,656234277: WARN : org.apache.cxf.phase.PhaseInterceptorChain: Interceptor for {http://mpos.v21.xxx.com/}MPOSEndPoint has thrown exception, unwinding now
java.lang.IllegalStateException: WRITER
at org.eclipse.jetty.server.Response.getOutputStream(Response.java:673)
<SNIP>
at java.lang.Thread.run(Thread.java:662)
2013-07-22 14:19:20,658931461: WARN : [qtp23135205-124] org.apache.cxf.phase.PhaseInterceptorChain: Interceptor for {http://mpos.v21.xxx.com/}MPOSEndPoint has thrown exception, unwinding now
java.lang.IllegalStateException: WRITER
at org.eclipse.jetty.server.Response.getOutputStream(Response.java:673)
at org.apache.cxf.transport.http.AbstractHTTPDestination.flushHeaders(AbstractHTTPDestination.java:564)
Now I can see that some people say I need to set ReceiveTimeout on my connection.1
These people don't seem to have an NotAuthorizedException like I do.
All the examples I see are like this:
<http-conf:destination
name="{http://apache.org/hello_world_soap_http}SoapPort.http-destination">
<http-conf:server ReceiveTimeout="30000"
HonorKeepAlive="true" />
</http-conf:destination>
Conversely, I've defined mine like this:
<jaxrs:client id="itemService" address="http://${itemservice.address}/esi-itemservice/ESI/ItemService" serviceClass="com.xxx.v21.esi.itemservice.rs.ItemServiceRSI" inheritHeaders="true">
<jaxrs:headers>
<entry key="Accept" value="application/xml" />
</jaxrs:headers>
<jaxrs:providers>
<ref bean="jaxbextprovider" />
</jaxrs:providers>
</jaxrs:client>
Can someone tell me how to set the ReceiveTimeout on my connection - Or give me something else to go on please?
I've not found the reason for this, but the work around that I've taken is to switch from Jetty in my integration tests and to start using Cargo to download Tomcat, install the artifact/wars and run the tests.
Cargo is taking 5 seconds a test, Jetty was taking 5 minutes!! So they now all run and it takes 2 minutes to run, not almost an hour!
In short, have a look at Cargo (cargo.codehaus.org)
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.5</version>
<configuration>
<container>
<containerId>tomcat7x</containerId>
<zipUrlInstaller>
<url>ftp://x.x.x.x/install_pack/Tomcat7/tomcat7.zip</url>
<downloadDir>${project.build.directory}/cargo/downloads</downloadDir>
</zipUrlInstaller>
<output>${project.build.directory}/cargo/container.log</output>
<append>false</append>
<log>${project.build.directory}/cargo/cargo.log</log>
<timeout>240000</timeout>
<systemProperties>
<logLevel>INFO</logLevel>
<itemservice.address>localhost:9080</itemservice.address>
<deviceservice.address>localhost:9080</deviceservice.address>
<userservice.address>localhost:9080</userservice.address>
<rtiservice.address>localhost:9080</rtiservice.address>
<corporateservice.address>localhost:9080</corporateservice.address>
</systemProperties>
</container>
<configuration>
<properties>
<cargo.servlet.port>9080</cargo.servlet.port>
<cargo.tomcat.ajp.port>9085</cargo.tomcat.ajp.port>
<cargo.jvmargs>-XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled</cargo.jvmargs>
<cargo.logging>high</cargo.logging>
</properties>
</configuration>
<deployables>
<deployable>
<groupId>com.test</groupId>
<artifactId>test-war</artifactId>
<type>war</type>
</deployable>
</deployables>
</configuration>
<executions>
<execution>
<id>start-server</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-server</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
Related
I'm running a Redis local cluster with Docker like this
docker run --env "IP=0.0.0.0" -p 7000-7007:7000-7007 -p 5000-5002:5000-5002 -p 6379:6379 grokzen/redis-cluster:5.0.3
I can't send commands when connected via telnet like
telnet localhost 7000
Hoewever when trying to connect with the lettuce client with the following code
RedisURI redisURI = RedisURI.Builder.redis("localhost", 7000).build();
RedisClusterClient client = RedisClusterClient.create(redisURI);
StatefulRedisClusterConnection<String, String> connection = client.connect();
RedisStringCommands sync = connection.sync();
String value = (String) sync.get("key");
The following exception is thrown
Exception in thread "main" io.lettuce.core.RedisException: Cannot retrieve initial cluster partitions from initial URIs [RedisURI [host='localhost', port=7000]]
at io.lettuce.core.cluster.RedisClusterClient.loadPartitions(RedisClusterClient.java:865)
at io.lettuce.core.cluster.RedisClusterClient.initializePartitions(RedisClusterClient.java:819)
at io.lettuce.core.cluster.RedisClusterClient.connect(RedisClusterClient.java:345)
at io.lettuce.core.cluster.RedisClusterClient.connect(RedisClusterClient.java:320)
at com.foo.DeleteMe.main(DeleteMe.java:22)
Caused by: io.lettuce.core.RedisConnectionException: Unable to establish a connection to Redis Cluster
at io.lettuce.core.cluster.topology.AsyncConnections.get(AsyncConnections.java:84)
at io.lettuce.core.cluster.topology.ClusterTopologyRefresh.loadViews(ClusterTopologyRefresh.java:68)
at io.lettuce.core.cluster.RedisClusterClient.doLoadPartitions(RedisClusterClient.java:871)
at io.lettuce.core.cluster.RedisClusterClient.loadPartitions(RedisClusterClient.java:844)
... 4 more
Suppressed: io.lettuce.core.RedisConnectionException: Unable to connect to localhost:7000
Caused by: java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:101)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622)
at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:209)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:199)
... 21 more
<!-- The configuration of maven-jar-plugin -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>3.2.4</version>
<configuration>
<!-- put your configurations here -->
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>shadeall</shadedClassifierName>
<relocations>
<relocation>
<pattern>io.netty</pattern>
<shadedPattern>com.ly.dc.io.netty</shadedPattern>
</relocation>
</relocations>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
</plugin>
I am building a CLI tool, which integrates with several EJB modules. For this reason, I need to build a fat jar, which is then executed as a standalone application.
However, executing this fat jar with java -jar (Note: conf/openejb.xml is in the same directory as the fat jar) fails with the following stacktrace:
INFORMATION - PersistenceUnit(name=demo, provider=org.hibernate.jpa.HibernatePersistenceProvider) - provider time 2706ms
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/MEJB!javax.management.j2ee.ManagementHome")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/MEJB")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/openejb/Deployer!org.apache.openejb.assembler.Deployer")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/openejb/Deployer")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/openejb/ConfigurationInfo!org.apache.openejb.assembler.classic.cmd.ConfigurationInfo")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/openejb/ConfigurationInfo")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/DemoServiceImpl!com.github.rzo1.service.DemoService")
INFORMATION - Jndi(name="java:global/DemoMain/demo-shade-1.0-SNAPSHOT/DemoServiceImpl")
INFORMATION - Existing thread singleton service in SystemInstance(): org.apache.openejb.cdi.ThreadSingletonServiceImpl#557c8e7e
INFORMATION - Closing DataSource: demoDS
INFORMATION - Closing DataSource: demoDSNonJTA
Exception in thread "Thread-0" java.lang.RuntimeException: org.apache.openejb.OpenEjbContainer$AssembleApplicationException: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at com.github.rzo1.DemoMain.run(DemoMain.java:116)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.openejb.OpenEjbContainer$AssembleApplicationException: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:346)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:56)
at com.github.rzo1.DemoMain.run(DemoMain.java:90)
... 1 more
Caused by: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:191)
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:913)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:717)
at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:342)
... 3 more
Caused by: org.apache.webbeans.exception.WebBeansException: Wrong startup object.
at org.apache.webbeans.web.lifecycle.WebContainerLifecycle.getServletContext(WebContainerLifecycle.java:227)
at org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:86)
at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:189)
... 7 more
Executing the code directly from my IDE (IntelliJ) the standalone container comes up and behaves as expected.
Version Summary:
openejb in version 1.7.0 / openejb-server in version 7.0.2
maven-shade-plugin in version 2.4.3
Maven in version 3.3.9
hibernate in version 5.2.7
Basic Setup
I was able to reproduce my problem on a simple working example, which I added as an GitHub project for further investigation.
The basic project layout is as follows:
| # demo-shade
| - demo-services (EJB-Module)
| - demo-main (Shading happens here)
The configuration of the maven-shade-plugin is as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<finalName>demo-shade-${project.version}</finalName>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<manifestEntries>
<Main-Class>com.github.rzo1.DemoMain</Main-Class>
</manifestEntries>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/openwebbeans/openwebbeans.properties</resource>
</transformer>
</transformers>
<filters>
<filter> <!-- we don't want JSF to be activated -->
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/faces-config.xml</exclude>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<shadedClassifierName>dist</shadedClassifierName>
</configuration>
</execution>
</executions>
</plugin>
The code to start up the container:
EJBContainer ejbContainer = null;
try {
final Properties properties = new Properties();
properties.setProperty(EJBContainer.APP_NAME, applicationName);
properties.setProperty(EJBContainer.PROVIDER, OpenEjbContainer.class.getName());
properties.setProperty(OpenEjbContainer.OPENEJB_EMBEDDED_REMOTABLE, "false");
properties.setProperty("ejbd.disabled", "true");
properties.setProperty("ejbds.disabled", "true");
properties.setProperty("admin.disabled", "true");
properties.setProperty("openejb.jaxrs.application", "false");
Path launchPath = Paths.get(DemoMain.class.getProtectionDomain().getCodeSource().getLocation().toURI());
properties.setProperty("openejb.configuration", launchPath.toAbsolutePath() + "/conf/openejb.xml");
properties.put("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
properties.put("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
// This is the line starting the EJB container
ejbContainer = EJBContainer.createEJBContainer(properties);
ejbContainer.getContext().bind("inject", this);
ejbContainerReady = true;
final CountDownLatch latch = new CountDownLatch(1);
// Graceful shutdown
Runtime.getRuntime().addShutdownHook(new Thread() {
#Override
public void run() {
try {
logger.info("Shutting down..");
latch.countDown();
logger.info("Shutdown completed successfully.");
} catch (final Exception e) {
logger.error("Graceful shutdown went wrong. SIGKILL (kill -9) if you want.", e);
}
}
});
try {
latch.await();
} catch (final InterruptedException e) {
// ignored
}
} catch (final Exception e) {
ejbContainerReady = false;
throw new RuntimeException(e);
} finally {
if (ejbContainer != null) {
ejbContainer.close();
}
}
}
Questions
Did I miss something in the configuration of the maven-shade-plugin?
How can I build a fat jar using openejb in a standalone manner?
Example Project
The full code example is available as a GitHub Project
UPDATE 1:
I changed the pom according to the answer by P. Merkle. I found an other article here describing the process of shading specifically for TomEE.
pom changed to
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<finalName>demo-shade-${project.version}</finalName>
<transformers>
<transformer
implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<manifestEntries>
<Main-Class>com.github.rzo1.DemoMain</Main-Class>
</manifestEntries>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
<transformer implementation="org.apache.openwebbeans.maven.shade.OpenWebBeansPropertiesTransformer"/>
</transformers>
<filters>
<filter> <!-- we don't want JSF to be activated -->
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/faces-config.xml</exclude>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
<shadedClassifierName>dist</shadedClassifierName>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.apache.openwebbeans</groupId>
<artifactId>openwebbeans-maven</artifactId>
<version>1.7.0</version>
</dependency>
</dependencies>
</plugin>
Extecuting this fat jar brings:
INFORMATION - OpenWebBeans Container is starting...
INFORMATION - Adding OpenWebBeansPlugin : [CdiPlugin]
SCHWERWIEGEND - CDI Beans module deployment failed
java.lang.NullPointerException
at org.apache.openejb.cdi.CdiScanner.handleBda(CdiScanner.java:271)
at org.apache.openejb.cdi.CdiScanner.init(CdiScanner.java:148)
at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:179)
at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:189)
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:913)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:717)
at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:342)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:56)
at com.github.rzo1.DemoMain.run(DemoMain.java:90)
at java.lang.Thread.run(Unknown Source)
INFORMATION - Closing DataSource: demoDS
INFORMATION - Closing DataSource: demoDSNonJTA
Exception in thread "Thread-0" java.lang.RuntimeException: org.apache.openejb.OpenEjbContainer$AssembleApplicationException: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at com.github.rzo1.DemoMain.run(DemoMain.java:116)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.openejb.OpenEjbContainer$AssembleApplicationException: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:346)
at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:56)
at com.github.rzo1.DemoMain.run(DemoMain.java:90)
... 1 more
Caused by: javax.enterprise.inject.spi.DeploymentException: couldn't start owb context
at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:191)
at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:41)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:913)
at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:717)
at org.apache.openejb.OpenEjbContainer$Provider.createEJBContainer(OpenEjbContainer.java:342)
... 3 more
Caused by: org.apache.openejb.OpenEJBRuntimeException: java.lang.NullPointerException
at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:200)
at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:189)
... 7 more
Caused by: java.lang.NullPointerException
at org.apache.openejb.cdi.CdiScanner.handleBda(CdiScanner.java:271)
at org.apache.openejb.cdi.CdiScanner.init(CdiScanner.java:148)
at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:179)
... 8 more
I added a branch with this changes on the GitHub Project for further investigation.
UPDATE 2
I excluded javax.xml.* from the shade:
<excludes>
<exclude>META-INF/faces-config.xml</exclude>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
<exclude>javax/xml/**</exclude>
</excludes>
However, the exception remains the same as in Update 1. I pushed a related branch to the GitHub repository.
So my question is:
What else needs to be excluded from the shade?
With the help of the other answers , I was finally able to find a working solution for building a standalone fat jar, which is working for my use-case.
UPDATE 3:
The steps (for now) are:
Usage of OpenWebBeansPropertiesTransformer instead AppendingTransformer as stated by P. Merkle
Exclude java.xml.* in the shade as stated by Romain Manni-Bucau:
<excludes>
<exclude>META-INF/faces-config.xml</exclude>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
<exclude>javax/xml/**</exclude>
Add a scan.xml in META-INF including only packages / classes, which should be scanned. Current working version can be found here
Question:
Is their an official or better way of doing this?
http://tomee.apache.org/advanced/shading/index.html and maybe http://tomee.apache.org/advanced/applicationcomposer/index.html are also good starting points.
Now it seems you scan unexpected classes like xml one where the classloader is null. Likely exclude javax.xml.* from scanning or even the shade and it will work
The exception is caused by merging multiple openwebbeans.properties files from different modules into a single properties file via AppendingTransformer.
This is because openwebbeans.properties files are structured in a special way:
All those files contain a single property configuration.ordinal which defines their 'importance'. Any setting from a property file with a higher configuration.ordinal will overwrite settings from one with a lower configuration.ordinal.
Now, if you naively merge these files--as AppendingTransformer does-- , you will end up with multiple competing ordinal properties in the same file.
The solution is to replace AppendingTransformer with OpenWebBeansPropertiesTransformer, which preserves priorities while merging.
An example pom.xml is available here: http://openwebbeans.apache.org/meecrowave/meecrowave-maven/index.html
Bad news is, however, that this solution uncovers another exception:
java.lang.NullPointerException at org.apache.openejb.cdi.CdiScanner.handleBda(CdiScanner.java:271)
So far I've not been able to identify the cause of that.
I'm trying to make my wsdl location not static anymore in my generated client (using the jaxws-maven-plugin), but I'm not having a lot of succes.
What I've found is the following..
My plugin (placed in the plugins in the build of the pom):
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxws-maven-plugin</artifactId>
<executions>
<execution>
<id>ecad-ws</id>
<phase>generate-sources</phase>
<goals>
<goal>wsimport</goal>
</goals>
<configuration>
<sourceDestDir>${basedir}/target/generated-sources</sourceDestDir>
<keep>true</keep>
<verbose>true</verbose>
<extension>true</extension>
<wsdlDirectory>src/main/resources</wsdlDirectory>
<wsdlFiles>
<wsdlFile>CBS.wsdl</wsdlFile>
</wsdlFiles>
<wsdlLocation>http://localhost/wsdl/msw/cbs?wsdl</wsdlLocation>
<catalog>
${basedir}/src/main/resources/META-INF/jax-ws-catalog.xml
</catalog>
</configuration>
</execution>
</executions>
</plugin>
and a jax-ws-catalog file (placed in src/main/resources/META-INF):
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="system">
<system
systemId="http://localhost/wsdl/msw/cbs?wsdl"
uri="../CBS.wsdl" />
</catalog>
the CBS.wsdl is placed in src/main/resouces. As far as I understand my research the above code changes the URL in the generated client to http://localhost/wsdl/msw/cbs?wsdl (that's working) and then, when the client is invoked, it looks for the catalog and matches the above url to ../CBS.wsdl. That last part isn't working since I'm getting the following exception:
Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:94)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:204)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:148)
... 118 more
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://localhost/wsdl/msw/cbs?wsdl'.: java.net.ConnectException: Connection refused: connect
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:244)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:191)
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:92)
... 120 more
Caused by: java.net.ConnectException: Connection refused: connect
I can't really find another solution. If I'm not changing the wsdl location in the generated client I'm always getting something like "Failed to access the WSDL at: file: XXXXX" (what is completely normal)
I'm using the jdk 7 btw..
This answer is about 6 years late, but...
I wandered onto this question as I was searching for how to setup the catalog file in my own repository .. in 2021 .. using Java 11. I managed to get it to work for my repo, and looking at this configuration above against mine, the only thing I could say is that you might need to add ${basedir} to the <wsdlDirectory> section.
...
<wsdlDirectory>${basedir}src/main/resources</wsdlDirectory>
...
I'm leaving this here for the next weary developer (like me) who has to implement a wsdl connection in the age of REST.
When I try to deploy or undeploy my application(EAR) in JBoss using Maven and Jenkins I get the following error :
INFO: JBoss Remoting version 3.2.12.GA
[DEBUG]
java.io.IOException: java.net.ConnectException: JBAS012144: Could not
connect to remote://192.168.1.8:10099. The connection timed out
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
...
My JBoss server is listening the port 10099 (9999+100) taking into account the following jboss configuration:
<socket-binding-group
name="standard-sockets"
default-interface="public"
port-offset="${jboss.socket.binding.port-offset:100}">
<socket-binding
name="management-native"
interface="management"
port="${jboss.management.native.port:9999}"/>
The Maven plugin configuration :
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.6.Final</version>
<inherited>true</inherited>
<configuration>
<!-- <skip>true</skip> -->
<hostname>${deploy.jboss.host}</hostname>
<port>${deploy.jboss.port}</port>
<username>${deploy.jboss.user}</username>
<password>${deploy.jboss.password}</password>
<filename>fitness-${stage}-${app.server}.ear</filename>
<name>fitness-${stage}-${app.server}.ear</name>
<skip>${skip.deployment}</skip>
<!-- Logging ??? not working-->
<execute-commands>
<commands>
<command>/subsystem=logging/file-handler=debug:add(level=DEBUG,autoflush=true,file={"relative-to"=>"jboss.server.log.dir", "path"=>"jenkins-deployment.log"})
</command>
<command>/subsystem=logging/logger=org.jboss.as:add(level=DEBUG,handlers=[debug])
</command>
</commands>
</execute-commands>
</configuration>
<executions>
<execution>
<id>deploy-application</id>
<goals>
<goal>deploy</goal>
</goals>
</execution>
<execution>
<id>undeploying-all-application</id>
<goals>
<goal>undeploy</goal>
</goals>
<configuration>
<match-pattern>fitness-.*</match-pattern>
<matchPatternStrategy>all</matchPatternStrategy>
</configuration>
</execution>
</executions>
</plugin>
With the following variables :
deploy.jboss.host = 192.168.1.8
deploy.jboss.port = 10099
Here is my configuration :
OS : Ubuntu 13.04
Java : 1.6.0_26
JBoss : 7.1.1.final
Maven : 3.0.3
Jboss-as-maven-plugin : 7.6.final
Jenkins and the target jboss server are running the same machine identified by the ip 192.168.1.8
My own diagnostic :
If I run
sudo netstat -nlp | grep :10099
I get :
tcp 0 0 0.0.0.0:10099 0.0.0.0:* LISTEN 25475/java
And 25475 is my Jboss instance. It seems that JBoss is listening behind the right port.
I can connect using another instance with CLI :
sh jboss-cli.sh controller=192.168.1.8:10099
Thanks in advance for your help
I had same problem and I solved it setting a higher timeout value.
For example:
<plugin>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.9.Final</version>
<inherited>true</inherited>
<configuration>
<hostname>${jboss.hostname}</hostname>
<port>${jboss.port}</port>
<username>${jboss.user}</username>
<password>${jboss.pass}</password>
....
<timeout>30000</timeout>
....
</configuration>
</plugin>
Default "timeout" value is 5000ms. You can try with a higher value like 30000ms. It worked for me.
Edited:
As Pedro said, another option can be passing "timeout" to maven via a command line argument. eg. -Djboss-as.timeout=30000
The problem was JDK 7 related. My jenkins server was using Java 1.7
If you want to use the jdk 7 you need to use the following parameter :
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider
I had the similar issue, however the fix was different, it might help somebody. I had to change maven plugin to the following one:
<plugin>
<groupId>org.wildfly.plugins</groupId>
<artifactId>wildfly-maven-plugin</artifactId>
<version>1.1.0.Alpha11</version>
</plugin>
I have a Java web service (made with a proprietary technology at my company), which is being used to service requests/responses, and while processing requests, it is attempting to talk to Hadoop's Hive and execute a query. However, it is failing immediately when I simply try to initialize the connection.
Here is the line of code it fails on. I am largely using the code sample from https://cwiki.apache.org/confluence/display/Hive/HiveClient:
String connString = "jdbc:hive://";
Connection con = DriverManager.getConnection(connString, "", "");
Here is the stack trace:
javax.jdo.JDOFatalInternalException: Unexpected exception caught.
at javax.jdo.JDOHelper.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1186)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:803)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:698)
at org.apache.hadoop.hive.metastore.ObjectStore.getPMF(ObjectStore.java:246)
at org.apache.hadoop.hive.metastore.ObjectStore.getPersistenceManager(ObjectStore.java:275)
at org.apache.hadoop.hive.metastore.ObjectStore.initialize(ObjectStore.java:208)
at org.apache.hadoop.hive.metastore.ObjectStore.setConf(ObjectStore.java:183)
at org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:70)
at org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:130)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getMS(HiveMetaStore.java:407)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.executeWithRetry(HiveMetaStore.java:359)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB(HiveMetaStore.java:504)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.init(HiveMetaStore.java:266)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.<init>(HiveMetaStore.java:228)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:131)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:121)
at org.apache.hadoop.hive.jdbc.HiveConnection.<init>(HiveConnection.java:76)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:104)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at (...my package...).RemoteCtrbTest.kickOffRemoteTest(RemoteCtrbTest.java:52)
NestedThrowablesStackTrace:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.jdo.JDOHelper$16.run(JDOHelper.java:1958)
at java.security.AccessController.doPrivileged(Native Method)
at javax.jdo.JDOHelper.invoke(JDOHelper.java:1953)
at javax.jdo.JDOHelper.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1159)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:803)
at javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:698)
at org.apache.hadoop.hive.metastore.ObjectStore.getPMF(ObjectStore.java:246)
at org.apache.hadoop.hive.metastore.ObjectStore.getPersistenceManager(ObjectStore.java:275)
at org.apache.hadoop.hive.metastore.ObjectStore.initialize(ObjectStore.java:208)
at org.apache.hadoop.hive.metastore.ObjectStore.setConf(ObjectStore.java:183)
at org.apache.hadoop.util.ReflectionUtils.setConf(ReflectionUtils.java:70)
at org.apache.hadoop.util.ReflectionUtils.newInstance(ReflectionUtils.java:130)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.getMS(HiveMetaStore.java:407)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.executeWithRetry(HiveMetaStore.java:359)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.createDefaultDB(HiveMetaStore.java:504)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.init(HiveMetaStore.java:266)
at org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.<init>(HiveMetaStore.java:228)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:131)
at org.apache.hadoop.hive.service.HiveServer$HiveServerHandler.<init>(HiveServer.java:121)
at org.apache.hadoop.hive.jdbc.HiveConnection.<init>(HiveConnection.java:76)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:104)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:185)
at (...my package...).RemoteCtrbTest.kickOffRemoteTest(RemoteCtrbTest.java:52)
Caused by: org.datanucleus.exceptions.NucleusUserException: Persistence process has been specified to use a ClassLoaderResolver of name "jdo" yet this has not been found by the DataNucleus plugin mechanism. Please check your CLASSPATH and plugin specification.
at org.datanucleus.OMFContext.getClassLoaderResolver(OMFContext.java:319)
at org.datanucleus.OMFContext.<init>(OMFContext.java:165)
at org.datanucleus.OMFContext.<init>(OMFContext.java:137)
at org.datanucleus.ObjectManagerFactoryImpl.initialiseOMFContext(ObjectManagerFactoryImpl.java:132)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.initialiseProperties(JDOPersistenceManagerFactory.java:363)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.<init>(JDOPersistenceManagerFactory.java:307)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.createPersistenceManagerFactory(JDOPersistenceManagerFactory.java:255)
at org.datanucleus.jdo.JDOPersistenceManagerFactory.getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:182)
... 35 more
I found one other question that has a similar error message, but it was about Maven and didn't contain Hive (which is the one using DataNucleus in it's code): Datanucleus, JDO and executable jar - how to do it?
I am using a hive-site.xml file to specify some properties for hive and datanucleus. The datanucleus ones are below. The last two I tried to try to fix the issue and when I change whatever I specify for datanucleus.classLoaderResolverName, it changes the error message that is in quotes.
<property>
<name>datanucleus.autoCreateSchema</name>
<value>false</value>
</property>
<property>
<name>datanucleus.fixedDatastore</name>
<value>true</value>
</property>
<property>
<name>datanucleus.classLoaderResolverName</name>
<value>jdo</value>
</property>
<property>
<name>javax.jdo.PersistenceManagerFactoryClass</name>
<value>org.datanucleus.jdo.JDOPersistenceManagerFactory</value>
</property>
The part that I cannot figure out is if somehow the service is re-bundling the jars, as in the other stackoverflow question that I linked to above, messing up the location of plugin.xml and/or the Manifest.mf file. I'm also not sure how the plugin file interacts with the hive-site file.
The classpath here requires to add specific jars instead of just a classpath. I am using the following datanucleus jars:
* datanucleus-connectionpool-2.0.3.jar
* datanucleus-enhancer-2.0.3.jar
* datanucelus-rdbms-2.0.3.jar
* datanucleus-core-2.0.3.jar
Any input you can give to help me would be greatly appreciated. I can provide more information if you need it so please do ask.
In case you are using Spring framework in your application made with proprietary technology at your company, then you can take advantage of Spring-Hadoop support.
All you have to do is just add below configuration in your applicationContext:
<hdp:configuration>
fs.default.name=${fs.default.name.url}
mapred.job.tracker=${mapred.job.tracker.url}
</hdp:configuration>
<hdp:hive-client-factory host="${hadoop.hive.host.url}" port="10000"
xmlns="http://www.springframework.org/schema/hadoop" />
<hdp:hive-template />
After that, autowire HiveTemplate,
#Autowired
HiveTemplate hiveTemplate;
And then query Hive as shown below:
List<String> list = hiveTemplate.query(queryString, parameterMap);
DataNucleus apparently uses an OSGi-based plugin mechanism. If you are not running it in an OSGi container and are just using a standard maven project, what's probably happening is the plugins are on the classpath but are not registered due to an issue with manifests. You might try something like this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/jars</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>false</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
This was answered previously.