October 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by scott.stark＠jboss.org

"ron.sigal(a)jboss.com" wrote : By the way, I'm not sure what you mean by "the jboss thirdparty repository". There's a jboss-remoting-2.2.2.GA-src.tar.gz, for example, in http://repository.jboss.com/jboss/remoting/2.2.2.GA-brew/src/. Should it be somewhere else as well | | Also, Remoting still lives in the CVS repository: cvs.forge.jboss.com/cvsroot/jboss/JBossRemoting . That is not a location that is pulled down by the thirdparty mechanism, and the format is not usable in an eclipse sourcepath. There needs to be a zip/jar compatible archive that is declared in the component-info.xml as an archive, but not in the export list: | <component id="jboss/remoting" | licenseType="lgpl" | version="2.2.2.SP2" | projectHome="http://www.jboss.org/products/remoting" | description="a single API for most network based invocations and related service that uses pluggable transports and data marshallers"> | | <artifact id="jboss-remoting.jar"/> | <artifact id="jboss-remoting-sources.jar"/> | | <import componentref="jboss/serialization"> | <compatible version="1.0.0.GA"/> | <compatible version="1.0.1.GA"/> | <compatible version="1.0.2.GA"/> | <compatible version="1.0.3.GA"/> | <compatible version="1.0.3.GA-brew"/> | </import> | <export> | <include input="jboss-remoting.jar"/> | </export> | </component> | | </project> | Looking at https://svn.jboss.org/repos/repository.jboss.org/jboss/remoting/2.2.2.SP2... I see a jboss-remoting-2_2_2_SP2.zip, but this is way too big to be just the source of the classes going into the jboss-remoting.jar. That is all the jboss-remoting-sources.jar should be. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098621#4098621 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098621

18 years, 5 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Any limitation on numbers of webwar deployed

by amitavc

I like to know if is there any limitation on numbers of webwar can run on a single instance of JBoss. Or if there is number which says the optimum web war should deployed in Jboss instance to perform better. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098620#4098620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098620

18 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by ron.sigal＠jboss.com

I told Tim and Clebert about this thread, just in case I missed something in JBossMessaging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098617#4098617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098617

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by ron.sigal＠jboss.com

By the way, I'm not sure what you mean by "the jboss thirdparty repository". There's a jboss-remoting-2.2.2.GA-src.tar.gz, for example, in http://repository.jboss.com/jboss/remoting/2.2.2.GA-brew/src/. Should it be somewhere else as well Also, Remoting still lives in the CVS repository: cvs.forge.jboss.com/cvsroot/jboss/JBossRemoting . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098616#4098616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098616

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Duplicate mbean removal

by scott.stark＠jboss.org

Ok, then need to figure out what is removing it. It must be something else trying to do a global cleanup of mbeans on shutdown. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098615#4098615 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098615

18 years, 5 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design of EJB 3.0] - new version of JBoss embedded ejb3 container

by r_sudh

The below link has the download for the embedded JBoss EJB3 container. http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=13... But the release is from back in 2005. Since this release, there are some bug fixes such as http://opensource.atlassian.com/projects/hibernate/browse/EJB-46 Is there any chance that a new version of the embedded EJB3 container will be released sometime soon. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098567#4098567 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4098567

18 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007