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

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New transport: Determining oneway messages

by timfox

Ok good. One more thing - if a packet can be sent one way or blocking, it doesn't really make sense to call the packets XXXRequest any more. We should probably rename all the XXRequest and XXResponse classes just to XXXMessage View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124085#4124085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124085

16 years, 11 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: how to define global variables for process in xml

by inxaoc

But what's not wrong forum? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124082#4124082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124082

16 years, 11 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Tomcat Deployer is wrong in JBoss Head

by adrian＠jboss.org

Looking at the AbstractWarDeployer this looks ok to me. So the first step would be to seperate out the runtime part of TomcatDeployer into a TomcatService or something that is constructed in deploy. Other things that look wrong are things like: | config.setSecurityManagerService(this.secMgrService); | where secMgrService is a link to the object rather than the name. This kind of think should be configured in the ServiceMetaData as an injection based on a name. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124072#4124072 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124072

16 years, 11 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Tomcat Deployer is wrong in JBoss Head

by adrian＠jboss.org

The first step doesn't need to be very complicated. We just need to logically seperate the deployment chain from the runtime. Migrating to POJOs isn't a requirement. You can leave all the classes in the jbossweb.deployer deployment for now, there's no need to seperate immediately runtime classes from deployment classes. If you look at jbossweb.deployer/META-INF/war-deployer-beans.xml it contains a number of deployers but these mix the deployment process with the runtime. What we want is a 1) deployers/jbossweb.deployer that is just the deployers and handles the metadata (constructing ServiceMetaData for the individual web apps) 2) deploy/jbossweb this is the runtime that the mbeans above get deployed into In more detail, the current deployers are 1) WebAppParsingDeployer Ok, this parses the web.xml to create a WebMetaData 2) JBossWebAppParsingDeployer Adds the jboss-web.xml to the WebMetaData (again ok, except the loader repository stuff which shouldn't be in the parsing layer) 3) WebAppClusteringDefaultsDeployer This is ok. It just modifies the WebMetaData to add defaults 4) WebAppClusteringDependencyDeployer Again just modifies the metadata to add dependencies that will later be used by the mbean deployment 5) WarDeployer This is what is wrong. It does at least two things 5a) It configures Tomcat 5b) It creates the ServiceMetaData that represent web deployments My guess is that it also handles some of the runtime process of that ServiceMetaData as well? Instead what should happen is that the runtime processing (configuration of the connectors and the other bits associated Tomcat's runtime in the server.xml) should be in deploy/jboss-web as a seperate service. The MBean that gets constructed from the ServiceMetaData will interact with this seperate runtime. In summary, the deployers should just be deailing with the metadata {jboss-}web.xml -> WebMetaData -> ServiceMetaData this ServiceMetaData will then desribe a WebDeployment MBean that will interact with the runtime services to create the actual WAR. Once that is done, we will no longer neded to pull lots of services like the transaction manager or the CachedConnectionManager into the bootstrap just to satisfy the Tomcat deployer's dependency on them. The clustering part of the WAR deployment has it correct, in that the dependencies are just names (not implementation) that will be satiisfied when those services are deployed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124067#4124067 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124067

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Checking DeploymentContext for failures

by alesj

I've added that piece of missing code. That's really the part that picks up BeanMetaData and ServiceMetaData runtime components, and checks if they are complete. In order to fix JBAS-4292, this would require new MC release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124061#4124061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124061

16 years, 11 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: some enhancements to jboss-test

by akostadinov

I'm going to commit the above change this week if nobody complains. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124057#4124057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124057

16 years, 11 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Tomcat Deployer is wrong in JBoss Head

by remy.maucherat＠jboss.com

It would be good if you did the packaging and the basics of that new web deployer, moslty with a minimal mostly hardcoded configuration for the servlet container, and I would then do the handling of the configuration that is in server.xml at the moment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124055#4124055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124055

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ProfileService shutdown and undeploy order

by sacha.labourey＠jboss.com

"bstansberry(a)jboss.com" wrote : The HAPartition bean is just doing this in stopService(): | | ctx = new InitialContext(); | ctx.unbind(boundName); | | In startService() it's more complicated, but essentially creates a new default InitialContext and does a rebind. So, no accessing a different dependency in stopService(). | | The bean has a depends on jboss:service=NamingService. | | ( BTW, maybe we should have a notion of implicit services applied to multiple inner-services i.e. a wrapping tag applied to multiple inner-service definitions so that it would be possible to assign global "services" (or default services) en masse. Things like the naming service for example, while a singleton today, might not be a a singleton anymore tomorrow (if we want to make JBoss AS 5.x a "multi-tenant" implementation i.e. SaaS hosting infrastructure for example). ) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124048#4124048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124048

16 years, 11 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Upgrade to Drooles-4.0.4

by mark.little＠jboss.com

Thanks. The Drools team report that this looks like the same issue they fixed a while ago. JBossESB 4.2.1 CP1 supports Drools 4.0.4. You can always check it out from svn yourself if you want. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124045#4124045 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124045

16 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Class loading debugging

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | "adrian(a)jboss.org" wrote : | | There's no such thing in general. If the policy is a VFSClassLoaderPolicy | | then you can ask what its VFS roots are and you could ask what other policies | | it can see that are VFSClassLoaderPolicys or URLClassLoaders. | | But the new classloading system has been designed to be flexible. | | There's no direct dependency of URLs/VFS etc. Somebody can implement | | a policy how they want. | It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible. | We can ask each ClassLoaderPolicy to implement a getURLs() for management purposes. For deployment generated classloaders its really just the same as getClassPath() on the deployment unit. But that doesn't mean that something should use those URLs as a classpath. Parts of the filesystem the url represents could be filtered out e.g. 1) your excluded packages example 2) the OSGi uses constraint where a deployment may contain jms.jar but declare it as "uses". i.e. it will actually use our jms classes 3) for importAll, a previously deployed classloader may mask some classes if they appear in two classloaders (only the first gets used) etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4124043#4124043 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4124043

16 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008