[Design of JBoss Profiler] - problem in loading jbossInspector
by nayyares
Hi,
I am using AS-4.0.4 on Solaris 10, i followed the instuctions at http://wiki.jboss.org/wiki/SolAris, everything went fine, now when i try to start/boot JBoss server i get following error:
anonymous wrote : $sh start.sh
| LD_LIBRARY_PATH = /export/home/user/jboss-profiler-1.0.CR4/jvmpi-src/solaris/bin:/usr/local/lib:/usr/local/lib/sparcv9
| Sending output to nohup.out
|
| JAVA: /usr/java/bin/java
|
| JAVA_OPTS: -server -Xmanagement:ssl=false,authenticate=false,port=7091 -d64 -Xms1360m -Xmx1360m -Xss256k -XrunjbossInspector:/export/home/user/jboss-profiler-1.0.CR4/ -Djboss.partition.name=SistafeCluster -Djboss.partition.udpGroup=224.0.0.100-Djboss.bind.address=srv018-app-fe -Djboss.fe.bind.address=srv018-app-fe -Djboss.be.bind.address=srv018-app-be -Djboss.sync.bind.address=127.0.0.1 -Dutrafe.home=/opt/utrafe -Djava.awt.headless=true -Dresolve.dns=false-Djava.rmi.server.hostname=srv018-app-fe -Dprogram.name=run.sh
|
| CLASSPATH: /opt/jboss/bin/run.jar:/usr/java/lib/tools.jar
|
| =========================================================================
|
| [ERROR][load ] Could not load library jbossInspector
| [ERROR][load ] Could not load library jbossInspector
|
|
here the ldd output,
anonymous wrote : $ldd -v libjbossInspector.so
|
| find object=libstdc++.so.6; required by ./libjbossInspector.so
| libstdc++.so.6 => /usr/local/lib/libstdc++.so.6
|
| find object=libm.so.2; required by ./libjbossInspector.so
| libm.so.2 => /lib/libm.so.2
|
| find object=libgcc_s.so.1; required by ./libjbossInspector.so
| libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
| find version=libgcc_s.so.1
| libgcc_s.so.1 (GCC_3.0) => /usr/local/lib/libgcc_s.so.1
|
| find object=libc.so.1; required by ./libjbossInspector.so
| libc.so.1 => /lib/libc.so.1
| find version=libc.so.1
| libc.so.1 (SUNW_1.1) => /lib/libc.so.1
|
| find object=libm.so.2; required by /usr/local/lib/libstdc++.so.6
|
| find object=libgcc_s.so.1; required by /usr/local/lib/libstdc++.so.6
| find version=libgcc_s.so.1
| libgcc_s.so.1 (GCC_3.3) => /usr/local/lib/libgcc_s.so.1
|
| find object=libc.so.1; required by /usr/local/lib/libstdc++.so.6
| find version=libc.so.1
| libc.so.1 (SUNW_1.22) => /lib/libc.so.1
| libc.so.1 (SUNWprivate_1.1) => /lib/libc.so.1
|
| find object=libc.so.1; required by /lib/libm.so.2
| find version=libc.so.1
| libc.so.1 (SUNW_0.7) => /lib/libc.so.1
| libc.so.1 (SUNWprivate_1.1) => /lib/libc.so.1
|
| find object=libc.so.1; required by /usr/local/lib/libgcc_s.so.1
| find version=libc.so.1
| libc.so.1 (SUNW_1.1) => /lib/libc.so.1
|
| object=/lib/libc.so.1; filter for /usr/lib/ld.so.1
|
| object=/lib/libc.so.1; filter for libm.so.2
|
| find object=libm.so.2; required by /lib/libc.so.1
|
| object=/lib/libc.so.1; filter for /platform/$PLATFORM/lib/libc_psr.so.1
|
| find object=/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1; required by /lib/libc.so.1
| /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
I have defined JAVA_OPTS & LD_LIBRARY_PATH in start up script as:
anonymous wrote : #Jboss Profiler
| JAVA_OPTS="$JAVA_OPTS -XrunjbossInspector:/export/home/user/jboss-profiler-1.0.CR4/"
| LD_LIBRARY_PATH="/export/home/user/jboss-profiler-1.0.CR4/jvmpi-src/solaris/bin:/usr/local/lib:/usr/local/lib/sparcv9"
| export LD_LIBRARY_PATH
|
even when i try with
anonymous wrote : $java -XrunjbossInspector:/tmp Foo
| [ERROR][load ] Could not load library jbossInspector
| [ERROR][load ] Could not load library jbossInspector
| Exception in thread "Main Thread" java.lang.NoClassDefFoundError: Foo
|
TIA
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152313#4152313
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152313
17 years, 10 months
[Design of JBoss ESB] - Re: FS-listener IOException
by tfennelly
"ama1" wrote : Hi Daniel,
| yes I had a look into that example. But the only think which looks different is the JMS-Listener. But it looked for me that this listener is just an alternative input channel for the actions?
| Or is it mandatory? And if yes what exactly does the JMS do in this example?
You're right... this is one of the more confusing parts of the ESB configuration. Pre 4.3.GA (just about to be released - available from SVN), every service needed to have at least 1 "message aware listener" configured. Gateways are there to get message payloads onto the bus, but most of them do it via a message aware listener. If you think this is confusing, don't worry... you're not the only one :-)
So it works something like this:
| message --> [gateways-listener] --> [message-aware-listener] --> [action-pipeline]
|
So you need the message aware listener to get the message payload from the gateway to the action processing pipeline.
The good news is that v4.3 will make this a lot easier (and more performant) because it adds support for an InVM transport, which means that by default, every service will have an InVM message aware listener. For the user, this means they just need to configure the gateway and it will work - no need to configure the extra JMS message aware listener.
So you need to configure that JMS message aware listener for now, but you can remove it when you move to 4.3.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152277#4152277
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152277
17 years, 10 months
[Design of EJB 3.0] - Re: JBMETA-42
by wolfc
"scott.stark(a)jboss.org" wrote : anonymous wrote : This will fix JBMETA-42, but cause regression in ResolvedJndiNameUnitTestCase, which looks like it's testing for wrong resolved JNDI Names anyway. Base should be the EJB Name, not the Default JNDI Name, right?
| No, if there is a given jndi name, it should be the unique root context for any other derivative jndi bindings. We are always given a jndi name in the tck tests, so this is what we are focusing on. The only time an ejb name should come into the picture is when there is no explicit jndi-name/mapped-name given.
|
That can't be. All jndi names must be unique or you'll get a NotContextException.
As already shown by Andrews prototype, my original idea of having the object factory bound at at a base jndi name turned out to be a 'Bad Idea (tm)'.
So the tests in ResolvedJndiNameUnitTestCase are out-dated in that respect.
What I also said was that the final jndi name is overridable. So if a jndi-name is set in jboss.xml then beanMD.determineResolvedJndiName(KnownInterfaces.REMOTE, null); must return that jndi-name.
This is just plain wrong in ResolvedJndiNameUnitTestCase.
There is a side issue where JBossWS expects to find a home interface on the jndi name. This might also be the case for EJB 2.1 compatibility.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152274#4152274
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152274
17 years, 10 months