we are trying to do the assessment around ActiveMQ to use in OSB 12c as JMS based integration. I did follow few blogs like https://bizzperform.com/blog/?p=686 but this is not helping and generating error like below.
did anyone came across this scenario and did implemented same .. kinldy advise.
<Failed to check whether connection factory LocalConnectionFactory supports XA. Will assume it does not: javax.naming.NoInitialContextException: Cannot instantiate class: org.apache.activemq.jndi.ActiveMQInitialContextFactory [Root exception is java.lang.ClassNotFoundException:
Active MQ client jar is missing from domain class path, you need to download it and add to PRE_CLASSPATH
Thanks, I finally got it working.
two quick changes and that worked
added the jar file in setDomainEnv.cmd like this
set PRE_CLASSPATH=%DOMAIN_HOME%\lib\activemq-all-5.16.3.jar;%PRE_CLASSPATH%
or you can put the complete URL of domain home.
while configuring the JMS on OSB, its always tricky to set the JNDI and I had to use both like below
jms://localhost:7001//
this helped and established a connection.
Related
When I use jconsole to access weblogic's mbean,I just can get some info about jvm like 'java.lang'.But what I want to get is about 'jdbc','jta','ejb','servlet'...
I wonder if I can get these indicators through service:jmx:rmi:///jndi/rmi://10.0.99.102:7997/jmxrmi with username and password.I think it's very likely that my configuration has errors, but I don't know where the problem is.
Then I tried another way.I enabled iiop, but I can't access it via iiop.
I met some errors like Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException.
Try to figure this error,I add wljarbulder.jar to my project,then another error comes out,'Unhandled exception in lookup,Caused by: javax.naming.NamingException Unhandled exception in lookup [Root exception is org.omg.CORBA.NO_PERMISSION...'.
All I need is to get the mbean information for weblogic, I am trying to monitor weblogic via jmx.
(I have collected weblogic's snmp oid, but it is not enough to complete my monitoring plan)
Thank you.
Actually,I figure out the problem.
It seems that the iiop default username and password must be set the same as weblogic Admin.
I don't understand why for this,but when I read one blog and try,then I get the data.
I'm not sure that I can get all the mbean data through this,but it connects successful at least and show a lot of data.
I should have used jconsole to find the value I want now.emmm,but I cannot connect by jconsole.But this is the next question.
First add these parameters to your WebLogic Server instance :
-Dcom.sun.management.jmxremote
-Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder
-Dcom.sun.management.jmxremote.port=6789
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Second, launch jconsole :
jconsole.exe -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%WL_HOME%\server\lib\weblogic.jar;%JAVA_HOME%\lib\tools.jar
and connect to port 6789
Does anyone know how to configure NServiceBus (v6.2) using the AzureServiceBusTransport to not attempt to create namespaces?
I'd like to configure NServiceBus the use a connection string which only has permissions to send (the queue's should already be there and if not an error is more appropriate than creation) but whenever I configure it this way I get the following error:
Pre start-up check failed: Configured to create topology, but have no manage rights for the following namespace(s): xxxxxxxxxxxxxx
This error message suggests the functionality is configurable but having looked through the code and the documentation for the mechanism I can't find it.
Many thanks
Adam
Looks like I answered my own question - a bug was raised against the AzureServiceBusTransport and subsequently fixed a little while ago:
https://github.com/Particular/NServiceBus.AzureServiceBus/issues/528
As the bug says upgrading to version 7.1.8 or 7.2.3 and not enabling installers fixes the issue.
I am porting a suite of related applications from WebLogic to JBoss EAP v6.2.
I have set up a data source connection using the JBoss command line interface and hooked it to an oracle database. This database has a name of "mydatasource" and a JNDI name of
"java:jboss/datasources/mydatasource" as per JBoss standards. I can test and validate this database connection.
However, when I try to port the code and run it, the connection doesn't work. The code that worked in WebLogic was simply:
InitialContext ic = new InitialContext() ;
DataSource ds = (DataSource)ic.lookup(dataSource) ;
with a value in dataSource of "mydatasource".
This worked in Web Logic but in JBoss it throws a NameNotFoundException
javax.naming.NameNotFoundException: mydatasource-- service jboss.naming.context.java.mydatasource
Clearly there is a difference in how the InitialContext is set up between the two servers.
But this port involves a large number of small applications, all of which connect to the datasource via code like that above. I don't want to rewrite all that code.
Is there a way through configuration (InitialContextFactory, maybe) to define the initial context such that code like that above will work without rewriting, or perhaps is there another way of naming the datasource that JBoss will accept that would allow code like that above to work without rewriting?
Or must we bite the bullet and accept that this code needs a rewrite?
Update: Yes, I know that simply passing "java:jboss/datasources/mydatasource" to the InitialContext lookup solves the problem, but I am looking for a solution via configuration, rather than via coding if there is such a solution.
The way to do this correctly through configuration is to use
java:comp/env/jdbc/myDataSource
then use resource-ref in web.xml to map it to the declare datasource and use weblogic.xml or jboss-web.xml to actually map it to the real one
in weblogic admin console, when you define datasource it can be jdbc/realDataSource
JNDI path Tomcat vs. Jboss
For weblogic http://docs.oracle.com/cd/E13222_01/wls/docs103/jdbc_admin/packagedjdbc.html
I am trying to connect to GlassFish 3's JMS service from a standalone remote client. However I am getting a java.lang.ClassNotFoundException: com.sun.messaging.jms.ra.ResourceAdapter. Any ideas on how to fix this?
Here's my setup so far:
Glassfish 3 JMS Service in LOCAL mode (I am assuming that EMBEDED mode will not work in this case because it bypasses the network stack)
JNDI properties are specified as follows:
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
java.naming.factory.url.pkgs=com.sun.enterprise.naming
java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl
gf-client-module.jar (in GLASSFISH_HOME/modules) added to the standalone application's classpath. Also tried adding other jars present in the modules directory (such as jms-core.jar), but still getting the same ClassNotFoundException.
Any help would be much appreciated.
Instead of using all of the individual Glassfish jar files that you might need (such as gf-client-module.jar, imqjmsra.jar, and imqbroker.jar), the preferred method is to use the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib.
There is more information at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. That document pertains to using EJBs in standalone clients, but the solution is the same for using JMS.
Ok. I found a solution. See here for details, but the short answer is that I needed to add two jars to the classpath: imqjmsra.jar and imqbroker.jar. These were available inside a rar called imqjmsra.rar which can be found under glassfish's mq directory. I had to extract the two jars from this rar!
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
As mentioned in the Ivan A Krizsan's notes for the EJB certification, and depending on the Glassfish version, this should be enough:
GlassFish 3 (and GlassFish 4 too, I've just tested it): $GLASSFISH_HOME/lib/gf-client.jar
GlassFish 2: $GLASSFISH_HOME/lib/appserv-rt.jar and $APS_HOME/lib/javaee.jar
I'm troubleshooting a Mapper problem and I'm running into an issue trying to use a Mapper class inside of the Scala/Lift console. Our MetaMappers have their datasource configured through a ConnectionIdentifier that points to a JDBC datasource configured in JNDI. This works great when bootstrapping through Jetty.
When loading the console and running (new bootstrap.liftweb.Boot).boot to initialize, Schemifier.schemify fails JNDI configuration is not available.
scala> (new bootstrap.liftweb.Boot).boot
java.lang.NullPointerException: Looking for Connection Identifier ConnectionIdentifier(jdbc/svcHub) but failed to find either a JNDI data source with the name jdbc/svcHub or a lift connection manager with the correct name
at net.liftweb.mapper.DB$$anonfun$7$$anonfun$apply$12.apply(DB.scala:141)
at net.liftweb.mapper.DB$$anonfun$7$$anonfun$apply$12.apply(DB.scala:141)
at net.liftweb.common.EmptyBox.openOr(Box.scala:465)
at net.liftweb.mapper.DB$$anonfun$7.apply(DB.scala:140)
at net.liftweb.mapper.DB$$anonfun$7.apply(DB.scala:140)
at net.liftweb.common.EmptyBox.openOr(Box.scala:465)
at net.liftweb.mapper.DB$.newConnection(DB.scala:134)
at net.liftweb.mapper.DB$.getConnection(DB.scala:230)
at net.liftweb.mapper.DB$.use(DB.scala:581)
at net.liftweb.mapper.Schemifier$.schemify(Sche...
Essentially, I'd like to have full MetaMapper functionality from within the console. My question is: What's the best way to bootstrap a Lift app from the console such that the JNDI-based dependencies can also be fulfilled outside of a JNDI-capable web container?
Under a application server it's likely that the server will provide a JNDI context for you. In a standalone application you must provide a JNDI Context your self. For that you can use a javax.naming.InitialContext.
There is a nice example using Apache's DBCP here: http://commons.apache.org/dbcp/guide/jndi-howto.html. Of course, will you have to fix the Datasource objects to the implementation you are using.
This will be enough (not very elegant, though) for simple JNDI usage.