June 2008 - jboss-dev-forums - Jboss List Archives

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by anil.saldhana＠jboss.com

There is some JBWS309UnitTestCase sitting in the AS test suite that can be used. It is originally part of the JACC test run. But it does not work correctly as I have seen the webapp deployed by JBossWS having no metadata created etc. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=137352 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160590#4160590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160590

17 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by richard.opalka＠jboss.com

"scott.stark(a)jboss.org" wrote : You need to make a copy of the JBossWebMetaData and use setContextRoot("jaxws-endpoint"). Yes we do. We create new JBossWebMetaData from scratch and set context root to "jaxws-endpoint". However it doesn't work :( "scott.stark(a)jboss.org" wrote : We also need this usecase in the jbossas testsuite as an illustration of proper dynamic deployment creation. Yes, we will add this test to JBossAS testsuite soon. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160589#4160589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160589

17 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by adrian＠jboss.org

Nice colours. ;-) I don't see how this is a deployment or classloader issue? If it is going in the wrong tomcat context then you've obviously not setup your JBossWebMetaData correctly. But since you don't show that, and it would be an issue for the Web/Tomcat developers forum if you don't understand its metadata, I can't really help (again). And like I said before. Passing the thread context classloader is almost certainly wrong (but not related to your problem). That is a wrapper classloader created by Tomcat for other purposes, e.g. determining which ENC to use in jndi java:comp/env lookups. You need to drill down through its parents to find the RealClassLoader. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160588#4160588 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160588

17 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by scott.stark＠jboss.org

You need to make a copy of the JBossWebMetaData and use setContextRoot("jaxws-endpoint"). The getPredeterminedManagedObjects attachments bucket is the wrong one to be using. This is for data that is set from previous admin edits through the profileservice. The client spi does not look correct for deployer implementations. We also need this usecase in the jbossas testsuite as an illustration of proper dynamic deployment creation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160587#4160587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160587

17 years, 9 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO deploy webapp dynamically

by richard.opalka＠jboss.com

