[JBossWS] - WSSecurity failure on Linux
by PeterJ
I have just spent the better part of a day trying to figure out why my Web service, which uses WSSecurity to either encrypt or sign my messages, works on Windows but not on Linux. What really bugged my is that no matter whether I built the Web service and client on Windows or on Linux, the resulting JARs would work on Windows but not Linux. In other words, I could build on Linux, and those JARs failed on Linux but worked on Windows. And vice-versa.
The error?
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: org.jboss.ws.core.CommonSOAPFaultException: This service requires <wsse:Security>, which is missing.
| at org.jboss.ws.core.jaxws.SOAPFaultHelperJAXWS.getSOAPFaultException(SOAPFaultHelperJAXWS.java:69)
| at org.jboss.ws.core.jaxws.binding.SOAP11BindingJAXWS.throwFaultException(SOAP11BindingJAXWS.java:109)
| at org.jboss.ws.core.CommonSOAPBinding.unbindResponseMessage(CommonSOAPBinding.java:553)
| at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:371)
| at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:243)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:164)
| at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:150)
Then inspiration struck. While attempting to debug the situation, I noticed that log4j correctly picked up its configuration file on Windows, but not on Linux. Apparently on Windows, the client's JAR files are placed first in the classpath, but on Linux they are placed last. Which caused a stray log4j configuration file to be used on Linux. (And yes, I did remove the "-Dlog4j.configuration=wstools-log4j.xml" option from the command line in wsrunclient. Not sure who thought it was a good idea to prevent users from defining their own log4j configuration files.)
Anyway, I changes the order in which the classpath was built, moving the following code in wsrunclient.sh:
while [ $# -ge 1 ]; do
| case $1 in
| "-classpath") WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$2"; shift;;
| *) args="$args \"$1\"";;
| esac
| shift
| done
before these lines:
# Setup the client classpath
| WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$JBOSS_HOME/client/log4j.jar"
| WSRUNCLIENT_CLASSPATH="$WSRUNCLIENT_CLASSPATH:$JBOSS_HOME/client/jbossws-client.jar"
The Web service now works correctly on Linux.
Any possibility that the wsrunclient.sh could be permanently fixed?
What I was running:
JBoss 5.0.0 beta3 pulled on Sept 27, which appears to contain jbossws-native-2.0.1.SP1
I checked JBossWS 2.0.0.GA and 2.0.1.GA, and both of their wsrunclient.sh files have the same problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092751#4092751
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092751
18Â years, 7Â months
[JBoss Portal] - Re: Chanhes Made Though the Admin Console is not reflecting
by shanportal
Hi Peter. The following is the portal-oracle-ds.xml file
| <?xml version="1.0" encoding="UTF-8"?>
| <!--~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ~ JBoss, a division of Red Hat ~
| ~ Copyright 2006, Red Hat Middleware, LLC, and individual ~
| ~ contributors as indicated by the @authors tag. See the ~
| ~ copyright.txt in the distribution for a full listing of ~
| ~ individual contributors. ~
| ~ ~
| ~ This is free software; you can redistribute it and/or modify it ~
| ~ under the terms of the GNU Lesser General Public License as ~
| ~ published by the Free Software Foundation; either version 2.1 of ~
| ~ the License, or (at your option) any later version. ~
| ~ ~
| ~ This software is distributed in the hope that it will be useful, ~
| ~ but WITHOUT ANY WARRANTY; without even the implied warranty of ~
| ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ~
| ~ Lesser General Public License for more details. ~
| ~ ~
| ~ You should have received a copy of the GNU Lesser General Public ~
| ~ License along with this software; if not, write to the Free ~
| ~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA ~
| ~ 02110-1301 USA, or see the FSF site: http://www.fsf.org. ~
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~-->
|
| <datasources>
| <local-tx-datasource>
| <jndi-name>PortalDS</jndi-name>
| <connection-url>jdbc:oracle:thin:portalopen/portalopen@portal:1521:bgopen</connection-url>
| <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
| <user-name>portalopen</user-name>
| <password>portalopen</password>
| </local-tx-datasource>
| </datasources>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092748#4092748
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092748
18Â years, 7Â months
[JBoss Seam] - Difference between @Factory and @Create for outjected compon
by shakenbrain
I have a page that has the following requirements:
* accessible from a GET request
* begins a conversation
* initializes a component
To do this, I created a method in a SFSB with conversational scope as follows:
@Create
| @Begin(flushMode=FlushModeType.MANUAL)
| public void createTicket() {
| jobTicket = new JobTicket();
| jobTicket.setTitle("Title");
| }
The jobTicket is outjected as follows:
@In(required=false) @Out
| private JobTicket jobTicket;
The XHTML source for the page:
<s:decorate id="titleDecorator" template="/decorateField.xhtml">
| <ui:define name="label">#{messages.Title}</ui:define>
| <h:inputText id="title" value="#{selectedJobTicket.title}" size="80" required="true" autocomplete="off"/>
| </s:decorate>
|
I have nothing in pages.xml that refers to the rendered page. When the page is rendered, the jobTicket appears to be uninitialized- the value for title is not displayed. However, if I look at the conversation in the debug page, the jobTicket object is there, and 'title' is populated with the correct value.
If I change '@Create' to '@Factory("jobTicket")', the page renders as expected- the value for title is displayed. I don't want to use @Factory, because in another bean I want to outject a different jobTicket into a different scope.
Can someone explain to me why there's a difference in behavior? I must be missing something fundamental here...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092745#4092745
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092745
18Â years, 7Â months