How to override 'org.apache.cxf.stax.maxChildElements' property value inside a TomEE container? - xml-parsing

I've got a JAX-WS web service endpoint configured purely via annotations running in TomEE 7 environment. Basically, the method being called has to return a List<String> of all node names contained in a graph data structure. The response of such a request can contain more thank 50k elements.
With CXF 2.6.x this worked fine. However, when I call the WS-method under CXF 3.x (bundled in TomEE 7.x), the following exception is thrown on the server side:
org.apache.cxf.interceptor.Fault: Unmarshalling Error: Maximum Number of Child Elements limit (50000) Exceeded
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:906)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:712)
at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:179)
at org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:801)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1680)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1559)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:653)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:514)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:423)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:324)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:277)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:139)
at com.sun.proxy.$Proxy51.getAllNodeNames(Unknown Source)
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[javax.xml.stream.XMLStreamException: Maximum Number of Child Elements limit (50000) Exceeded]
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:485)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:417)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:394)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.doUnmarshal(JAXBEncoderDecoder.java:855)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.access$100(JAXBEncoderDecoder.java:102)
at org.apache.cxf.jaxb.JAXBEncoderDecoder$2.run(JAXBEncoderDecoder.java:894)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:892)
... 21 more
Caused by: javax.xml.stream.XMLStreamException: Maximum Number of Child Elements limit (50000) Exceeded
at com.ctc.wstx.sr.InputElementStack.push(InputElementStack.java:340)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2951)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2839)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1073)
at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:196)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:415)
... 27 more
Error: Maximum Number of Child Elements limit (50000) Exceeded
So far, I've read the official CXF documentation on this issue, checked a HowTo at the TomEE website and read many related, yet older posts in forums.
I tried to set the properties - as advised by the TomEE documentation - via openejb-jar.xml in the webservice's WEB-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar>
<ejb-deployment ejb-name="MyWebService">
<properties>
org.apache.cxf.stax.maxChildElements = 100000
</properties>
</ejb-deployment>
</openejb-jar>
I also tried with the shorter property cxf.stax.maxChildElements to check whether this would be accepted, yet without success.
For testing/debugging, I start the TomEE instance via the tomee-maven-plugin, Therefore, I tried the set the maxChildElement property as an environment property like so:
<plugin>
<groupId>org.apache.tomee.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>${tomee.plugin.version}</version>
<configuration>
<tomeeVersion>${tomee.version}</tomeeVersion>
<tomeeClassifier>plus</tomeeClassifier>
<debug>false</debug>
<tomeeHttpPort>8181</tomeeHttpPort>
<debugPort>5005</debugPort>
<args>-Dfoo=bar</args>
<skipCurrentProject>true</skipCurrentProject>
<webapps>
<webapp>my.ws:${webservice.artifact.name}:${webservice.artifact.version}?name=ws-endpoint</webapp>
</webapps>
<libs>
<!-- Third party libraries needed in the global lib folder of TomEE -->
<lib>log4j:log4j:${log4j.version}</lib>
</libs>
<systemVariables>
<!--
special property needed to allow for more childElements in StAX Parser
-->
<org.apache.cxf.stax.maxChildElement>100000</org.apache.cxf.stax.maxChildElement>
</systemVariables>
</configuration>
</plugin>
Sadly, it has no effect on the runtime configuration of CXF/StAX (Woodstox).
Question
How can we override the maxChildElements property via a configuration in openejb-jar.xml or as an external property at TomEE startup.

