June 2010 - jboss-dev-forums - Jboss List Archives

Re: [jboss-dev-forums] [JBoss Web Services Development] - Installing JBossWS Native on JBAS 5.1.0

by Alessio Soldano

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "Installing JBossWS Native on JBAS 5.1.0" To view the discussion, visit: http://community.jboss.org/message/548638#548638 -------------------------------------------------------------- Sorry, as I said previously, that's not possible. Let's forget for now that we'd have to provide 3 (stacks) * 3 (supported target containers) = 9 additional zips for each release; depending on the jbossws and application server versions, there're some files that are just to be delated, not replaced. So, again, just expanding a zip is not going to work. We provide an installation script (which can be run with just 2 commands) because there's need for that. Just as an example, installing 3.3.1 on AS 5.1.0 implies removing the following files: client: jbossws-jboss50.jar client: jbossws-native-jaxrpc.jar client: jbossws-native-jaxws.jar client: jbossws-native-saaj.jar common/lib: jbossws-native-jaxrpc.jar common/lib: jbossws-native-jaxws.jar common/lib: jbossws-native-saaj.jar server/default/deploy: jbossws.sar server/default/deployers/jbossws.deployer: FastInfoset.jar server/default/deployers/jbossws.deployer: jboss-jaxb-intros.jar server/default/deployers/jbossws.deployer: jbossws-common.jar server/default/deployers/jbossws.deployer: jbossws-framework.jar server/default/deployers/jbossws.deployer: jbossws-jboss50.jar server/default/deployers/jbossws.deployer: jbossws-native-core.jar server/default/deployers/jbossws.deployer: jettison.jar server/default/deployers/jbossws.deployer/META-INF: jboss-beans.xml server/default/deployers/jbossws.deployer/META-INF: jbossws-deployer-jboss-beans.xml server/default/deployers/jbossws.deployer/META-INF: standard-jaxrpc-client-config.xml server/default/deployers/jbossws.deployer/META-INF: standard-jaxrpc-endpoint-config.xml server/default/deployers/jbossws.deployer/META-INF: standard-jaxws-client-config.xml server/default/deployers/jbossws.deployer/META-INF: standard-jaxws-endpoint-config.xml server/default/deployers/jbossws.deployer: policy.jar server/default/deployers/jbossws.deployer: wsdl4j.jar server/default/deployers/jbossws.deployer: xmlsec.jar In case you're going to ask me why the files above need to be removed, as an example the jbossws-native-jaxrpc, jbossws-native-jaxws and jbossws-native-saaj jars do not exist anymore in JBWS 3.3.x, so leaving those there would basically break the installation. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548638#548638] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Installing JBossWS Native on JBAS 5.1.0

by ANIL SALDHANA

