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

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by alesj

"anil.saldhana(a)jboss.com" wrote : | The apostle from Slovania makes a point. ;) Read my location more precisely and do a copy/paste, since your geography sucks. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131401#4131401 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131401

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: ServiceMetaData has the most recent dependencies/attribu

by anil.saldhana＠jboss.com

"alesj" wrote : "adrian(a)jboss.org" wrote : Anyway, this is an issue brought up by Ales that is unrelated to the actual topic. ;-) | Eh, I always like to bother people when they want to change metadata, related or unrelated. :-) The apostle from Slovania makes a point. ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131399#4131399 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131399

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : | 1) EJBDeployer attaches ServiceMetaData | 2) WebServiceDeployerEJB generates and attaches JBossWebMetaData | 3) TomcatDeployer also attaches ServiceMetaData | If there's a conflict of attachment names between these deployers (and you need these in the same deployment) then we need to get people together to come up with unique attachment names. Like I said above, the only time the attachment needs to be called ServiceMetaData.class.getName() is when it becomes a component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131396#4131396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131396

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : | my proposed fix is | ... | Please review. I be happier if you proposed and asked before you committed. Now you'll have to unpick it all since you just reinvented the wheel again. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131394#4131394 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131394

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer

by adrian＠jboss.org

No, you don't create the components yourself. You leave that to the component deployer. The key part is that the attachment doesn't have to be named ServiceMetaData.class.getName(). Most people call it that, but that's just a convention. (It's always called that at the component level though). The component deployer looks for any attachment that implements the type, it's doesn't care what it is called and creates a component for it. JMX component deployer http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/m... Helper http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... | protected void deployComponents(DeploymentUnit unit) throws DeploymentException | { | if (compVisitor == null) | return; | | Set<? extends C> components = unit.getAllMetaData(getOutput()); | for (C component : components) | compVisitor.deploy(unit, component); | } | And because it uses a visitor pattern, it knows how to unwind errors. Your version suffers from the usual, "I'm not going to bother to tidyup if I get an error part way through" bug. Which is just going to lead to "InstanceAlreadyExists" errors in the MBeanServer when you try to redeploy. >From a brief look at the code you posted, it breaks the following basic design princples of the deployers 1) It sidesteps the deployer chain with one deployer calling another directly 2) Since the metadata is deleted it won't be available to the management tool 3) It doesn't create components for the individual services, so there's no way the IncompleteDeploymentException to know which MBeans are part of the deployment and give a reasonable error message. Finally, there already is a ServiceMetaDataSet, its called a ServiceDeployment http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/system-jmx/src/m... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131393#4131393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131393

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deploying multiple service through the ServiceDeployer

by alesj

No, this is already taken care of. You just need to create new component on the deployment unit, with your new ServiceMetaData attached. See ServiceDeploymentDeployer fore more details. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131388#4131388 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131388

18 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Deploying multiple service through the ServiceDeployer

by thomas.diesler＠jboss.com

Folks, I have/had an issue with a deployment wanting to create multiple services 1) EJBDeployer attaches ServiceMetaData 2) WebServiceDeployer generates and attaches JBossWebMetaData 3) TomcatDeployer also attaches ServiceMetaData my proposed fix is | // In case there already is a ServiceMetaData object attached, we use a set | ServiceMetaData prevService = unit.getAttachment(ServiceMetaData.class); | if (prevService != null) | { | ServiceMetaDataSet services = new ServiceMetaDataSet(); | services.add(prevService); | services.add(webModule); | unit.addAttachment(ServiceMetaDataSet.class, services); | unit.removeAttachment(ServiceMetaData.class); | } | else | { | unit.addAttachment(ServiceMetaData.class, webModule); | } | and a new deployer | public class MultipleServicesDeployer extends AbstractSimpleRealDeployer<ServiceMetaDataSet> | { | private ServiceDeployer serviceDeployer; | | public MultipleServicesDeployer() | { | super(ServiceMetaDataSet.class); | } | | public void setServiceDeployer(ServiceDeployer serviceDeployer) | { | this.serviceDeployer = serviceDeployer; | } | | @Override | public void deploy(DeploymentUnit unit, ServiceMetaDataSet deployment) throws DeploymentException | { | Iterator<ServiceMetaData> it = deployment.iterator(); | while (it.hasNext()) | { | ServiceMetaData service = it.next(); | unit.addAttachment(ServiceMetaData.class, service); | try | { | serviceDeployer.deploy(unit, service); | } | finally | { | unit.removeAttachment(ServiceMetaData.class); | } | } | } | ... | | | | | Please review. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131387#4131387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131387

18 years, 1 month

1
0
0 / 0

[Design of JBoss Portal] - Re: Can't visit my JBoss Portal website on internet

by thomas.heute＠jboss.com

Try: sh run.sh -b or sh run.sh -b 0.0.0.0 to use all network interfaces. It used to be the default, very convenient for developers but it had to change... Now it only listens on localhost by default. (Then blame the so called independent security analysts and people denigrating a piece of software by looking at the number of security holes found ;)) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131386#4131386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131386

18 years, 1 month

1
0
0 / 0

[Design of POJO Server] - Re: JMS Topics/Queues in ProfileService

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Its going to depend on the underlying runtime component providing the stats. The ds don't have them because the pools are not created until needed. | If it's just an issue of lazy pool construction then add something like the following to your test -ds.xml | <min-pool-size>2</min-pool-size> | <prefill/> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131349#4131349 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131349

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - ClassLoader for a subdeployment

by adrian＠jboss.org

One of the things left to do is the managed classloader for a subdeployment. This is so we can use the new classloader framework for the war classloader which would include having OSGi style imports for the isolated wars. The way I'm planning to do it, is that if a subdeployment has a ClassLoadingMetaData then it will trigger this processing. The subdeployment will become a classloading "Module" in its right, capable of importing dependencies that are different to the main classloader of the deployment. Also, its ClassPath will NOT be included in the main classloader classpath. For the war classloader I expect this to be triggered by a specific deployer that decides that wars should get their own classloader and what the default policy should be, e.g. excluded classes, parent first, etc. The are some gotchas: OLD LOADER REPOSITORY CONFIG Previously we only checked for subdeployment classloader config for a war (and then only if the useJBossClassloade was configured). e.g. a loader repository config in a jboss.xml of a nested ejb jar would be ignored. With this new feature, it wouldn't be ignored anymore and the nested ejb would get its own subclassloader. We can probably fix this in the "hack" that ignores it for non-wars or at least add a warning? PARENTS There are two ways to implement it, both have issues. 1) Just create a classloader with the main deployment classloader as the parent. This may run into the circularity issue in the Sun Classloader, although, I haven't seen it myself with the Tomcat classloader doing this? 2) With the new classloader we can create an hierarchical domain with the main deployment classloader as parent. This would allow us to "schedule" the classloading like we do for other hierarchical domains. But this means creating a domain for the subdeployment classloader (not a big issue), it's more ugly that the "parentDomain" in the metadata would be ignored since the parent is already defined to be the main deployment classloader. PROPOSAL I'm going to try to implement it as (2), since having a domain would also allow multiple copies of a dependency. e.g. two wars with servlet style classloading could OSGi style import apache clogging and we could let them have their own singletons/versions of the classes. i.e. for isolated classloading, the import would be a peer clasloader in the sub-deployment's constructed domain not visible to others. JOKE: WAR developers like to have their own singletons and other junk. Admins don't trust them and so like to give them their own sandbox. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131348#4131348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131348

18 years, 1 month

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 February 2008