Finally, I got it working with the help of Romain Manni-Bucau (credits to him for pointing me into the right direction). Yet, his original answer is not the final solution. Therefore, I give the working configuration here.
1.) Put the following openejb-jar.xml to the WEB-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar>
<ejb-deployment ejb-name="MyWebService">
<properties>
cxf.jaxws.properties = cxfConfig
</properties>
</ejb-deployment>
</openejb-jar>
2.) Provide a new (or add to an existing) resources.xml file, again via WEB-INF:
<?xml version="1.0" encoding="UTF-8"?>
<resources>
<Service id="cxfConfig" class-name="org.apache.openejb.config.sys.MapFactory" factory-name="create">
org.apache.cxf.stax.maxChildElements = 100000
</Service>
</resources>
Note well the configuration link via the MapFactory object with the id cxfConfig.
3.) Configure JAX-WS clients to set corresponding property as well. For instance, given a Spring client, this can be configured like so:
<bean id="wsClientProxy" class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean">
<property name="serviceClass" value="com.acme.ws.jaxb.MyWebservice"/>
<property name="address" value="${ws.endpoint.url}"/>
<property name="properties">
<map>
<entry key="org.apache.cxf.stax.maxChildElements" value="100000" />
</map>
</property>
</bean>
In general, this might also be useful for people trying to set other CXF-related properties as listed in the XML section of the CXF security guideline, in particular to increase or decrease conservative default values.
I tested the above configuration steps successfully under a TomEE 7.0.3 and 8.0.9 environment, yet this should also reliably work with all 7.0.x and 8.0.x releases.
For other use cases, this blog post by Romain might also be worth reading, as it covers basic configuration concepts quite well.
Hope this helps others.

You can try
-Dorg.apache.cxf.stax.maxChildElements=100000
It should also work

I think you need to define a resources.xml with a Service of type (class-name) java.util.Properties and the properties inside:
openejb-jar.xml would get this property:
cxf.jaxws.properties = cxfConfig
resources.xml would get
org.apache.cxf.stax.maxChildElements = 1
This test does it programmatically: https://github.com/apache/tomee/blob/master/server/openejb-cxf/src/test/java/org/apache/openejb/server/cxf/MaxChildTest.java

Related

How to add logs in RHPAM DMN?

I need help in RHPAM Business Central.
Anybody knows how to add any print statements or logs in DMN's for debugging DMN flow?
You can define your own DMNRuntimeEventListener.
The listener is usually wired in Drools library using: https://docs.drools.org/8.33.0.Final/drools-docs/docs-website/drools/DMN/index.html#dmn-properties-ref_dmn-models:~:text=org.kie.dmn.runtime.listeners.%24LISTENER_NAME
e.g.: with a configuration such as:
-Dorg.kie.dmn.runtime.listeners.mylistener=org.acme.MyDMNListener
or alternatively with analogous configuration in kmodule.xml
<kmodule xmlns="http://www.drools.org/xsd/kmodule">
<configuration>
<property key="org.kie.dmn.runtime.listeners.mylistener" value="org.acme.MyDMNListener"/>
</configuration>
</kmodule>
This latter option, is the one you might preference on RHPAM Business Central.
You might find helpful this tutorial: https://www.youtube.com/watch?v=WzstCC3Df0Q

Error starting Hazelcast in kubernetes

