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

[Design the new POJO MicroContainer] - Re: DeployersImpl and AbstractController

by alesj

"adrian(a)jboss.org" wrote : Looks like a "Brain Fart" on my part? :-) Must've been after England vs. Croatia game. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131340#4131340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131340

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DeployersImpl and AbstractController

by adrian＠jboss.org

Looks like a "Brain Fart" on my part? :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131337#4131337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131337

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - New MetaType annotations and changes

by adrian＠jboss.org

While doing the ManagedObjects for the classloading metadata I've added a few "features" to the MetaType handling. 1) ManagedObject should be inheritable When you have a base class handling metadata for different use cases and versions its a pain (and probably error prone) to have to add @ManagementObject to every one. So I've made the annotation inheritable. e.g. all these will pick up that this is a managed object from the base class @ManagementObject com.acme.BaseMetaData com.acme.BaseMetaDataV10 extends BaseMetaData com.acme.BaseMetaDataV20 extends BaseMetaDataV10 com.acme.UseCase1MetaData extends BaseMetaData com.acme.UseCase2MetaData extends BaseMetaData 2) Ignoring implementation details I had a case where I wanted to ignore some properties when creating CompositeMetaTypes/Values, which you can now do with an annotation public class MyClass { @CompositeValue(ignore=true) public void setImplementationDetail(); } 3) Choosing the property type exposed for management This is really a form of aliasing. Basically you have a generic property but for management purposes you want to expose an explicit type. e.g. My use case is: // Too generic to be useful for management so ignore @CompositeValue(ignore=true) public void setVersion(Object version) {} // This is how we want it exposed (it's really an alias of setVersion) @CompositeValue(name="version") public void setTheVersion(Version version) { setVersion(version); ) 4) Mapping of types in metatype I also didn't want to expose the Version as a CompositeType, e.g. major=1, minor=0, micro=0, qualifier=GA so like JAXB, I've allowed a mapper to specified using an annotation e.g. this exposes the Version type as a String "1.0.0.GA" | @MetaMapping(VersionMetaMapper.class) | public class Version implements Serializable, Comparable<Version> | | public class VersionMetaMapper extends MetaMapper<Version> | { | public Type mapToType() | { | return String.class; | } | | public MetaValue createMetaValue(MetaType<?> metaType, Version object) | { | return SimpleValueSupport.wrap(object.toString()); | } | | public Version unwrapMetaValue(MetaValue metaValue) | { | if (SimpleMetaType.STRING.equals(metaValue.getMetaType()) == false) | throw new IllegalArgumentException("Not a string: " + metaValue); | | SimpleValue<?> simple = (SimpleValue<?>) metaValue; | String value = (String) simple.getValue(); | return Version.parseVersion(value); | } | The mapToType() is an "ease of use" thing. If you need a more complex type you should override getMetaType() instead. NOTE: This annotation is checked AFTER the MetaType/ValueBuilder stuff. So if somebody installs a specific builder for a type (e.g. using xml configuration), it will override this annotation. 5) Bug fix Finally, I fixed a bug where the CompositeValue stuff had a couple places iterating over the keySet() (only the id properties) instead of the itemSet() (all properties). One of them wasn't really a bug, it was in the toString(), but it confused me ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131334#4131334 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131334

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - DeployersImpl and AbstractController

by alesj

Why does DeployersImpl's constructor take AbstractController instead of plain Controller? Since the code plays nice with plain Controller as such. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131333#4131333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131333

18 years, 1 month

1
0
0 / 0

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

by coral

Hi all, I download the JBoss Portal + JBoss AS 4.2.2 zip and deploy it with my portlet. It can work fine on my local PC. But once I want to visit my Portal website on internet (by another PC). It dosen't work. Can anyone tell me how come it doesn't work and what config file I should deploy. Thanks a lot. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131327#4131327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131327

18 years, 1 month

1
0
0 / 0

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

by alesj

"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. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131322#4131322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131322

18 years, 1 month

1
0
0 / 0

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

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Its equivalent to creating an attribute with a ServiceDependencyValueMetaData as its value. | Yes, but my point is we don't modify (normalise) the metadata after the user creates it in the ServiceMetaData. The user has to know that a depends optional attribute is really two different pieces of metadata programmatically. Anyway, this is an issue brought up by Ales that is unrelated to the actual topic. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131321#4131321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131321

18 years, 1 month

1
0
0 / 0

[Design of OSGi Integration] - Re: Facade Questions

by adrian＠jboss.org

"johnbailey" wrote : | Am I making any sense? I am getting a really good understanding of | the MC and deployments, but I guess I need a clearer understanding of | how a client would use the Facade? Is there a client type we are | looking to support? | The use case is people wanting to use the OSGi api to control deployments which is spec defined rather than the JBoss specific api. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131319#4131319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131319

18 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int

by adrian＠jboss.org

You look to be getting very confused. :-) The first problem: anonymous wrote : | the AspectBeanMetaDataFactory replaces the AOPDeployment, which is obvious having looked at the TestSchemaResolver. For AbstractKernelDeployment, all the associated metadata classes are added. My guess is that this is because they are referenced somehow by the AbstractKernelDeployment. If I have understood the previous posts correctly, the AOPDeployment should be kept simple, i.e.: | No its because you are registering two schemas with the same namespace. (two top level classes in the resolver). You should register one schema for the top level class and annotate the classes you want as @XmlRootElement. The second problem anonymous wrote : | Does this look like the correct approach? | Looks like you don't understand how it works? :-) The aspect element is an xml wildcard in the microcontainer schema. If you want it native to your schema, you need to subclasses the setBeanFactories() and change the annotations to say what is valid. Illustrative example (trying to show how it works): | @XmlElements | ({ | @XmlElement(name="aspect", type=AspectFactoryMetaData.class), // aspect in your namespace | @XmlElement(name="bean" type=AbstractBeanMetaData.class), // bean in your namespace | @XmlElement(name="bean" namespace="urn:jboss:bean-deplioyer:2.0", type=AbstractBeanMetaData.class), // bean in the MC namespace | // etc. | }) | @XmlAnyElement // This accepts anything in a different namespace that implements BeanMetaDataFactory | public void setBeanFactories(List<BeanMetaDataFactory> beanFactories) | { | // No need for your own interface, just subclass and change annotations | super.setBeanFactories(beanFactories); | } | Your element is called {urn:jboss:aop-beans:1.0}aspects. It can be used as such (as a wildcard) in the bean schema (providing it is a root element in your schema. In your schema you just list it explctly and then there's no need to qualify it with a namespace, it's native. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131316#4131316 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131316

18 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: FileStructure and FileMatcher

by alesj

"adrian(a)jboss.org" wrote : | FileStructure: http://jira.jboss.com/jira/browse/JBMICROCONT-235 | AbstractParsingDeployerWithOutput is not VFS aware. I'll implement the FileMatcher in its direct subclass, AbstractVFSParsingDeployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4131308#4131308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4131308

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