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

[Design of JBoss Web Services] - Re: JAXB in cxf/metro

by richard.opalka＠jboss.com

jaxb is widely used library -> it must take care of bc compatibility -> jaxb 2.1.6 is bc with jaxb 2.1.4 -> cxf works with jaxb 2.1.4 -> cxf will work with jaxb 2.1.6 -> #2 we should let the AS define the jaxb version and not deploy it Just a simple math transitivity ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143070#4143070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143070

18 years

1
0
0 / 0

[Design of JBoss Web Services] - JAXB in cxf/metro

by thomas.diesler＠jboss.com

Currently we have the following jaxb versions native=2.1.6 cxf=2.1.4 metro=2.1.6 That generally opens the following question: #1 Should we align the jaxb version with the respective stack and deploy it to the AS #2 Should we let the AS define the jaxb version and not deploy it views ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143063#4143063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143063

18 years

1
0
0 / 0

[Design of JBoss Web Services] - Re: http://org.jboss.ws/http#chunksize

by thomas.diesler＠jboss.com

I moved this to the dev forum and here is your jira for it http://jira.jboss.org/jira/browse/JBWS-2124 good work, btw View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143061#4143061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143061

18 years

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBPAPP-750 - Integration between AS and JBossMessaging 1

by jesper.pedersen

IMHO anything that could help prevent a misconfiguration would be a great enhancement for JBoss 5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143057#4143057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143057

18 years

1
0
0 / 0

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

by scott.stark＠jboss.org

Which has now expanded to: | /** | * Factory for the BeanMetaData describing component instances. | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ComponentBeanMetaDataFactory | { | /** | * Create the beans that will be created together as a component. | * | * @param baseName - base name used to derive unique bean name | * @param compID - component id used to derive unique bean name | * @param nameBuilder - transformer used to derive unique bean name from baseName/compID | * @param visitor - optional visitor that may augment BeanMetaData | * @return list of beans describing the component | */ | public List<BeanMetaData> getBeans(String baseName, long compID, | ComponentNameBuilder nameBuilder, ComponentVisitor visitor); | } | | /** | * 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<T> | { | /** | * the factory which defines template BeanMetaData[] for the components | * @return the BeanMetaDataFactory defining the component beans | */ | public ComponentBeanMetaDataFactory 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 component context instance information. | * @throws Throwable - on failure to install the component beans | */ | public ComponentInstance<T> createComponents(String baseName) | throws Throwable; | | /** | * Extract the unique component id from a component bean name. | * @param name - a name previously returned from createComponents. | * @return the component id portion of the name | * @throws NumberFormatException - if name is not a valild bean component | * name with a component id. | */ | public long getComponentID(String name) throws NumberFormatException; | | /** | * Uninstall the component beans for the given instance | * @param instance - the ComponentInstance previously returned from createComponents | * @throws Exception - on failure to uninstall the component beans | */ | public void destroyComponents(ComponentInstance<T> instance) | throws Exception; | } | | /** | * The component context instance. This is the bean that acts as the container | * for the component bean instances. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ComponentInstance<T> | { | /** | * Get the name of the bean for the component context instance | * @return | */ | public String getContextName(); | /** | * Get the component bean names | * @return | */ | public List<String> getComponentNames(); | /** | * Get the id associated with this component | * @return | */ | public long getComponentID(); | /** | * Get the component context instance | * @return | */ | public T getContext(); | | } | | /** | * Abstraction for building/parsing component names | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ComponentNameBuilder | { | /** | * Create a globally unique mc bean name | * @param baseName - base name used to derive unique bean name | * @param compName - the component name used to derive unique bean name | * @param compID - component id used to derive unique bean name | * @return the unique mc bean name | */ | public String buildName(String baseName, String compName, long compID); | /** | * Parse a mc bean name for the component id | * @param name - the mc bean name | * @return the component id | * @throws NumberFormatException | */ | public long getComponentID(String name) throws NumberFormatException; | } | | /** | * A component bean factory visitor plugin that allows for extension of the | * bean metadata produced by the factory. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ComponentVisitor | { | /** | * Visit callback to allow for augmentation of a components bean metadata. | * @param builder - the bean metadata build facade to augment the metadata | * @param baseName - the bean base name | * @param componentName - the bean component name | * @param compID - the bean component id | */ | void visit(BeanMetaDataBuilder builder, String baseName, | String componentName, long compID); | | } | 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] - Indirect dependency names

by scott.stark＠jboss.org

One issue I have with creating the component factory notion pattern is that the factory wants to describe relationships between components with logical names that have to be transformed into unique names for the mc beans that are installed when the factory is asked to create the component beans. For example, and ejb component factory would have BeanMetaData for the interceptors that included an | AbstractInstallMetaData install = new AbstractInstallMetaData() | install.setBean("BeanContext"); | install.setMethodName("addInterceptor"); | ... | The "BeanContext" name is the logical component name portion of the bean context. When its created as an mc bean instance by the component factory, this gets transformed into a unique name using an input base name and component id number. I'm going to have to extend all of the dependency related metadata and builders to override the depends name to allow for a transformed name. I'm wondering if we should have consistent support for a dependency name abstraction that would allow for name transformation more easily. The existing String/Object based name methods would just call the generalized version taking a DependencyName with an IdentityDependencyName implementation: | interface DependencyName | { | Object getName(); | } | class IdentityDependencyName implements DependencyName | { | private Object name; | IdentityDependencyName(Object name)... | Object getName() { return name; } | } | | class AbstractInstallMetaData | { | private DependencyName bean; | | public setBean(String bean) | { | setBean(new IdentityDependencyName(bean)); | } | public setBean(DependencyName bean) | { | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143035#4143035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143035

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ClassLoader behaviour on remote clustering tests

by clebert.suconic＠jboss.com

We will need an AOP release anyway. When I changed build-messaging.xml to use the default aopc I got another ClassNotFoundException, but everything passed when I built aop from SVN and replaced thirdpary, as Flavia fixed another problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143034#4143034 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143034

18 years

1
0
0 / 0

[Design of POJO Server] - Re: JBAS-5266 Remove a deployment but the component remains

by mark.spritzler

I might have messed one thing up. @Override protected String getProfileName() { return "default"; } I changed the name to "default" because on my machine it wasn't finding a profile named "profileservice". But if it breaks Hudson's running of this test, then I will need to revert it back. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143012#4143012 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143012

18 years

1
0
0 / 0

[Design of POJO Server] - JBAS-5266 Remove a deployment but the component remains

by mark.spritzler

I updated the JmsDestinationUnitTestCase to check for this. The tests are currently failing. I believe the call to getManagementView() will reload the profile, so it should reload the Component By Type map, and refresh the list of components etc. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142999#4142999 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142999

18 years

1
0
0 / 0

[Other JBoss Development Design] - Re: failing org.jboss.test.util.test.ThreadPoolRunnableUnitT

by fnasser＠redhat.com

You are supposed to be using http://repository.jboss.org/oswego-concurrent/1.3.4.patch01-brew/ which has the patches: concurrent-ConcurrentHashMap.patch concurrent-ConcurrentReaderHashMap.patch concurrent-PooledExecutor.patch I have no idea how the unpatched 1.3.4-brew ended up in Branch_4_2. P.S.: I myself run the testsuite after any component upgrade, -brew or not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142918#4142918 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142918

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