I am trying to start Hazelcast in a Kubernetes/Docker cluster.
After some digging on the web, I found that someone has already thought about this.
Currently I am trying to use kubernetes-hazelcast lib
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-kubernetes</artifactId>
<version>1.0.0</version>
</dependency>
Here is my hazelcast config:
<?xml version="1.0" encoding="UTF-8"?>
<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.9.xsd"
xmlns="http://www.hazelcast.com/schema/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<group>
<name>GROUP_NAME</name>
<password>GROUP_NAME_PASSWORD</password>
</group>
<network>
<port auto-increment="true">5701</port>
<join>
<multicast enabled="false">
<multicast-group>224.2.2.3</multicast-group>
<multicast-port>54327</multicast-port>
</multicast>
<!-- <tcp-ip enabled="false">
<interface>127.0.0.1</interface>
</tcp-ip>-->
<!-- activate the Kubernetes plugin -->
<discovery-strategies>
<discovery-strategy enabled="true" class="com.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategy">
<properties>
<!-- configure discovery service API lookup -->
<property name="service-name">service-name</property>
<property name="service-label-name">label-name</property>
<property name="service-label-value">true</property>
<property name="namespace">default</property>
</properties>
</discovery-strategy>
</discovery-strategies>
</join>
<interfaces enabled="false">
<interface>10.10.1.*</interface>
</interfaces>
<!-- <symmetric-encryption enabled="true">
encryption algorithm such as
DES/ECB/PKCS5Padding,
PBEWithMD5AndDES,
AES/CBC/PKCS5Padding,
Blowfish,
DESede
<algorithm>PBEWithMD5AndDES</algorithm>
salt value to use when generating the secret key
<salt>4oItUqH</salt>
pass phrase to use when generating the secret key
<password>gctuSBc5bKZrSwXk+</password>
iteration count to use when generating the secret key
<iteration-count>19</iteration-count>
</symmetric-encryption> -->
</network>
<executor-service>
<pool-size>16</pool-size>
<!-- <max-pool-size>64</max-pool-size>-->
<queue-capacity>64</queue-capacity>
<statistics-enabled>true</statistics-enabled>
<!-- <keep-alive-seconds>60</keep-alive-seconds>-->
</executor-service>
<queue name="default">
<!--
Maximum size of the queue. When a JVM's local queue size reaches the maximum,
all put/offer operations will get blocked until the queue size
of the JVM goes down below the maximum.
Any integer between 0 and Integer.MAX_VALUE. 0 means
Integer.MAX_VALUE. Default is 0.
-->
<max-size>0</max-size>
<!--
Maximum number of seconds for each item to stay in the queue. Items that are
not consumed in <time-to-live-seconds> will automatically
get evicted from the queue.
Any integer between 0 and Integer.MAX_VALUE. 0 means
infinite. Default is 0.
-->
<!-- <time-to-live-seconds>0</time-to-live-seconds>-->
</queue>
<map name="default">
<!--
Number of backups. If 1 is set as the backup-count for example,
then all entries of the map will be copied to another JVM for
fail-safety. Valid numbers are 0 (no backup), 1, 2, 3.
-->
<backup-count>4</backup-count>
<!--
Valid values are:
NONE (no eviction),
LRU (Least Recently Used),
LFU (Least Frequently Used).
NONE is the default.
-->
<eviction-policy>NONE</eviction-policy>
<!--
Maximum size of the map. When max size is reached,
map is evicted based on the policy defined.
Any integer between 0 and Integer.MAX_VALUE. 0 means
Integer.MAX_VALUE. Default is 0.
-->
<max-size>0</max-size>
<!--
When max. size is reached, specified percentage of
the map will be evicted. Any integer between 0 and 100.
If 25 is set for example, 25% of the entries will
get evicted.
-->
<eviction-percentage>25</eviction-percentage>
<!--
While recovering from split-brain (network partitioning),
map entries in the small cluster will merge into the bigger cluster
based on the policy set here. When an entry merge into the
cluster, there might an existing entry with the same key already.
Values of these entries might be different for that same key.
Which value should be set for the key? Conflict is resolved by
the policy set here. Default policy is hz.ADD_NEW_ENTRY
There are built-in merge policies such as
hz.NO_MERGE ; no entry will merge.
hz.ADD_NEW_ENTRY ; entry will be added if the merging entry's key
doesn't exist in the cluster.
hz.HIGHER_HITS ; entry with the higher hits wins.
hz.LATEST_UPDATE ; entry with the latest update wins.
-->
<merge-policy>hz.ADD_NEW_ENTRY</merge-policy>
</map>
<!-- Add your own map merge policy implementations here:
<merge-policies><map-merge-policy name="MY_MERGE_POLICY"><class-name>com.acme.MyOwnMergePolicy</class-name></map-merge-policy></merge-policies>
-->
</hazelcast>
After trying to start the program the hazelcast isn´t starting and it is raising an exception
2017-10-25 15:44:34,849 INFO [main] DiscoveryService:65 - [192.168.1.83]:5701 [dev] [3.9] Kubernetes Discovery: Bearer Token { null }
2017-10-25 15:44:34,888 ERROR [main] Launcher:97 - Unable to start EventEngineManager
java.lang.RuntimeException: Failed to configure discovery strategies
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.loadDiscoveryStrategies(DefaultDiscoveryService.java:153)
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.<init>(DefaultDiscoveryService.java:60)
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryServiceProvider.newDiscoveryService(DefaultDiscoveryServiceProvider.java:29)
at com.hazelcast.instance.Node.createDiscoveryService(Node.java:265)
at com.hazelcast.instance.Node.<init>(Node.java:220)
at com.hazelcast.instance.HazelcastInstanceImpl.createNode(HazelcastInstanceImpl.java:160)
at com.hazelcast.instance.HazelcastInstanceImpl.<init>(HazelcastInstanceImpl.java:128)
at com.hazelcast.instance.HazelcastInstanceFactory.constructHazelcastInstance(HazelcastInstanceFactory.java:195)
at com.hazelcast.instance.HazelcastInstanceFactory.newHazelcastInstance(HazelcastInstanceFactory.java:174)
at com.hazelcast.instance.HazelcastInstanceFactory.newHazelcastInstance(HazelcastInstanceFactory.java:124)
at com.hazelcast.core.Hazelcast.newHazelcastInstance(Hazelcast.java:58)
at com.nsn.monitor.eva.eem.engine.state.EventEngineManagerContext.startup(EventEngineManagerContext.java:131)
at com.nsn.monitor.eva.eem.EventEngineManager.init(EventEngineManager.java:59)
at com.nsn.monitor.eva.eem.Launcher.initialize(Launcher.java:74)
at com.nsn.monitor.eva.eem.Launcher.main(Launcher.java:57)
Caused by: io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred.
at io.fabric8.kubernetes.client.KubernetesClientException.launderThrowable(KubernetesClientException.java:53)
at io.fabric8.kubernetes.client.utils.HttpClientUtils.createHttpClient(HttpClientUtils.java:144)
at io.fabric8.kubernetes.client.BaseClient.<init>(BaseClient.java:41)
at io.fabric8.kubernetes.client.DefaultKubernetesClient.<init>(DefaultKubernetesClient.java:90)
at com.hazelcast.kubernetes.ServiceEndpointResolver.buildKubernetesClient(ServiceEndpointResolver.java:74)
at com.hazelcast.kubernetes.ServiceEndpointResolver.<init>(ServiceEndpointResolver.java:64)
at com.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategy.<init>(HazelcastKubernetesDiscoveryStrategy.java:75)
at com.hazelcast.kubernetes.HazelcastKubernetesDiscoveryStrategyFactory.newDiscoveryStrategy(HazelcastKubernetesDiscoveryStrategyFactory.java:56)
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.buildDiscoveryStrategy(DefaultDiscoveryService.java:185)
at com.hazelcast.spi.discovery.impl.DefaultDiscoveryService.loadDiscoveryStrategies(DefaultDiscoveryService.java:145)
... 14 more
Caused by: java.security.cert.CertificateParsingException: no more data allowed for version 1 certificate
at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:672)
at sun.security.x509.X509CertInfo.<init>(X509CertInfo.java:167)
at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1804)
at sun.security.x509.X509CertImpl.<init>(X509CertImpl.java:195)
at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:102)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at io.fabric8.kubernetes.client.internal.CertUtils.createTrustStore(CertUtils.java:68)
at io.fabric8.kubernetes.client.internal.CertUtils.createTrustStore(CertUtils.java:62)
at io.fabric8.kubernetes.client.internal.SSLUtils.trustManagers(SSLUtils.java:110)
at io.fabric8.kubernetes.client.internal.SSLUtils.trustManagers(SSLUtils.java:104)
at io.fabric8.kubernetes.client.utils.HttpClientUtils.createHttpClient(HttpClientUtils.java:68)
Since I don´t know where to point, could someone give me some guidance?
I don´t know if this a problem with the certificate in the docker, problem with my hazelcast config?
Since I am no expert on this, I am totally lost.
Basically it was a problem with certificate of the docker. Changed it and everything worked as it should

