[JBoss Web Services Development] New message: "Problem with WS Security"
by Marcin Ostachowski
JBoss development,
A new message was posted in the thread "Problem with WS Security":
http://community.jboss.org/message/521875#521875
Author : Marcin Ostachowski
Profile : http://community.jboss.org/people/CichyKloszard
Message:
--------------------------------------------------------------
Hi everyone,
I`m trying to implement WS server and client with WS Security for several last days.
My server looks like:
package test;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService()
public class Calculator {
@WebMethod
public int add(int value1, int value2) {
return value1 + value2;
}
}
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.4">
<servlet>
<display-name>Calculator</display-name>
<servlet-name>Calculator</servlet-name>
<servlet-class>
test.Calculator
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Calculator</servlet-name>
<url-pattern>/calculator</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>
jboss-wsse-server.xml:
<jboss-ws-security
xmlns="http://www.jboss.com/ws-security/config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/ws-security/config
http://www.jboss.com/ws-security/schema/jboss-ws-security_1_0.xsd">
<key-store-file>WEB-INF/server.keystore</key-store-file>
<key-store-password>pass123</key-store-password>
<key-store-type>jks</key-store-type>
<trust-store-file>WEB-INF/server.truststore</trust-store-file>
<trust-store-password>pass123</trust-store-password>
<trust-store-type>jks</trust-store-type>
<key-passwords>
<key-password alias="server" password="pass123" />
</key-passwords>
<config>
<encrypt type="x509v3" alias="client" />
<requires>
<encryption />
</requires>
</config>
</jboss-ws-security>
I`ve put server.keystore and server.truststore into web-inf direcotry.
My Client:
package test;
public class Client {
public static void main(String[] args) {
CalculatorService svc = new CalculatorService();
Calculator calc = svc.getCalculatorPort();
System.out.println("2 + 2 = " + calc.add(2, 2));
}
}
I`ve put client.keystore, client.truststore, jboss-wsse-client.xml and standard-jaxws-client-config.xml to meta-inf directory.
When I deploy server, I can see wsdl file. But when I run the client i get :
Exception in thread "main" javax.xml.ws.WebServiceException: Failed to access the WSDL at: http://localhost:8080/calc/ca
lculator?wsdl. It failed with:
Connection refused: connect.
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
at javax.xml.ws.Service.<init>(Unknown Source)
at test.CalculatorService.<init>(CalculatorService.java:40)
at test.Client.main(Client.java:12)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at sun.net.NetworkClient.doConnect(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.openServer(Unknown Source)
at sun.net.www.http.HttpClient.<init>(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.http.HttpClient.New(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.URL.openStream(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.createReader(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.resolveWSDL(Unknown Source)
... 8 more
Can anyone help me?
Marcin Ostachowski
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521875#521875
14 years, 12 months
[JCA Development] New message: "Re: JBJCA-260: New WorkManager"
by David Lloyd
JBoss development,
A new message was posted in the thread "JBJCA-260: New WorkManager":
http://community.jboss.org/message/521849#521849
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> jesper.pedersen wrote:
> [..]
> We need to define datastructures such that the WorkManager API:
> http://java.sun.com/javaee/6/docs/api/javax/resource/spi/work/WorkManager...
>
> can be implemented.
>
> The WorkManager should reference two thread pools at first:
>
> 1. Short running tasks (default)
> 2. Long running tasks (tasks with HintsContext.LONGRUNNING_HINT set)
>
> Later we can add support for additional thread pools with custom JBoss hints - such as LOWPRIORITY_HINT and HIGHPRIORITY_HINT.
Sounds good. In order to implement WorkManager, you need to be able to execute tasks in three different ways:
1. Block the calling thread until the work is complete (with an optional task submission timeout and callbacks)
2. Block the calling thread until the work is accepted (with an optional task submission timeout and callbacks)
3. Do not block the calling thread (with an optional task submission timeout and callbacks)
In addition, the callbacks which must be supported include:
1. Work accepted (i.e. the executor queued the task)
2. Work started (i.e. a thread began executing the task)
3. Work completed (i.e. the runnable finished, with or without an exception)
4. Work rejected (i.e. the executor could not accept the task, or the submission timeout expired before the task started)
I just committed a new version of JBoss Threads into trunk (2.0.0.CR2) which includes a new type, BlockingExecutor, which includes these methods:
package org.jboss.threads;
public interface BlockingExecutor extends Executor {
// [...]
void executeBlocking(Runnable task) throws RejectedExecutionException, InterruptedException;
void executeBlocking(Runnable task, long timeout, TimeUnit unit) throws RejectedExecutionException, InterruptedException;
void executeNonBlocking(Runnable task) throws RejectedExecutionException;
// [...]
}
All JBoss Threads executors now implement this interface. With this new executor interface, along with simple wrapper Runnables, all the above requirements should be easily implemented. Unfortunately this means that the JCA implementation will need a hard dependency on jboss-threads, because there is no java.util.concurrent equivalent to these methods.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521849#521849
14 years, 12 months
[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Flavia Rainone
JBoss development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/521819#521819
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
I've been testing the trunk version of jboss classpool (with the cache disabled) with AS trunk, and the AOP tests are not passing.
I discovered that the classes are not being woven because the weaving proccess throws a CannotCompileException, indicating that wrapped methods do not exist. The exception is thrown at the moment that code that invokes the wrapped method is generated (dispatch method).
The trigger of this exception is the classpool, that is returning a new, fresh, CtClass instance of the class being woven. Instead, the classpool should return the modified CtClass instance, the one that contains the wrapped method renamed. I'll continue investigating to find out why are the classpools behaving this way.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521819#521819
14 years, 12 months