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

[Design the new POJO MicroContainer] - Re: GenericBeanFactory and install methods

by scott.stark＠jboss.org

A little more fleshed out: | /** | * A factory for creating a collection of related mc beans based on a | * template of BeanMetaData[] from a BeanMetaDataFactory. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ComponentFactory | { | /** | * the factory which defines template BeanMetaData[] for the components | * @return the BeanMetaDataFactory defining the component beans | */ | public BeanMetaDataFactory getFactory(); | | /** | * Install a collection of mc beans based on the factory metadata. | * | * @param baseName - the base bean name used in conjuction wth the factory.getBeans() | * BeanMetaData instances getName() to build the unique bean name: | * baseName + bmd.getName() + "#" + compID; | * @return the list of mc bean names installed. | */ | public List<String> createComponents(String baseName); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142624#4142624 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142624

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: GenericBeanFactory and install methods

by scott.stark＠jboss.org

And going through this again, its probably nothing more than another pattern on top of existing mc notions: | interface ComponentFactory | { | List<String> createComponent(String baseName); | } | | class GenericComponentFactory implements KernelControllerContextAware | { | BeanMetaDataFactory componentsFactory; | int compID; | | List<String> createComponent(String baseName) | { | int nextID = incCompID(); | KernelController controller = ...; | List<BeanMetaData> compBeans = componentsFactory.getBeans(); | for(BeanMetaData bmd : compBeans) | { | String beanName = baseName + bmd.getName() + "#" + nextID; | controller.install(beanName, bmd); // Ignoring there is no install taking the bean name | compNames.add(beanName); | } | return compNames; | } | } | The ComponentFactory/GenericComponentFactory would be used similar to how BeanFactory/GenericBeanFactory are currently. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142612#4142612 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142612

18 years

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Used of JGroups shared transport in AS 5

by galder.zamarreno＠jboss.com

Brian, thanks very much for the detailed information on shared transport vs multiplexer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142610#4142610 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142610

18 years

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Checking in Eclipse project files into Remoting 3 repository

by trustin

I've just managed to import all Remoting 3 components into Eclipse. For those who will try to import Remoting 3 into their Eclipse workbench, I thought it might be a good idea to check in the project files into the source code repository. I know it's not really a good idea to check in files which is specific to a certain IDE, but configuring all the classpaths and project dependencies is a time-consuming task. Moreover, Remoting 2 already has Eclipse IDE files in the repository. If we are not going to migrate to Maven 2, we could check in our IDE files meanwhile although it might be pain in the butt to maintain two files - build.xml and .classpath (and probably IntelliJ ones?) WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142607#4142607 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142607

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: GenericBeanFactory and install methods

by scott.stark＠jboss.org

Thinking about this more, talking with Carlo, what we really need is a MetaGenericBeanFactory: | interface MetaBeanFactory extends BeanFactory | { | BeanMetaData createBeanMetaData(); | } | whose contract is to create the BeanMetaData for the bean and then install that into the mc when createBean() is called. This way create lifecycle events like PostConstruct can be delegated to the mc as well as the install callbacks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142598#4142598 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142598

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: jbossws-common vs. jbossws-framework

by richard.opalka＠jboss.com

I don't know the background of decision to keep separate common and framework code bases. However it doesn't make a sence to me :( For me both framework and common are both common. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142590#4142590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142590

18 years

1
0
0 / 0

[Design of JBoss Web Services] - jbossws-common vs. jbossws-framework

by thomas.diesler＠jboss.com

Folks, please remind me why we have jbossws-common *and* jbossws-framework. Apart from: "yada yada ... academic .. yada yada" - that I have probably come up with myself. Is there any real use to maintain the jbossws-common code base separately? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142565#4142565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142565

18 years

1
0
0 / 0

[Design the new POJO MicroContainer] - GenericBeanFactory and install methods

by scott.stark＠jboss.org

An issue I have with creating a custom BeanFactoryMetaData instance that models an ejb container is that I want to have the ejb interceptors added to the ejb bean context via install methods. The custom BeanFactoryMetaData (org.jboss.test.kernel.deployment.support.container.BeanContextFactory) creates 4+ BeanMetaDatas: 1. GenericBeanFactory(BeanContext) - is the bean factory for creating the bean component consisting of: 2 - bean context 3 - + bean instance 4 - + 0 or more bean interceptors The BeanMetaData for the interceptors wants to install the interceptor bean into the BeanContext by calling the addInterceptor method. However, the BeanMetaData for the BeanContext if the GenericBeanFactory. There is no notion of the GenericBeanFactory acting as a proxy for the BeanContext instances in terms of install/uninstall callbacks. Its not obvious how this can be supported in the current impl as the GenericBeanFactory.createBean instances are themselves not mc beans with a name that could be used with the interceptor install metadata. Ideas on how to do this, add support for it? See the org.jboss.test.kernel.deployment.test.BeanContainerUsageTestCaseMD.testComponentBeanFactory for the current wiring. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142548#4142548 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142548

18 years

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Hot deploying an ear -- issues

by eartromick

We have an ejb project deployed as an exploded ear. When we make a change in the ejb jar itself -- we can touch the ejb-jar.xml and the ejb will be redeployed. If, however we make changes to another jar that the ear depends on -- (exploded deploy as well) the change is not picked up when we touch the ejb-jar.xml. Is there a way to achieve what we want without dumping all our class files into the ejb.jar and deploying that exploded? TIA Eric View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142513#4142513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142513

18 years

1
0
0 / 0

[Design of JBoss Profiler] - Re: cannot ant or build profiler

by clebert.suconic＠jboss.com

I have been reported about problems with Solaris, so I'm not sure if this is going to work well. if you are looking for the jvmpi implementation go to ./jvmpi-lib/solaris and run ./compile if you are looking for the jvmti implementation (memory profiler only) go to ./jvmti-lib/solaris On the jvmti I have already added autoconf, so you could go cd ./jvmti-lib and call the bootstrap script there (but you will need gnu autotools installed) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142500#4142500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142500

18 years

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