[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote :
| 1) The AbstractManagedObjectFactory.buildManagedObject(Class) method always produces a ManagedObject. If an attachment class does not have a ManagementObject annotation I don't think we should as a loop over all DeploymentUnit attachments is going to have too many ManagementObjects.
|
Ok, that's probably just a mistake because the code is incomplete?
| 2) We can't adequately describe the ManagedProperty constraints (allowed values, min/max) via annotations. It seems we need something like a ManagedPropertyConstraintsPopulator:
|
I think we can in most cases, but when we can't your idea looks a good one.
Just as long as it isn't an all or nothing. i.e. you can use it to override
just one property where the annotations are currently inadequete
rather than having to recode everything.
anonymous wrote :
|
| | interface ManagedPropertyConstraintsPopulator
| | {
| | /** Populate the ManagedProperty fields constraint related info
| | */
| | populateManagedProperty(Class attachmentClass, PropertyInfo info, Fields fields);
| | }
| |
| and this would be registered with the ManagedObjectFactory similar to how ManagedObjectBuilders are.
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068229#4068229
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068229
16 years, 9 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-181 & ManagedDeployments
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : For the ha datasource URLDeliimeter property, its is a new datasource type that does effectively need some synchronization with the admin tool as there can be a lot of hidden complexity in the list of jdbc urls in terms of a tool providing testing to ping the indicated databases. Arguably this also requires a new multi-valued jdbc url property rather than a separator that is used in combination with the old jdbc url. How we deal with this type of evolution best is the question.
|
That's exacly my point. The underlying model is a connection-url and a delimiter.
It has to be that way because it is configuring an MCF which can only take strings
and primitives as parameters.
We could at some future time decide that really this should be a exposed as
one mangaged property that is an array or list.
The underlying model doesn't change, but what appears in the management
layer (and to the user) is easier to understand.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068227#4068227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068227
16 years, 9 months
[Design the new POJO MicroContainer] - Annotation handling impl
by alesj
I've implemented initial version of handling MC beans annotations.
So, before I go into madly testing all the features, backcompatibility, javadocs, ..., it would probably be good to get some feedback on my impl - bad, really bad, so so, good, nice, wonderful, ... :-)
Let me first explain what I did.
In the DescribeAction, after the metadata has been set, I create BeanAnnotationAdapter - currently only BasicBeanAnnotationAdapter.
| public interface BeanAnnotationAdapter
| {
| /**
| * Apply the annotations.
| *
| * @param context the context
| * @throws Throwable for any error
| */
| void applyAnnotations(KernelControllerContext context) throws Throwable;
| }
|
The main goal is to fill in BeanMetaData with information from @Annotations.
There are 5 different AnnotetedInfo types that need checking:
- class
- constructor
- property
- method
- field
I currently don't do field (since there is no matching 'Bean'MetaData), and I differentiate between property and method for the ease of providing matching PropertyMetaData.
The whole idea is to check type's matching MetaDataRetrieval (MDR).
For class this is context's top level MDR, for others it is the component of this top level MDR.
And for constructor|method parameters it is component's component MDR - see the AnnotatedElementMetaDataLoader post issue.
For each annotation there is matching AnnotationPlugin:
| public interface AnnotationPlugin<T extends AnnotatedInfo, C extends Annotation>
| {
| Class<C> getAnnotation();
|
| Set<ElementType> getSupportedTypes();
|
| void applyAnnotation(T info, MetaDataRetrieval retrieval, KernelControllerContext context) throws Throwable;
| }
|
Depending on the ElementType's of @Target on the annotation, matching collections of plugins are filled: classPlugins, constructorPlugins, ...
I then iterate through all possible AnnotatedInfos - ClassInfo, ConstructorInfos, PropertyInfos, MethodInfos, static MethodInfos, FieldInfos - and apply matching plugins. For each AnnotatedInfo I iterate over with all possible plugins.
| // methods
| Set<MethodInfo> methods = info.getMethods();
| if (methods != null && methods.isEmpty() == false)
| {
| for(MethodInfo mi : methods)
| {
| Signature mis = new MethodSignature(mi.getName(), Configurator.getParameterTypes(trace, mi.getParameterTypes()));
| MetaDataRetrieval cmdr = retrieval.getComponentMetaDataRetrieval(mis);
| if (cmdr != null)
| {
| for(AnnotationPlugin plugin : methodAnnotationPlugins)
| plugin.applyAnnotation(mi, cmdr, context);
| }
| }
| }
|
If the AnnotationItem is found in MDR and metadata is not yet set, I apply information from the annotation.
| public final void applyAnnotation(T info, MetaDataRetrieval retrieval, KernelControllerContext context) throws Throwable
| {
| AnnotationItem<C> item = retrieval.retrieveAnnotation(getAnnotation());
| if (item == null || isMetaDataAlreadyPresent(info, item.getAnnotation(), context))
| return;
| internalApplyAnnotation(info, retrieval, item.getAnnotation(), context);
| }
|
I'm also supporting constructor|method parameter annotation injection.
In order for this to work, all parameters must have of the Annotation2ValueMetaDataAdapter annotations present: @Inject, @StringValue, @ValueFactory, @ThisValue, @NullValue.
So much for simple explanation. :-)
This is what you can currently do:
| @Aliases({"al", "test"})
| @Demands({"otherBean"})
| @Depends({"serviceBean"})
| @Supplys({"txBean"})
| public class SimpleInject
| {
| private int intVF;
| private TestBean testBean;
| private Set<MyDeployer> deployers;
|
| public int getVf()
| {
| return intVF;
| }
|
| @FactoryMethod
| public static SimpleInject getInstance(@NullValue Object someNull)
| {
| return new SimpleInject();
| }
|
| @Start
| public void startMeUp(@Inject(bean = "lifecycleBean") TestBean bean, @ValueFactory(bean="valueBean", method = "getValue", parameter = "123") int value)
| {
| intVF =- value;
| }
|
| @StringValue("123")
| public void setVf(int vf)
| {
| this.intVF = vf;
| }
|
| @Install
| public void addDeployer(MyDeployer deployer)
| {
| if (deployers == null)
| deployers = new HashSet<MyDeployer>();
| deployers.add(deployer);
| }
|
| @Uninstall
| public void removeDeployer(MyDeployer deployer)
| {
| deployers.remove(deployer);
| }
|
| @InstallMethod
| public void whenInstalled(@ThisValue SimpleInject me, @NullValue Object plainNull)
| {
| System.out.println(me == this);
| System.out.println("plainNull = " + plainNull);
| }
|
| @UninstallMethod
| public void withUninstall(@ThisValue SimpleInject me, @NullValue Object plainNull)
| {
| System.out.println(me == this);
| System.out.println("plainNull = " + plainNull);
| }
|
| public TestBean getTestBean()
| {
| return testBean;
| }
|
| @Inject(bean = "testBean")
| public void setTestBean(TestBean bean)
| {
| this.testBean = bean;
| }
|
| public class TestConstructorBean
| {
| @Constructor
| public TestConstructorBean(@Inject(bean = "testBean") TestBean test)
| {
| System.out.println("test = " + test);
| }
| }
|
I'll commit the code, just to make it more simple to see what I did.
There is just one entry point to all this mess - in the DescribeAction.
I removed the old @Annotation lifecycle support - now part of this new approach.
The BeanMetaData is not cloned yet - a big TODO. :-)
I haven't thought of how exactly this will fit with the factory beans. One step at the time ... ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068190#4068190
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068190
16 years, 9 months
[Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache
by manik.surtani＠jboss.com
"jason.greene(a)jboss.com" wrote : "galder.zamarreno(a)jboss.com" wrote : Manik, thanks for the wiki, it's clearer now :)
| |
| | For curiosity, how would you enforce SERIALIZABLE? It's quite an edge case but I guess it's exclusively locking read operations and the rest as it is, correct?
|
| Yes, essentially an exclusive FQN lock is acquired on all read operations. We also have the ability to skip the node copy on writes, since it's not needed.
|
| I think everyone is more likely to use the forceWriteLock option on a read (AKA SELECT FOR UPDATE) with READ COMMITTED or REPEATABLE READ instead of SERIALIZABLE, since it allows you to selectively chose when and what you serialize access to.
Either way, to keep the design clean and standardised, this could be encapsulated in a SerializableNode. But the concept is essentially an exclusive lock even for reads.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068172#4068172
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068172
16 years, 9 months