August 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by adrian＠jboss.org

The deployment isn't a "SecurityDomain" it is the submanaged objects, the policies in the deployment that are security domains. I don't see why you need anymore markup than I've shown? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070683#4070683 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070683

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | Based on your "SecurityDomain" example then I don't see this as anything | more than a name with qualifier. | | i.e. SecurityDomain/Default. | | The trivial requirement could be served from the following | pseudo markup. | | | | public class ConnectionManagerMetaData | | { | | @ManagedObjectRef(type="SecurityDomain'); | | public void setSecurityDomain(String securityDomain); | | } | | | | @MangedObject | | public class SecurityDeployment | | { | | @ManagedProperty | | Collection<SecurityPolicy> getPolicies(); | | } | | | | public SecurityPolicyMetaData | | { | | @ManagedObjectID(type="SecurityDomain") | | public String getName(); | | } | | | | I'd actually turn the "policies" managed property into a map by id. | i.e. the property that gets constructed is not a collection it is effectively. | | | Map<String, ManagedObject<SecurityPolicy>> | | | | There is a similar trick going on the 'unified metadata" for | | object (id) | ------------- | ejbs (ejb-name) | ejb-refs (ejb-ref-name) | etc. Ok, something needs to identify that the SecurityDeployment is of type "SecurityDomain", and identify what the key under the "SecurityDomain" type is. Presumably something like? | @ManagementObject(type="SecurityDomain"). | public class SecurityDeployment | { | @ManagedProperty | @ManagedObjectKey | Collection<SecurityPolicy> getPolicies(); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070681#4070681 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070681

16 years, 9 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Specification of the Exception on After-throwing and finally

by flavia.rainone＠jboss.com

This thread is about the design of task http://jira.jboss.com/jira/browse/JBAOP-388. I just couldn't come up with a good approach to implement this task. Let me show why. First, I think the specification of the exception would have to do with the pointcut matching, because it does affects selection of whether that after-throwing advice will be bound to a specific joinpoint or not. If the joinpoint does not throw that type of exception, we are not calling the advice. But, besides, this information is also part of the advice matching algorithm itself. I need to validate the type of exception the advice is receiving. After going through these first thoughts, I noticed it would be a bad idea adding this to pointcut matching, and decided to do the matching on the advisor generation algorithm. For that, I need to pass this info along with the advice factory created. And notice this will affect all types of advices and weaving modes, because the advice factory is used regardless of the advice type and weaving mode. So, I would have to add a field to AdviceFactory, and this field will be used only in case it is an after-throwing or finally advice, and only if the user specified the exception type. On the other hand, if we just do a matching on the type of the exception that the advice catches, we would get rid of the design problem, and the algorithm would be concentrated on the advice.annotation package and the JoinPointGenerator class only. I started considering this approach after reviewing all classes I would have to edit using the previous approach. Any thoughts? If the first solution is considered better than the second one, any hint on a better design is more than welcome :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070679#4070679 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070679

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by tom.baeyens＠jboss.com

