[Design of JBoss Web Services] - JBoss equivalent of clientGen of WL
by JBoss_82
Hi,
I am using the top-down approach by starting with the WSDL. I am trying to figure out a mechanism in JBoss 4.2.2 with jbossws-native2.0.1 which is equivalent of WL's clientgen. Objective is to generate a client-jar which can be used by the client program to consume the web service.
Sample WL clietgen task:
| <taskdef name="clientgen" classname="weblogic.ant.taskdefs.webservices.clientgen.ClientGenTask"
| classpathref="clientgen.class.path"/>
|
| <target name="McAfee">
| <clientgen wsdl="macafeeAdapterContract.wsdl"
| packageName="com.covad.vendororder"
| typePackageName="com.covad.vendororder.xsd"
| clientJar=".\mcafeeadapter-client.jar">
| <classpath refid="clientgen.class.path" />
| </clientgen>
| </target>
|
anonymous wrote : I know there is a crude way of using the client artifacts generated by "wsconsume", zip those class files and create a client-jar, but I want to know if there's a better way to do this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098618#4098618
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098618
18 years, 5 months
[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal
by ron.sigal@jboss.com
Sorry, my explanation was off base.
The Connector isn't registering itself - it's creating and registering an org.jboss.remoting.ServerInvoker (BisocketServerInvoker, in this case). As you say, the Connector is acting as a container for the ServerInvoker. The Connector appears in a *-service.xml file, and the ServerInvoker does not.
So, registering and unregistering the ServerInvoker makes sense, I think. The question is, why is Connector.stop() not finding the ServerInvoker's object name? If, for some reason, there was a problem registering the ServerInvoker, the log should have the output of
| log.warn("Error registering invoker " + invoker + " with MBeanServer.", e);
|
I was wondering if maybe JBossMessaging is programmatically stopping the Connector, leaving the ServerInvoker's object name unregistered, so that when the ServiceController stops the Connector, the object name isn't there. However, I see that the Connector is injected into two JBM MBeans (org.jboss.jms.server.ServerPeer and org.jboss.jms.server.connectionfactory.ConnectionFactory), and it doesn't look like either of those is doing it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098612#4098612
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098612
18 years, 5 months
[QA of JBoss Portal] - Re: Portlet Container test framework update
by julien@jboss.com
Another example of a more complex test case using the "method" style:
@TCK({5,6,8})
| public class ExceptionsOnInit
| {
|
| @JoinPoint(portletId=PortletExceptionDuringInitPortlet.NAME)
| public DriverResponse a(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| PortletExceptionDuringInitPortlet.rendered = true;
| return null;
| }
|
| @JoinPoint(portletId= RuntimeExceptionDuringInitPortlet.NAME)
| public DriverResponse b(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| PortletExceptionDuringInitPortlet.rendered = true;
| return null;
| }
|
| @JoinPoint(portletId= UnavailableExceptionDuringInitPortlet.NAME)
| public DriverResponse c(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| UnavailableExceptionDuringInitPortlet.rendered = true;
| return null;
| }
|
| @JoinPoint(portletId= UTP1.NAME)
| public DriverResponse d(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| return new InvokeGetResponse(response.createRenderURL().toString());
| }
|
| @JoinPoint(count=1, portletId=UTP1.NAME)
| public DriverResponse e(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| return new InvokeGetResponse(response.createRenderURL().toString());
| }
|
| @JoinPoint(count=2, portletId=UTP1.NAME)
| public DriverResponse f(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context)
| {
| //portlets shouldn't render itself
| assertEquals(false, PortletExceptionDuringInitPortlet.rendered);
| assertEquals(false, UnavailableExceptionDuringInitPortlet.rendered);
| assertEquals(false, RuntimeExceptionDuringInitPortlet.rendered);
|
| //and shouldn't be destroyed as Exceptions on init() were throwed
| assertEquals(false, PortletExceptionDuringInitPortlet.destroyed);
| assertEquals(false, UnavailableExceptionDuringInitPortlet.destroyed);
| assertEquals(false, RuntimeExceptionDuringInitPortlet.destroyed);
|
| //
| return new EndTestResponse();
| }
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098590#4098590
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098590
18 years, 5 months
[QA of JBoss Portal] - Re: Portlet Container test framework update
by julien@jboss.com
The other way to do would be to use some public field which would allow a more typed approach and enforce the contract with the different actions:
@TCK(4)
| public class InitializeBeforeHandle
| {
| @JoinPoint(portletId = InitializeBeforeHandlePortlet.NAME)
| public PortletRenderTestAction tmp = new PortletRenderTestAction()
| {
| protected DriverResponse run(Portlet portlet, RenderRequest request, RenderResponse response, PortletTestContext context) throws PortletException, IOException
| {
| Assert.assertTrue(InitializeBeforeHandlePortlet.init);
| return new EndTestResponse();
| }
| };
| }
it is a bit more cluttered but enforces the contract. I remind here that the goal is to provide a way to break down a test spanning several classes (different portlets + servlet) of a same test case into one single place in order to make the test easy to read/write and share a common state.
Ideas are welcome.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098588#4098588
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098588
18 years, 5 months