How do you enable MOxy on WebSphere Liberty without breaking Glassfish? - glassfish

Is there a way of creating an application using MOXy on WebSphere Liberty which uses Jackson and does not support JAXB by default for their JAX-RS implementation without breaking Glassfish or creating a separate build for WebSphere Liberty?

Related

Apache Ignite with Spring framework

Does the Apache Ignite operate on a spring framework basis?
Can I register a spring controller in classpath at server remote node and use it?(using component , like #Controller)
Apache Ignite is integrated with Spring but isn't based on it.
You can register spring beans when starting remote node (using normal spring approach) and then use them from e.g. compute or distributed services.
I'm not sure if you can register beans remotely in runtime, but I don't see why not.

Database persistence based JMS messaging in Jboss EAP 7.0

I am trying to configure JDBC database based persistence for JMS messaging in JBoss Version 7.0.6.GA.
When I look at JBoss 7.0 docs - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuring_messaging/configuring_persistence, I don't see any documentation about "Messaging Journal Persistence Using a JDBC Database".
But when I look at JBoss 7.1 docs - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/configuring_persistence#messaging_journal_persistence_using_a_jdbc_database, it does details about "Messaging Journal Persistence Using a JDBC Database".
Do that mean JBoss 7.0 EAP doesn't support database persistence based JMS messaging? Do I need to migrate to JBoss 7.1 to achieve this?
Looking at JBoss 7.1 release notes, I can conclude that we can use JDBC to persist JMS messages only after JBoss 7.1.x and above. This feature is not supported in JBoss 7.0 EAP.

Hazelcast ClassCastException when deploying a mule application that uses Hazelcast in mule 3.6.2 ee

I'm trying to deploy a Mule application which uses Hazelcast to cache the result of some methods that are frequently used. However, while deploying the application I got the following error:
java.lang.ClassCastException: Cannot cast com.hazelcast.client.txn.ClientTxnPortableHook to com.hazelcast.nio.serialization.PortableHook
at java.lang.Class.cast(Class.java:3176) ~[?:1.7.0_79]
at com.hazelcast.util.ServiceLoader$1.next(ServiceLoader.java:97) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.load(PortableHookLoader.java:48) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.(PortableHookLoader.java:41) ~[hazelcast-3.1.6.jar:3.1.6]
I've tried to use the loader override function by placing the next setting in mule-deploy.properties:
loader.override=-com.hazelcast
The Mule application uses Hazelcast 3.5, and Mule 3.6.2 EE uses Hazelcast 3.1.6. Can you tell me a possible solution?
I have reviewed the link provided by Enrique (ClassCastException when casting to the same class) and it was useful because there were two different classpaths, but there were other aspects to be considered in the solution of the problem:
The Hazelcast versions were different. The Mule application used Hazelcast 3.5, and Mule 3.6.2 EE used Hazelcast 3.1.6.
There was not log configuration for Hazelcast in the mule server.
Because I really need to use the Hazelcast 3.5, it was not a choice to downgrade the Hazelcast to 3.1.6. So, I had to replace the version of the Hazelcast in the mule server to 3.5 and remove this library from the Mule application. And then I had to made a lot of tests to discard possible incompatibility issues. The tests were successful.
For the log configuration for Hazelcast in the mule server, I had to add the next JVM parameter to the mule server wrapper:
wrapper.java.additional.44=-Dhazelcast.logging.type=log4j
I used "log4j" because I was using Log4j2. You can see more information about this configuration in the next link:
http://docs.hazelcast.org/docs/3.5/manual/html/logging.html

Can't get cxf and cxf-client to work at the same time grails

I have a problem when I use both cxf and cxf-client together.
The cxf says that it can't find any services.
When I comment the configuration for the cxf-client the cxf finds the services.
The configuration for the servlet is the standard configuration.
The configuration for the client made from EU TIN service.
The two plugins works find seperately but not together.
Have anyone find a solution for this problem ?
Using grails version 2.3.7
Cxf version 1.1.4
cxf-client 1.6.1
I managed to get around the same problem by modifying CXF client plugin a bit. In WebServiceClientFactoryImpl modify creating JaxWSProxyFactoryBean as follows:
Bus bus = Holders.grailsApplication.mainContext.getBean("cxf") as Bus
JaxWsProxyFactoryBean clientProxyFactory = new JaxWsProxyFactoryBean(serviceClass: serviceInterface,
address: serviceEndpointAddress, bus: bus)
CXF plugin creates that 'cxf' bean which is of type org.apache.cxf.bus.spring.SpringBus. CXF client creates (by default) another bus which seems to break CXF web service. By using the same bus in CXF client the problem was solved.

Jboss Mbeans visible in jmx-console but not in JConsole

JBoss(4.0.x) has many useful MBeans (org.apache.commons.modeler.*) that are visible in:
/jmx-console
But i cannot see these beans listed in JConsole (MBeans tab).
Are these beans not exposed to outside world?
JBoss 4.x has its own internal MBean server, separate from the default JVM one (JBoss AS 4.x pre-dates Java 5 and its MBean server, so needed its own).
I believe that in JBoss AS 5.x you can tell it to use the JVM's MBean server, but I don't think JBoss AS 4.x provides that option.
Are these beans not exposed to outside world?
Yes they are - JBoss AS's internal MBean server is just as exposed as the JVM's one, it's just exposed differently. JConsole talks to the JVM's MBean server, you need different tools to talk to the JBoss AS one.
P.S. JBoss AS 4.0 is eye-poppingly old (2004? 2005?). You really should update it.