the DLQ could be implemented in the JobExecutor MDB, no ? but you need to know in the bean somehow that this is the last retry that JMS is going to give the message delivery. if you then do a try { | // continue asynchronously | } catch (Exception e) { | if (thisIsTheLastAttempt()) { | signalInNewTransaction(execution.getId(), "failure); | } | } execution would need to be reloaded in the new transaction method, but i think this could work. would it make sense to update the MDB in that sense ? can you know in JMS if this is the last retry that JMS is going to give the MDB to deliver the message ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070678#4070678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070678

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Failure handling

by estaub

Bill, Many thanks. The DLQ technique certainly seems promising for the asynch continuation case. The info on TransactionManager in various appservers is most helpful. The code snippet really helped clarify the different scenarios you and Tom are thinking about, versus the one I was poorly describing. -Ed View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070672#4070672 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070672

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding applyMetaData method to KernelControllerContext

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | e.g. You've reused the MetaDataVisitors to do what? | | They look at the MetaData object not the real object graph how does this relate to annotations are you talking about the annotations in the xml? | | | After you add new MetaData, it needs to be 'visited', in order to plugin all those dependencies, callbacks, installs, ... | So the easiest way for me to do that was to use the existing MetaDataVisitor concept, and just twist it a bit to suite my need - not starting from BeanMetaData, but on newly added MetaDataVisitorNode + pushing BMD at the bottom of the stack before executing it. | Ok. But I'm not sure it needs to be this complicated? anonymous wrote : | "adrian(a)jboss.org" wrote : | | Why would the annotations be already processed? | | | When we do a re-install on the controller context, do we need a new look at the annotations? | Of course, the class could change. anonymous wrote : | "adrian(a)jboss.org" wrote : | | How does one add ImplementationDetail3Adapter or use | | AlternateImplementationDetail1Adapter.INSTANCE. | There is a BeanAnnotationAdapter (uf, yup, bad choice of name) factory. | Some simple extension impl can be easily added. | | | public class BeanAnnotationAdapterFactory | | { | | private static final BeanAnnotationAdapter adapter = new BasicBeanAnnotationAdapter(); | | | | public static BeanAnnotationAdapter getBeanAnnotationAdapter() | | { | | return adapter; | | } | | } | | | | | | You can extend BasicBeanAnnotationAdapter and use its addPlugin method to add your new annotation plugins. | | | | protected void addAnnotationPlugin(AnnotationPlugin plugin) | | { | | Class<? extends Annotation> annotation = plugin.getAnnotation(); | | if (annotation.getAnnotation(Target.class) == null) | | log.warn("Annotation " + annotation + " missing @Target annotation!"); | | if (annotation.getAnnotation(Retention.class) == null) | | log.warn("Annotation " + annotation + " missing @Retention annotation!"); | | | | Set supported = plugin.getSupportedTypes(); | | if (supported.contains(ElementType.TYPE)) | | { | | classAnnotationPlugins.add(plugin); | | } | | if (supported.contains(ElementType.CONSTRUCTOR)) | | { | | constructorAnnotationPlugins.add(plugin); | | } | | if (supported.contains(ElementType.METHOD)) | | { | | if (plugin instanceof PropertyAware) | | propertyAnnotationPlugins.add(plugin); | | else | | methodAnnotationPlugins.add(plugin); | | } | | if (supported.contains(ElementType.FIELD)) | | { | | fieldAnnotationPlugins.add(plugin); | | } | | } | | Ok. So the code that didn't compile was just out-of-the-box factory settings for bootstrapping? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070671#4070671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070671

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - WriteThroughManagedPropertyImpl

by adrian＠jboss.org

What is WriteThroughManagedPropertyImpl doing? It is the Fields implementation that should be doing this (setting the property on the attachment). The ManagedProperty(Impl) is just a wrapper for the Fields to make the api easier to use at the front end. There should be a JavaBeanFields implementation, a DomFields, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070665#4070665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070665

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding applyMetaData method to KernelControllerContext

by alesj

"adrian(a)jboss.org" wrote : | e.g. You've reused the MetaDataVisitors to do what? | They look at the MetaData object not the real object graph how does this relate to annotations are you talking about the annotations in the xml? | After you add new MetaData, it needs to be 'visited', in order to plugin all those dependencies, callbacks, installs, ... So the easiest way for me to do that was to use the existing MetaDataVisitor concept, and just twist it a bit to suite my need - not starting from BeanMetaData, but on newly added MetaDataVisitorNode + pushing BMD at the bottom of the stack before executing it. "adrian(a)jboss.org" wrote : | Why would the annotations be already processed? | When we do a re-install on the controller context, do we need a new look at the annotations? "adrian(a)jboss.org" wrote : | I can say from that code that was broken, | I don't like the idea of hardwiring those annotation handlers | This can easily be fixed, just temp impl detail. Basically you have two kinds on annotations handlers - plugins and adapters. Plugins are those who know how to handle class, constructor, method (property), field annotations. Adapters (Annotation2ValueMetaDataAdapter) are those who know how to produce ValueMetaData from annotation. Since property plugins == adapters, there is just one need for actual impl. "adrian(a)jboss.org" wrote : | How does one add ImplementationDetail3Adapter or use | AlternateImplementationDetail1Adapter.INSTANCE. There is a BeanAnnotationAdapter (uf, yup, bad choice of name) factory. Some simple extension impl can be easily added. | public class BeanAnnotationAdapterFactory | { | private static final BeanAnnotationAdapter adapter = new BasicBeanAnnotationAdapter(); | | public static BeanAnnotationAdapter getBeanAnnotationAdapter() | { | return adapter; | } | } | | You can extend BasicBeanAnnotationAdapter and use its addPlugin method to add your new annotation plugins. | protected void addAnnotationPlugin(AnnotationPlugin plugin) | { | Class<? extends Annotation> annotation = plugin.getAnnotation(); | if (annotation.getAnnotation(Target.class) == null) | log.warn("Annotation " + annotation + " missing @Target annotation!"); | if (annotation.getAnnotation(Retention.class) == null) | log.warn("Annotation " + annotation + " missing @Retention annotation!"); | | Set supported = plugin.getSupportedTypes(); | if (supported.contains(ElementType.TYPE)) | { | classAnnotationPlugins.add(plugin); | } | if (supported.contains(ElementType.CONSTRUCTOR)) | { | constructorAnnotationPlugins.add(plugin); | } | if (supported.contains(ElementType.METHOD)) | { | if (plugin instanceof PropertyAware) | propertyAnnotationPlugins.add(plugin); | else | methodAnnotationPlugins.add(plugin); | } | if (supported.contains(ElementType.FIELD)) | { | fieldAnnotationPlugins.add(plugin); | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070658#4070658 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070658

16 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - User Portlet Discussion

by emuckenhuber

Regarding to a revision of the UserPortlet we were thinking of dividing it into two portlets - one User Administration Porlet (including Role Management) and a generic Portlet. Furthermore we thought about adding following additional features: > Generic Portlet not logged in - Register new account - Retrieve lost password - Retrieve lost username loggend in - Change user profile - Customizable profile page - Privacy Options registration - Terms and conditions - Stricter constaints on input (username, unique email, increase password strength) - Captcha support - Popup calendar (e.g. for birthday) > Admin Portlet - Add/delete user - Select approval process (workflow based) - Change required input fields - Change terms of use - Approve registered users - Change user profiles - Add/delete roles - Assign roles Feel free to post your ideas or further requirements Thanks, Emanuel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070651#4070651 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070651

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding applyMetaData method to KernelControllerContext

by adrian＠jboss.org

You need to take a step back and explain it from first princples. e.g. You've reused the MetaDataVisitors to do what? They look at the MetaData object not the real object graph how does this relate to annotations are you talking about the annotations in the xml? Why would the annotations be already processed? Short of finding the time (I don't at the moment) to do a code read on all these changes (not just the latest stuff), I can't really comment. I can say from that code that was broken, I don't like the idea of hardwiring those annotation handlers What was it something like? | Adapter[] adapters | { | ImplementationDetail1Adapter.INSTANCE | ImplementationDetail2Adapter.INSTANCE | }; | How does one add ImplementationDetail3Adapter or use AlternateImplementationDetail1Adapter.INSTANCE. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070642#4070642 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070642

16 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2007