"Can not initialize the default wsdl from..." -- Why?

My pom.xml contains the following to auto generate a client for a working web service having the WSDL specified below:
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>generate-sources</id>
<configuration>
<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/src/main/wsdl/myclient.wsdl</wsdl>
<extraargs>
<extraarg>-client</extraarg>
<extraarg>-verbose</extraarg>
</extraargs>
<wsdlLocation>wsdl/myclient.wsdl</wsdlLocation>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
The project builds fine, without any errors or warnings and I can see the the file myclient.wsdl in the JAR file right under a wsdl folder.
But when I try running that JAR:
java -Xmx1028m -jar myclient-jar-with-dependencies.jar
It complains that "Can not initialize the default wsdl from wsdl/myclient.wsdl"
Why?
What am I missing?
How can I find out what path that wsdl/myclient.wsdl in pom.xml translates into, that makes the client's JAR complain at run time?
Update: I am aware of some solutions/workarounds that involve modifying the auto-generated code:
Pass "null" for the wsdl URL and then use the ((BindingProvider)port).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://example.com/....") to set the address.
load the WSDL as a Java resource and pass its location into your service's constructor.
But I am more interested in a solution that requires entering the right values into the pom.xml like the classpath approach (but unfortunately classpath didn't work for me for some reason).
Any ideas what I should be typing there instead? Apparently this is a very simply case of figuring out the correct path rules for that particular plugin, but I am missing something and I don't know what it is.
The error comes from the static initializer of your generated service class (which is annotated by #WebServiceClient). It tries to load the wsdl file as resource. The generator uses the value which you have provided by the parameter wsdlLocation. You should leave away the "wsdl/" prefix:
<wsdlLocation>myclient.wsdl</wsdlLocation>
because the wsdl is located directly in the root of the classpath folder.
BTW: If you omit the parameter <wsdlLocation> the value of the param <wsdl> is used (which is not correct at runtime in your case, but would be correct if the provided URL would be a remote URL address, i.e. directly fetched from the webservice server).
BTW2: Your workaround 2 is in fact +/- what the generated code of the service class does if you use the parameterless constructor.
I notice the cfx examples use slightly different locations for sourceRoot, wsdl and wsdlLocation.
Remember that typically, files in src/main/resources are included in the produced artifact. In order for files in src/main/wsdl to be included, it needs to be added as a resource in the pom.xml:
<resources>
<resource>
<directory>src/main/wsdl</directory>
</resource>
</resources>
Tips:
Set the paths you suspect to known bad paths and see if you get the same error-message.
Unzip the produced *.jar-file(s) and check if the wsdl is included, and what the path is.

Migrate EAP5 to JBoss7 - remote invocation error

Hi this is my scenario,
I am trying to migrate an app from JBoss5 to JBoss7.
I am using jboss-as-7.1.1.Final.
The error I am getting is:
No EJB receiver available for handling [appName:,modulename:myapp-ejb,distinctname:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext#6b9bb4bb
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:584) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:119) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
I have looked at several discussions with the same error message but I just cant figure out what I am doing wrong.
In the deployments directory I have only one myapp.war. I do not deploy a .ear file. I have a dependency (myapp-ejb.jar) deployed as a module.
I have followed the instructions from https://docs.jboss.org/author/display/AS71/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 in section "Migrate EAP 5 Deployed Applications That Make Remote Invocations to AS 7".
SERVER
In the myapp-ejb.jar I have a bunch of JNDI names like:
public static final String ACCOUNT_REMOTE = "ejb:/myapp-ejb//AccountBean!com.company.myapp.ejb.account.AccountRemote";
The lookup is done from the client by invoking this static method which is defined in myapp-ejb.jar:
public static AccountRemote getAccountRemote() throws NamingException {
if (accountRemote == null){
InitialContext ic = new InitialContext();
Object ref = ic.lookup(JNDINames.ACCOUNT_REMOTE);
accountRemote = (AccountRemote) PortableRemoteObject.narrow(ref, AccountRemote.class);
}
return accountRemote;
}
All remote interfaces are for stateless EJB like:
#Stateless
#Remote(AccountRemote.class)
public class AccountBean implements AccountRemote {
CLIENT
From the myapp.war I make a remote invocation to the myapp-ejb.jar using the above static method getAccountRemote().
In the myapp.war/WEB-INF directory I have added a jndi.properties and a jboss-ejb-client.properties.
The jndi.properties contains only one value:
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
The jboss-ejb-client.properties contains:
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
I have removed the security realm on remoting from the standalone.xml:
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting" />
</subsystem>
I have added the JBOSS_HOME/bin/client/jboss-client.jar to the myapp.war/WEB-INF/lib.
The application deploys successfully without any errors but when I launch localhost:8080/ I get the No EJB receiver available for handling error.
Does anyone knows what I have missed? Any suggestions?
"EJB client API approach" for remote EJB invocation from one node to another node in clustered JBOSS:
------------------------------------------------------------------------------------
1. To call EJB from remote location we need to enable "remoting-ejb-receiver" on server side.
Please refer to “standalone_changes.xml” to know change details.
2. Also we need to register the "remoting-ejb-receiver" to the application, so that the application can receive remote EJB.
Please refer to “jboss-ejb-client.xml” section.
3. Now we need to call remote EJB in "EJB client API approach" way, which needs to have JNDI name pattern as:
ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fullclassname-of-the-remote-interface>
In our case it will be: ejb:myapp-ejb//node1/AccountBean!com.company.myapp.ejb.account.AccountRemote
Important to note that identification to remote location IP address is not based on InitialContext as InitialContext will not contain any IP address as normally happens with "remote://URL:Port".
The remote location identification is based on <distinct-name> passed in JNDI. JBOSS will internally identify the remote IP based on <distinct-name>.
Hence is required to provide unique <distinct-name> to the application running on different nodes.
Add "<distinct-name>${jboss.node.name}</distinct-name>" to “jboss-app.xml”. Make sure that jboss.node.name property is always unique.
But then jboss.node.name should be added as environmental property while server startup.
For test purpose we can provide hardcoded value like:
For node1: "<distinct-name>node1</distinct-name>" to “jboss-app.xml”.
For node2: "<distinct-name>node2</distinct-name>" to “jboss-app.xml”.
standalone_changes.xml:
------------------------------------------------------------------------------------
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<outbound-connections>
<remote-outbound-connection name="remote-ejb-connection-host2" outbound-socket-binding-ref="remote-ejb-host2" username="xxx" security-realm="ejb-security-realm">
<properties>
<property name="SASL_POLICY_NOANONYMOUS" value="false"/>
<property name="SSL_ENABLED" value="false"/>
</properties>
</remote-outbound-connection>
...........
...........
</outbound-connections>
</subsystem>
...........
...........
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<outbound-socket-binding name="remote-ejb-host2">
<remote-destination host="${jboss.ejb.host2}" port="${jboss.ejb.host2.port}"/>
</outbound-socket-binding>
...........
...........
</socket-binding-group>
...........
...........
<management>
<security-realms>
<security-realm name="ejb-security-realm">
<server-identities>
<secret value="${jboss.ejb.remoting.password}"/>
</server-identities>
</security-realm>
...........
...........
</security-realms>
</management>
jboss-app.xml:
------------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<jboss-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee">
<distinct-name>node1</distinct-name>
<security-domain>xyz</security-domain>
<unauthenticated-principal>guest</unauthenticated-principal>
<library-directory>lib</library-directory>
</jboss-app>
jboss-ejb-client.xml
------------------------------------------------------------------------------------
<jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
<client-context>
<ejb-receivers>
<remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-host2"/>
<!-- <remoting-ejb-receiver outbound-connection-ref="${jboss.remote.outbound.connection.host3}"/> -->
</ejb-receivers>
</client-context>
</jboss-ejb-client>
For more details refer to:
"https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project" which tells us different way of remote EJB location.
You don't actually require jboss-client.jar if you are using JBOSS as your App server. Please add the following property to your initialContext or jndi.propeties file everything would be fine.
jboss.naming.client.ejb.context=true
also please remove the property unless you are calling from a standalone client or server other than Jboss.
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
Try with these settings.

How do I set up a wicket quickstart to use seam-wicket CDI?

What do I need to do to make CDI work on my wicket quickstart project? When I try to launch the Jetty server, I get an exception:
org.jboss.seam.solder.beanManager.BeanManagerUnavailableException: Failed to locate BeanManager using any of these providers: org.jboss.seam.solder.beanManager.DefaultJndiBeanManagerProvider(11), org.jboss.seam.solder.beanManager.ServletContainerJndiBeanManagerProvider(10)
at org.jboss.seam.solder.beanManager.BeanManagerLocator.getBeanManager(BeanManagerLocator.java:91)
at org.jboss.seam.wicket.SeamApplication.internalInit(SeamApplication.java:54)
at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:723)
...
I am authoring a wicket project. I don't know the first thing about Seam, Weld, or CDI; I want to learn it by incorporating it into a small project. I am following this reference documentation:
http://docs.jboss.org/seam/3/wicket/latest/reference/en-US/html_single/
Right now, I am swimming in a sea of alien documentation trying to find the answer. Help!
Edit:
The Jetty server in the wicket quickstart is created programmatically. Based on the documentation given below, I created:
webapp/WEB-INF/jetty-env.xml:
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN"
"http://jetty.mortbay.org/configure.dtd">
<Configure id="webAppCtx" class="org.mortbay.jetty.webapp.WebAppContext">
<New id="BeanManager" class="org.mortbay.jetty.plus.naming.Resource">
<Arg><Ref id="webAppCtx"/></Arg>
<Arg>BeanManager</Arg>
<Arg>
<New class="javax.naming.Reference">
<Arg>javax.enterprise.inject.spi.BeanManager</Arg>
<Arg>org.jboss.weld.resources.ManagerObjectFactory</Arg>
<Arg/>
</New>
</Arg>
</New>
</Configure>
In web.xml, I have added the following snippet:
<resource-env-ref>
<resource-env-ref-name>BeanManager</resource-env-ref-name>
<resource-env-ref-type>
javax.enterprise.inject.spi.BeanManager
</resource-env-ref-type>
</resource-env-ref>
<listener>
<listener-class>org.jboss.seam.solder.resourceLoader.servlet.ResourceListener</listener-class>
</listener>
The following Java code is responsible for setting up the Jetty server in the quickstart environment, when Start is run:
Server server = new Server();
SocketConnector connector = new SocketConnector();
// Set some timeout options to make debugging easier.
connector.setMaxIdleTime(1000 * 60 * 60);
connector.setSoLingerTime(-1);
connector.setPort(8080);
server.setConnectors(new Connector[] { connector });
WebAppContext bb = new WebAppContext();
bb.setServer(server);
bb.setContextPath("/");
bb.setWar("src/main/webapp");
// FIXME: This doesn't seem to do anything? bb.addEventListener(new ResourceListener());
server.addHandler(bb);
/* I don't know what this commented code does, but it doesn't fix the problem when uncommented. */
// START JMX SERVER
// MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
// MBeanContainer mBeanContainer = new MBeanContainer(mBeanServer);
// server.getContainer().addEventListener(mBeanContainer);
// mBeanContainer.start();
I am using jetty version 6.1.25, according to my Maven Dependencies.
The 42Lines folks have published a Wicket-CDI integration library that includes a working example project.
Several of these guys are actually Wicket committers; they write good code, and they know what they're doing.
In a servlet container you need to bootstrap Weld CDI yourself to make it available to Seam. The documentation states this under installation:
http://docs.jboss.org/seam/3/wicket/latest/reference/en-US/html_single/#wicket.installation
With a link to the relative Weld bootstrapping documentation for either Jetty 6 or 7:
http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5286
It should work fine after configuring Jetty to bootstrap Weld. However please take not of the limitations of using Weld within a servlet container:
http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#d0e5221
Also ensure that you have an empty (or configured) beans.xml in your WEB-INF/ directory.

Resources