This is our usecase: We have the jaxws-endpoint-servlet.war web archive with the following content: jar -tvf jaxws-endpoint-servlet.war META-INF/ META-INF/MANIFEST.MF WEB-INF/ WEB-INF/classes/ WEB-INF/classes/org/ WEB-INF/classes/org/jboss/ WEB-INF/classes/org/jboss/test/ WEB-INF/classes/org/jboss/test/ws/ WEB-INF/classes/org/jboss/test/ws/jaxws/ WEB-INF/classes/org/jboss/test/ws/jaxws/endpoint/ WEB-INF/classes/org/jboss/test/ws/jaxws/endpoint/EndpointBean.class WEB-INF/classes/org/jboss/test/ws/jaxws/endpoint/EndpointInterface.class WEB-INF/classes/org/jboss/test/ws/jaxws/endpoint/EndpointServlet.class WEB-INF/wsdl/ WEB-INF/wsdl/TestService.wsdl WEB-INF/web.xml The most important class here is EndpointServlet, which contains the following lines of code: | public void init(ServletConfig config) throws ServletException | { | super.init(config); | | // Create the endpoint | EndpointBean epImpl = new EndpointBean(); | javax.xml.ws.Endpoint endpoint = Endpoint.create(SOAPBinding.SOAP11HTTP_BINDING, epImpl); | | // Create and start the HTTP server | SPIProvider spiProvider = SPIProviderResolver.getInstance().getProvider(); | HttpServer httpServer = spiProvider.getSPI(HttpServerFactory.class).getHttpServer(); | httpServer.start(); | | // Create the context and publish the endpoint | HttpContext context = httpServer.createContext("/jaxws-endpoint"); | endpoint.publish(context); | } | The purpose of this code is to create new web application deployment dynamically using this api only. The endpoint published this way must reside on address http://localhost:8080/jaxws-endpoint where HttpContext and Endpoint are our abstractions. Our current approach: To solve this use case we're creating new web deployment dynamically this way at the moment: | JBossWebMetaData jbwmd = dep.getAttachment(JBossWebMetaData.class); | | AbstractDeployment deployment = createSimpleDeployment(dep.getSimpleName()); | MutableAttachments ma = (MutableAttachments)deployment.getPredeterminedManagedObjects(); | ma.addAttachment(HttpSpec.PROPERTY_GENERATED_WEBAPP, Boolean.TRUE); | ma.addAttachment(ClassLoaderFactory.class, new ContextClassLoaderFactory()); | ma.addAttachment(JBossWebMetaData.class, jbwmd); | mainDeployer.deploy(deployment); | | ... | | private static class ContextClassLoaderFactory implements ClassLoaderFactory | { | public ClassLoader createClassLoader(DeploymentUnit unit) throws Exception | { | return Thread.currentThread().getContextClassLoader(); | } | | public void removeClassLoader(DeploymentUnit unit) throws Exception | { | } | } | Problem we're dealing with: We're not able to dynamically deploy this archive to http://localhost:8080/jaxws-endpoint context. The dynamically created application is deployed to http://localhost:8080/jaxws-endpoint-servlet context. I guess this is because of our custom class loader we have. Is there a possibility to enforce deployment context? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160586#4160586 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160586

17 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing Pointcut Matching

by kabir.khan＠jboss.com

"flavia.rainone(a)jboss.com" wrote : I think that, during implementation, I have spotted a bug. InstanceDomain class, overwites addBinding method. Isn't it supposed to make pointcuts collection consistent, by adding the binding to the pointcuts collection as well? | Probably "flavia.rainone(a)jboss.com" wrote : Plus, do you think it would be worthy to use the classification on the instrumentation stages as well? We could have a classified pointcut collection, similar to the one I wrote for bindings, and the transformers would match only the relevant pointcuts. Yes, I think this is worth implementing. I thought of this while away, but forgot by the time I got back :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160581#4160581 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160581

17 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS HDScanner test

by scott.stark＠jboss.org

The point of the test was to illustrate the current usage that causes locking problems. How one thread can reliably delete a file when there are scanner threads that may have recently been active is what needs to be handled. It does not matter if the deployDir(in general there can be multiple dirs) should be cached from the initial point where the deploy dir uris are setup. There should be a better api than having to set a system property to clear all unused locks. Can't this be incorporated into the VirtualFileHandler delete implementation? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160576#4160576 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160576

17 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing Pointcut Matching

by flavia.rainone＠jboss.com

anonymous wrote : | In this case, I'm going to implement it this week. Let's hope it improves the performance somewhat. | This is implemented now. I am going to commit soon. I think that, during implementation, I have spotted a bug. InstanceDomain class, overwites addBinding method. Isn't it supposed to make pointcuts collection consistent, by adding the binding to the pointcuts collection as well? Plus, do you think it would be worthy to use the classification on the instrumentation stages as well? We could have a classified pointcut collection, similar to the one I wrote for bindings, and the transformers would match only the relevant pointcuts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160571#4160571 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160571

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBPAPP-863 -- FC blocks during slow failure detection

by bstansberry＠jboss.com

The issue of whether to include FC in a config should be better covered in the docs: http://jira.jboss.com/jira/browse/JBAS-5677 Re: mod_jk doing retries, I expect the config described would cause test failures even if there were a much faster failure timeout (say 20-30 seconds). After 8 secs, mod_jk will retry, and this is a counter-based test, so the counter will increase by 2 and you'll get a failure. This illustrates why a retry when the request has reached a server is dangerous. For EJB proxies the clustering logics forbids this. If you want to enable retries, suggest you use the recovery_options parameter (see http://tomcat.apache.org/connectors-doc/reference/workers.html ) and set it to 1 such that retries are not attempted if the request reaches the server. OK, now back to this JIRA and the general testing program. First, besides the good points Bela makes about 2.4.x vs. 2.6.x, I wouldn't want to change config files in a micro release or EAP CP. So, if we don't change the defaults, this becomes a knowledge-base issue. Hence the docs update JIRA, and I know the support guys are aware of this thread. For the general testing program, a bigger cluster is probably better if you're testing what happens when the plug is pulled on a single node. *If* you need to drill further into what happens with a 2 node cluster, then removing FC from your TCP-based config makes sense. We already know the effect FC has, and removing FC from a 2 node TCP config is correct. So removing it will let you check for other effects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160565#4160565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160565

17 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBPAPP-863 -- FC blocks during slow failure detection

by bstansberry＠jboss.com

For the AS 5 change: http://jira.jboss.com/jira/browse/JBAS-5676 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160554#4160554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160554

17 years, 9 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 June 2008