ANIL SALDHANA [http://community.jboss.org/people/anil.saldhana%40jboss.com] replied to the discussion "Installing JBossWS Native on JBAS 5.1.0" To view the discussion, visit: http://community.jboss.org/message/548622#548622 -------------------------------------------------------------- I am wondering if you are able to provide a zip with each release of JBossWS, that I can just plug into my integration test workspace. Before the test startup, I want to unzip this jbossws distribution on a stock AS 5.1, to get everything replaced (that needs to be replaced) for the new stack to be running on AS5.1 If we have to certify PicketLink STS to run against JBossWS stacks, we need the zips. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548622#548622] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Messaging Development] - problem with seam and mdb on jboss5.1

by Bob Cleveland

Bob Cleveland [http://community.jboss.org/people/bclevelandsview] replied to the discussion "problem with seam and mdb on jboss5.1" To view the discussion, visit: http://community.jboss.org/message/548610#548610 -------------------------------------------------------------- Add this annotation: @Depends( {"jboss.web.deployment:war=/myappname"} ) Where myappname is the name of your app's warfile. This will delay the initialization of the MDB until after Seam has finished initializing during the war deployment. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548610#548610] Start a new discussion in JBoss Messaging Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

[JBoss Remoting Development] - Threads Hanging in MicroSocketClientInvoker.readVersion()

by Nathan Ciliberto

Nathan Ciliberto [http://community.jboss.org/people/snacker] created the discussion "Threads Hanging in MicroSocketClientInvoker.readVersion()" To view the discussion, visit: http://community.jboss.org/message/548604#548604 -------------------------------------------------------------- Note: this issue was originally reported here: https://community.jboss.org/message/548382#548382 https://community.jboss.org/message/548382#548382 On the web server side we see occasionally see threads with this stack: 75: [Thread[jrpp-1390,5,jrpp]]/id=49440/hc=13398717/shc=*/state=RUNNABLE/name=* java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(SocketInputStream.java:129) java.io.BufferedInputStream.fill(BufferedInputStream.java:218) java.io.BufferedInputStream.read(BufferedInputStream.java:237) java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249) java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2429) java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2499) java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2571) java.io.ObjectInputStream.read(ObjectInputStream.java:820) org.jboss.remoting.transport.socket.MicroSocketClientInvoker.*readVersion*(MicroSocketClientInvoker.java:1263) org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:838) org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165) org.jboss.remoting.Client.invoke(Client.java:1724) org.jboss.remoting.Client.invoke(Client.java:629) org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74) org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) $Proxy5.invoke(Unknown Source) org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207) org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164) $Proxy1643.completeMyOrder(Unknown Source) ... rest of our business process thread stack... On the jboss server for each thread above we usually see at least 2 jboss threads with the following stack: 816: [WorkerThread#10[10.1.4.245:46454]]/id=6923/hc=1806701791/shc=*/state=RUNNABLE/name=* java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(SocketInputStream.java:129) java.io.BufferedInputStream.fill(BufferedInputStream.java:218) java.io.BufferedInputStream.read(BufferedInputStream.java:237) java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249) java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2429) java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2499) java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2571) java.io.ObjectInputStream.read(ObjectInputStream.java:820) org.jboss.remoting.transport.socket.ServerThread.*readVersion*(ServerThread.java:1038) org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:673) org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551) org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232) I am not sure what is going on, but it looks like there is something that occasionally gets messed up with these "readVersion(...)" methods. These threads will hang for hours and days. The only way we can get these to stop hanging is to send a Thread.interrupt() to the threads on the web server side. Sending the interrupt to the thread on the jboss side only moves the problem to a different thread and doesn't stop the web server threads from hanging. We are not sure what is causing this, but it appears to be a bug in jboss. We are using 5.1.0 GA. It looks like the class allows for timeout and retry settings, but I am not sure how to set these on the client side. http://anonsvn.jboss.org/repos/jbossremoting/remoting2/tags/2.5.1/src/mai... http://anonsvn.jboss.org/repos/jbossremoting/remoting2/tags/2.5.1/src/mai... The MANIFEST.MF of our jboss-remoting.jar shows version "2.5.1" Is this related to https://jira.jboss.org/browse/JBREM-1188 https://jira.jboss.org/browse/JBREM-1188 ? If so, I think the default of 30 seconds would be too long for us. Is there a way to change that via a config file on the client side? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548604#548604] Start a new discussion in JBoss Remoting Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Development] - Failed to load: org.jboss.ws.tools.jaxws.impl.JBossWSProviderFactoryImpl

by Jean-Francois Morin

Jean-Francois Morin [http://community.jboss.org/people/jmorin] replied to the discussion "Failed to load: org.jboss.ws.tools.jaxws.impl.JBossWSProviderFactoryImpl" To view the discussion, visit: http://community.jboss.org/message/548594#548594 -------------------------------------------------------------- try adding this dependency, i just got the same issue and that fixed it <dependency> <groupId>org.jboss.ws.native</groupId> <artifactId>jbossws-native-core</artifactId> <version>3.1.2.GA</version> <type>jar</type> <scope>compile</scope> </dependency> -JF -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548594#548594] Start a new discussion in JBoss Web Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss ESB Development] - Camel integration input requested

by David Ward

David Ward [http://community.jboss.org/people/dward] replied to the discussion "Camel integration input requested" To view the discussion, visit: http://community.jboss.org/message/548572#548572 -------------------------------------------------------------- Fair enough. I just added the following note to http://community.jboss.org/docs/DOC-15462 Camel Gateway: Using non-core Components: *Note:* When installing additional Camel Components, the directories listed above are the recommended location for the Component jar libraries and any of their dependent jar libraries. Whereas installing these libraries in other directories available to JBoss might be possible, it +has not been tested+, and thus not recommended. Finally, be aware that a restart of the ESB server will be required afer installing the Component jars before the Component's URI can be used by the CamelGateway. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548572#548572] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - Unexpected behaviour when binding to java:comp and @Startup beans

by Marius Bogoevici

Marius Bogoevici [http://community.jboss.org/people/marius.bogoevici] replied to the discussion "Unexpected behaviour when binding to java:comp and @Startup beans" To view the discussion, visit: http://community.jboss.org/message/548568#548568 -------------------------------------------------------------- Yes, that's what puzzles me. I'll try to think of a way to reproduce the issue per se - the problem becomes obvious with the Weld JNDI Binding. Meanwhile, here is a very simple example which does not quite reproduce the issue, but helps explaining what I mean. while postconstructing the ejb, we're looking for java:comp - now if you're looking at ComponentObjectFactory, you can see that CurrentComponent.get() returns null, so the application is using the legacy branch. A "java:comp" is found during lookup, but for some reason, it does not seem to be the same as the one accessed via JavaEEComponent.getContext(). So, thanks Jaikiran for looking into this, and please let me know what you think. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548568#548568] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss ESB Development] - Camel integration input requested

by Keith Babo

Keith Babo [http://community.jboss.org/people/kcbabo] replied to the discussion "Camel integration input requested" To view the discussion, visit: http://community.jboss.org/message/548565#548565 -------------------------------------------------------------- I probably should have prefaced my feedback by saying that I don't think it requires functionality changes or even further testing right now. Probably just a 3-4 bullet summary something along the lines of: * When installing additional Camel components, it is recommended that the component jars and any dependenies are placed in the JBoss ESB SAR's lib directory* *AS 4:* .../server/default/deploy/jbossesb.sar/lib/ * *AS 5:* .../server/default/deployers/esb.deployer/lib/ * While component jars can be installed in alternate locations (e.g. server lib, or within an ESB application), this has not been tested. * A restart of the ESB server will be required afer installing the component jars before the component's URI can be used by the Camel gateway We can add class loader scoping to the above instructions when we get around to it. Or maybe someone in the community that's interested will do it and post their experience to the forum. `k. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548565#548565] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss ESB Development] - WSDL11Reader.java has problems w/ included WSDL

by David Ward

David Ward [http://community.jboss.org/people/dward] replied to the discussion "WSDL11Reader.java has problems w/ included WSDL" To view the discussion, visit: http://community.jboss.org/message/548562#548562 -------------------------------------------------------------- Kev, Yes, this is a JBossWS utility class that I leverage in SOAPProxy, as seen in Dave's stack trace: at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:129) at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:174) Should we create a JBossWS jira issue and alert that team? David -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548562#548562] Start a new discussion in JBoss ESB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - Unexpected behaviour when binding to java:comp and @Startup beans

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "Unexpected behaviour when binding to java:comp and @Startup beans" To view the discussion, visit: http://community.jboss.org/message/548559#548559 -------------------------------------------------------------- This should have worked, because when EJBContainer.start() is invoked, it's expected that the java:comp is setup correctly. Let me see what's wrong. (If you have app which can reproduce this, please mail it to me or attach it here. That will help :) ) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548559#548559] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

14 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2010