Re: [jboss-user] [JBoss Web Services] - Problem with WS Security encryption
by Peter Johnson
Peter Johnson [http://community.jboss.org/people/peterj] replied to the discussion
"Problem with WS Security encryption"
To view the discussion, visit: http://community.jboss.org/message/546800#546800
--------------------------------------------------------------
Do not use Eclipse to build your web service for you - I think that Eclipse bases its web services on Axis.
Did you install JBoss Tools into Eclipse? You could use that to build your web services (I think I did that once).
Have you built an run target 07 in project ch09? That builds a secured web client but uses the properties file (rather than a database) for login. Target 05 in ch08 builds a messaging client using the database for login, so you could use that as an example of switching the web service to using the database for login.
Also, try setting the log to TRACE for org.jboss.security.auth, that should give you some details of exactly what is going on. (From what you have provided I cannot tell if your code is incorrect (you did not provide the code), or if your database is not set up correctly. The trace might provide some insight into that.)
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546800#546800]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Microcontainer Development] - Wildcard support in Dynamic-imports
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] replied to the discussion
"Wildcard support in Dynamic-imports"
To view the discussion, visit: http://community.jboss.org/message/546799#546799
--------------------------------------------------------------
It now boils down to this prototype (with lots of details yet to impl).
Is this what you had in mind - roughly speaking :-)?
public class WildcardDelegateLoader extends FilteredDelegateLoader
{
private Controller controller;
private Module module;
private VersionRange range;
public WildcardDelegateLoader(Controller controller, ClassLoaderPolicyFactory factory, ClassFilter filter, RequirementDependencyItem item)
{
super(factory, filter);
if (controller == null)
throw new IllegalArgumentException("Null controller");
if (item == null)
throw new IllegalArgumentException("Null item");
Requirement requirement = item.getRequirement();
if (requirement instanceof PackageRequirement == false)
throw new IllegalArgumentException("Illegal package requirement: " + requirement);
this.controller = controller;
this.module = item.getModule();
this.range = ((PackageRequirement)requirement).getVersionRange();
}
protected Module resolve(String pckg)
{
Requirement requirement = new PackageRequirement(pckg, range);
// TODO -- add this DI to module? new DI impl to remove delegate from policy when resolved module goes away?
RequirementDependencyItem item = new RequirementDependencyItem(module, requirement, module.getClassLoaderState(), ControllerState.INSTALLED);
if (item.resolve(controller))
{
ClassLoaderPolicy policy = getPolicy();
// TODO -- add delegate to policy
}
return item.getResolvedModule();
}
@Override
protected Class<?> doLoadClass(String className)
{
Module resolvedModule = resolve(ClassLoaderUtils.getClassPackageName(className));
try
{
return resolvedModule != null ? resolvedModule.loadClass(className) : null;
}
catch (ClassNotFoundException e)
{
throw new RuntimeException(e);
}
}
@Override
protected URL doGetResource(String name)
{
Module resolvedModule = resolve(ClassLoaderUtils.getResourcePackageName(name)); // TODO -- extract package name
return resolvedModule != null ? resolvedModule.getResource(name) : null;
}
@Override
protected void doGetResources(String name, Set<URL> urls) throws IOException
{
Module resolvedModule = resolve(ClassLoaderUtils.getResourcePackageName(name)); // TODO -- extract package name
if (resolvedModule != null)
{
Enumeration<URL> ue = resolvedModule.getResources(name);
while (ue.hasMoreElements())
urls.add(ue.nextElement());
}
}
@Override
protected Package doGetPackage(String name)
{
return null; // TODO -- how to get package from here, from resolved Module?
}
@Override
protected void doGetPackages(Set<Package> packages)
{
// do nothing?
}
}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546799#546799]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Web Services] - JBOSSWS creates WSDL incompatible with JDK Endpoint class and .Net Clients
by Russell Ritenour
Russell Ritenour [http://community.jboss.org/people/ritenru] replied to the discussion
"JBOSSWS creates WSDL incompatible with JDK Endpoint class and .Net Clients"
To view the discussion, visit: http://community.jboss.org/message/546764#546764
--------------------------------------------------------------
<warning type="editorial">
Well, this is a first. Three weeks without a single comment (even one to tell me I shouldn't do it this way).
</warning>
I installed the jboss-6.0.0-20100429-M3 version with no change in behavior.
Upon further investigation, I discovered that the message part name attribute (//message/part[@name]) is different between the Endpoint RI and the JBOSS generated WSDL. If I modify the WSDL from JBOSS by changing the name="..." to name="parameters", the .NET client works fine.
{code}
/cygdrive/c/foo/jbossws/mod-wsdl> diff cfg.wsdl cfg.wsdl.orig
118c118
< <part element="tns:createConfigEntry" name="parameters"/>
---
> <part element="tns:createConfigEntry" name="createConfigEntry"/>
121c121
< <part element="tns:listEntriesResponse" name="parameters"/>
---
> <part element="tns:listEntriesResponse" name="listEntriesResponse"/>
127c127
< <part element="tns:listEntries" name="parameters"/>
---
> <part element="tns:listEntries" name="listEntries"/>
130c130
< <part element="tns:createConfigEntryResponse" name="parameters"/>
---
> <part element="tns:createConfigEntryResponse" name="createConfigEntryResponse"/>
133c133
< <part element="tns:getConfigValue" name="parameters"/>
---
> <part element="tns:getConfigValue" name="getConfigValue"/>
139c139
< <part element="tns:deleteConfigEntryByName" name="parameters"/>
---
> <part element="tns:deleteConfigEntryByName" name="deleteConfigEntryByName"/>
145c145
< <part element="tns:deleteConfigEntryByNameResponse" name="parameters"/>
---
> <part element="tns:deleteConfigEntryByNameResponse" name="deleteConfigEntryByNameResponse"/>
154c154
< <part element="tns:getConfigValueResponse" name="parameters"/>
---
> <part element="tns:getConfigValueResponse" name="getConfigValueResponse"/>
{code}
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546764#546764]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Tools] - WEB-INF/lib remains empty after deployment
by henk de boer
henk de boer [http://community.jboss.org/people/henk53] replied to the discussion
"WEB-INF/lib remains empty after deployment"
To view the discussion, visit: http://community.jboss.org/message/546754#546754
--------------------------------------------------------------
> Max Andersen wrote:
>
> Check the updatesite :)
Great that it has been released!
Unfortunately, I have some bad news. This update didn't seem to have fixed this particular problem :(
On Ubuntu 10.04, running Eclipse 3.5.2 with JBoss tools 3.1.0GA, I entered the following URL in P2: http://download.jboss.org/jbosstools/updates/JBossTools-3.1.1.GA http://download.jboss.org/jbosstools/updates/JBossTools-3.1.1.GA
I got the message: "Your original request has been modified.
"JBossAS Tools" is already installed, so an update will be performed instead.", I selected ok, restarted Eclipse and afterwards started JBoss AS via the Jboss tools server adapter.
On the first boot, I got a deployment error again, and when I inspected the deployment on my fs, WEB-INF/lib was empty again. I then performed the well known trick: close projects, open projects, select clean on the server adapter. After this the libs were back.
Thinking it might be stale state remaining from the JBoss tools 3.1.0GA install, I closed Eclipse. Started Eclipse again and thereafter started JBoss AS again. To my horror, the same deployment error was reported and upon inspecting the fs again, the libs were once again gone :( I double checked that I'm running the correct version of Jboss Tools, but Eclipse really says "Version: 2.1.1.v201006011046R-H111-GA", which should be the right one, shouldn't it?
I will also test this on my most sensitive machine (the OS X one) and report back later how this went.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546754#546754]
Start a new discussion in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
Re: [jboss-user] [JBoss Web Services CXF] - XTS tests broken in AS trunk after switch to CXF stack in 3.3.0
by Andrew Dinn
Andrew Dinn [http://community.jboss.org/people/adinn] replied to the discussion
"XTS tests broken in AS trunk after switch to CXF stack in 3.3.0"
To view the discussion, visit: http://community.jboss.org/message/546743#546743
--------------------------------------------------------------
> Alessio Soldano wrote:
>
> Let's clarify the situation a bit first then: it seems to me the problem here is that cxf does not consider the action provided in the message, which is what you'd expect, right?
> CXF instead goes throught the model constructed from the wsdl and try to get the action from that. That's why it's looking at the soap binding part of ws-addressing ( http://www.w3.org/TR/ws-addr-wsdl/ http://www.w3.org/TR/ws-addr-wsdl/), which defines namespace +http://www.w3.org/2006/05/addressing/wsdl http://www.w3.org/2006/05/addressing/wsdl+ for the Action element.
I don't think that is what is happening here. I believe it is the endpoint annotations not the WSDL which is being used. My endpoint implemenation bean and the method which is failing are coded as follows
> @WebService(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", name = "ActivationPortType",
> wsdlLocation = "/WEB-INF/wsdl/wscoor-activation-binding.wsdl",
> serviceName = "ActivationService",
> portName = "ActivationPortType"
> )
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
> // @EndpointConfig(configName = "Standard WSAddressing Endpoint")
> @HandlerChain(file="/handlers.xml")
> @Addressing(required=true)
> public class ActivationPortTypeImpl implements ActivationPortType
> {
> @Resource private WebServiceContext webServiceCtx;
>
> @WebMethod(operationName = "CreateCoordinationContextOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext")
> @WebResult(name = "CreateCoordinationContextResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
> @Action(input="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext", output="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext...")
> public CreateCoordinationContextResponseType createCoordinationContextOperation(
> @WebParam(name = "CreateCoordinationContext", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
> CreateCoordinationContextType parameters)
> {
> . . .
As you can see the output response action is specified using the @Action annotation.
Now looking at the exception stack you cqan see that when MAPAggregator executes as part of the output pipeline processing it tries to obtain the action associated with the response message by calling ContextUtils.getAction(message). This calls Contextutils.getActionFromServiceModel(message, null) which obtains the outbound message info and calls Contextutils.getActionFromMessageAttributes(msgInfo). The latter makes the call to ContextUtils.getAction(msgInfo) which blows up.
Now the odd thing is that message info has an action associated with it in the extension attributes hashmap and CXF has put it there. The key for the atribute is { http://www.w3.org/2005/08/addressing http://www.w3.org/2005/08/addressing}Action and the value is the one I specified in the @Action annotation. The lookup in MAPAggregator is trying to look it up using all the other possible keys (2006/05, 2007/05 etc) but not the one for the value which has been installed in the attributes map. Since this causes it to fall over when it fails to find an entry in the map I suspect the problem is that it is using the wrong key for the first test in ContextUtils.getAction(). Where it says
> Object o = ext.getExtensionAttribute(JAXWSAConstants.WSAW_ACTION_QNAME);
I believe it should say
> Object o = ext.getExtensionAttribute(JAXWSAConstants.WSA_ACTION_QNAME);
However, I don't see how this could ever have passed any sensible sort of QA process.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546743#546743]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
[Beginner's Corner] - Deployment and classloader issues
by null null
null null [http://community.jboss.org/people/mimtiaz] created the discussion
"Deployment and classloader issues"
To view the discussion, visit: http://community.jboss.org/message/546711#546711
--------------------------------------------------------------
Hi,
We have around 7 EAR's which needs to be deployed into JBoss, of which all the EAR's depend upon one EAR which contains an application that is required to be started before any other applicatons gets deployed and started. Also, we want to have all the EAR's to be loaded with their own(seperate) classloaders. To achieve this, we set the *isolated* property value to *true* in the *ear-deployer-jboss-beans.xml* file. Of these EAR's 4 (publish, rdesk, blueplanet, website) are having the WAR and the EJB submodules having MDBs in the EJB modules. The rest are having only WAR modules inside and they are starting perfectly fine without any issues. Every WAR module of an EAR contains a startup servlet, which determines whether the application has got started successfully or not. The problem here is with the EARs having the MDBs in them. It looks like JBoss is sharing the same classloader for all the EARs having MDBs in them. The state variable maintained to indentify the status of the application indicating if its started or not is getting always true once an EAR having MDB gets deployed into JBoss. Hence, the rest of the EARs followed by during the deployment fails to start the applications. Please be noted that we were able to start at least one EAR having MDBs in it along with the other EARs having only WARs. If we try to deploy another EAR having a WAR and MDBs it wont start the application with the above explained issue. Following are the details of the steps that we followed to achive this:
* We have pointed all the EAR locations in the *profile.xml* as given below:
<value>${jboss.server.home.url}deploy</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/eac/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/edesk/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/jms/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/rdesk/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/publish/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/blueplanet/appserver/jboss</value>
<value>file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/website/appserver/jboss</value>
eac.ear located under "file:///D:/BM/Dev_Env/Commerce_10_0_Dev/modules/eac/appserver/jboss" is the one that is required by all other applications. Hence, we have placed the rest of the EARs inside a directory named "deploy.last" under thier respective deployment locations as specified above.
* We set the *isolated* property value to *true* in the *ear-deployer-jboss-beans.xml* file as given below:
<property name="isolated">true</property>
* We have also specified the *jboss-app.xm*l in each EAR as given below:
<jboss-app>
<loader-repository>
blueplanet:archive=blueplanet.ear
<loader-repository-config>
java2ParentDelegation=true
</loader-repository-config>
</loader-repository>
</jboss-app>
* Also, specified the *jboss-classloading.xml* in each WAR as given below:
<classloading xmlns="urn:jboss:classloading:1.0"
name="blueplanet.war"
domain="bpa_domain"
top-level-classloader="true"
export-all="NON_EMPTY"
import-all="true">
</classloading>
Nothing helped us to get rid of this issue. Where are we going wrong ? Kindly help us with your valuable inputs. Your earliest inputs are highly appreciated.
PS: Plese find the attached server log of JBoss related to this issue.
Thanks,
IM.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/546711#546711]
Start a new discussion in Beginner's Corner at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month