[Design of JBoss Web Services] - WSContractConsumer API in a seam app
by maeste
Hi,
We are rewriting the core of our generic web based ws client (I spoke about it here some days ago) using a more standard and mantainable core based on JAX-WS and in particular on WSContractConsumer runtime API.
We already done the most important steps of the job and all our test cases works perfectly.
Now we are experincing problems when we deploy our apps (a seam ear) on jboss 4.0.5 with, of course, jbossws from the svn trunk.
The problem is that WSContractConsumer doesn't generate .class file (but .java is generated correctly) when used inside the jboss container. The same class used out of container by our junit test case works perfectly.
Here is the init method of our class:
| public void init(String wsdlURL) {
| try {
| WSContractConsumer wsImporter = WSContractConsumer.newInstance();
| wsImporter.setGenerateSource(true);
| File outputDir = new File("/home/oracle/testImp/tmp/");
| wsImporter.setOutputDirectory(outputDir);
| wsImporter.setSourceDirectory(outputDir);
| String tagetPkg = "it.javalinux.ws";// + (new Random()).nextInt();
| wsImporter.setTargetPackage(tagetPkg);
| wsImporter.consume(wsdlURL);
|
|
| FilenameFilter filter = new FilenameFilter() {
| public boolean accept(File dir, String name) {
| return name.endsWith("Service.class");
| }
| };
| File scanDir = new File("/home/oracle/testImp/tmp/it/javalinux/ws/");
| System.out.println(scanDir);
| String[] a = scanDir.list();
| for (int i = 0; i < a.length; i++) {
| System.out.println(a);
|
| }
|
| String[] children = scanDir.list(filter);
| String className =null;
| if (children != null) {
| className = children[0].substring(0, children[0].length() - 6);
|
| }
|
| classLoader = new URLClassLoader(new URL[]{outputDir.toURL()}, Thread.currentThread().getContextClassLoader());
| //URLClassLoader classLoader = new URLClassLoader(new URL[]{outputDir.toURL()}, Thread.currentThread().getContextClassLoader());
| Thread.currentThread().setContextClassLoader(classLoader);
|
| serviceClass = JavaUtils.loadJavaType("it.javalinux.ws." + className , classLoader);
| service = serviceClass.newInstance();
| } catch (Exception e) {
| e.printStackTrace();
| }
| }
|
What's happen is, as already said, that we find only .java file in this directory and not .class file. We don't get any exception from WSContractConsumer.
Any ideas?
Thanks in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4018523#4018523
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4018523
19 years, 1 month
Re: cts ejb2 webservices
by Jason T. Greene
Hi Alexey,
I created a jira issue against 1.2.0 on this:
http://jira.jboss.com/jira/browse/JBWS-1527
-Jason
On Wed, 2007-02-14 at 14:27 +0100, Alexey Loubyansky wrote:
> Could you guys please check these
> Folder: com/sun/ts/tests/ejb/ee/webservices/allowedmethodstest
>
> Prorbably a configuration issue.
>
> Thanks,
> Alexey
>
>
> 02-14-2007 14:10:53: ERROR: java.rmi.RemoteException: Call invocation
> failed; nested exception is:
> org.jboss.remoting.CannotConnectException: Can not connect http client
> invoker.
> at
> org.jboss.ws.core.jaxrpc.client.CallImpl.invokeInternal(CallImpl.java:520)
> at org.jboss.ws.core.jaxrpc.client.CallImpl.invoke(CallImpl.java:273)
> at org.jboss.ws.core.jaxrpc.client.PortProxy.invoke(PortProxy.java:151)
> at $Proxy3.businessMethod(Unknown Source)
> at
> com.sun.ts.tests.ejb.ee.webservices.allowedmethodstest.bm.Client.wsbmAllowedMethodsTest1(Client.java:151)
>
19 years, 1 month
meaningful javadocs required for sample tests
by Thomas Diesler
Heiko,
these are bad samples tests if they don't tell the user what is actually
being tested. Please add
meaningful javadocs.
/**
* @author Heiko Braun <heiko.braun(a)jboss.com>
* @since 05.12.2006
*/
public class XOPHandlerTestCase extends XOPBase
/**
* @author Heiko Braun <heiko.braun(a)jboss.com>
* @since 05.12.2006
*/
public class XOPTestCase extends XOPBase
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 1 month
Re: Explanation on how JBoss WS handles port numbers?
by Darran Lofthouse
I am going to need some more time to look at the WSRP stuff but here is
some background on the address being set to the https address in the
WSDL.
There are two almost independent areas of code responsible for setting
the address in the WSDL, the first part is the configuration.
Defined in the descriptor jboss-beans.xml there is the
'ServiceEndpointManager' bean, this bean can be used to set the web
service port and the web service secure port.
Anything that calls the get methods for these two values will receive
the values that were configured. If the values have not been set the
'ServiceEndpointManager' will use the 'ServerConfig' to retrieve these
values, for JBoss this bean queries all the connector MBeans to find out
what the non-secured and secured ports are.
If the MBeans can not be found it defaults to 8080 and 8443 and logs a
warning. If multiple connectors are found it uses the first connector
found and logs a warning.
That is the total code change that went into JBWS1115.
The second part is existing code within JBossWS that decides which port
to use, this existing code is based on if the transport guarantee has
been set in the web.xml or jboss.xml.
Looking at the forum posts I am initially suspecting that the transport
guarantee is not set in the appropriate descriptor, as they have defined
a https connector they can access the WSDL over https but this is not
enough for the address in the WSDL to be set to https.
Separately to this there has been another patch added to JBossWS to
dynamically rewrite the address in the WSDL based on the address the
client used to access the WSDL, this might be more what your users are
expecting - I need to do some further work on this for JBossWS 1.2.1
Regards,
Darran Lofthouse.
On Thu, 2007-02-15 at 11:37 -0500, Chris Laprun wrote:
> Hi Darran,
>
> On Feb 15, 2007, at 11:27 AM, Darran Lofthouse wrote:
>
> > Do you have any examples of the issues they are experiencing?
>
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101445
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=100461
>
> Could you review: http://wiki.jboss.org/wiki/Wiki.jsp?page=WSRPUseSSL
> and http://wiki.jboss.org/wiki/Wiki.jsp?page=WSRPChangePorts for
> accuracy and to let me know if there is a better way to do these?
>
> Also, is there any training material that I could look at since I'd
> like to improve my proficiency with WS?
>
> Thanks in advance.
>
> Best,
> Chris
>
> ==
> JBoss Portal Developer / WSRP Lead
> JBoss, a division of Red Hat
>
>
19 years, 1 month
Auto discover HTTP(S) port configuration from Tomcat
by Thomas Diesler
Darran,
Testsuite: org.jboss.test.ws.jaxrpc.jbws1115.JBWS1115TestCase
Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 1.127 sec
fails in jbossws-1.2.0. Is this supposed to work?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
19 years, 1 month
Re: Explanation on how JBoss WS handles port numbers?
by Darran Lofthouse
Do you have any examples of the issues they are experiencing?
Regards,
Darran Lofthouse.
On Thu, 2007-02-15 at 11:23 -0500, Chris Laprun wrote:
> On Feb 15, 2007, at 10:53 AM, Thomas Diesler wrote:
>
> > > Ideally, no changes would be required in our web service
> > configuration (i.e. we don't want our users to have to change
> > several configuration files).
> > > It seems like it is currently the case with 1.0.4. Is this correct?
> >
> > Yes that is correct. Unless JBWS-1115 is truly resolved (which you
> > claim it is not) the user will have to modify the jbossws
> > configuration.
>
> In my experience, JBWS-1115 is fixed. However, some of our users are
> still experiencing issues with port numbers, especially when it comes
> to using HTTPS.
>
> > > can someone look at http://jira.jboss.com/jira/browse/JBWS-1515
> >
> > I commented.
>
> Thanks.
>
> Best,
> Chris
>
> ==
> JBoss Portal Developer / WSRP Lead
> JBoss, a division of Red Hat
>
>
19 years, 1 month
