[Design of JBossXB] - Re: Attributes problem
by adrian＠jboss.org
"alex.loubyansky(a)jboss.com" wrote : We do support binding to a model group. Model group can be referenced by its QName. This is what @JBossXmlModelGroup is for.
I mean having a GroupBinding object inside JBossXB to which you can attach
processing rules.
The current strategy is to unwind any model into its components
sequences, choices, elements, etc.
which means there's no way for JBossXB to give me back the information
about where in the model I am when it does "setParent", etc.
You can see part of the problem with all the "instanceof" or "isModelGroup/Element"
etc. You have to bind to the unwound model rather than the real model and
hack around the "cognitive disonance" this causes. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134783#4134783
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134783
18 years, 1 month
[Design the new POJO MicroContainer] - Re: enums, generics and other animals
by alesj
"adrian(a)jboss.org" wrote : I don't understand why there is an InjectOption and an InjectionOption?
|
The non enum version was first added.
But when the annotation support kicked in, I didn't want to rely on the String, so the enum was added, but the old one was never removed. :-(
You can also see that the FromContext suffers from the same syndrome.
Where Inject(ion)Option should really be enum, since it only has finite number of usages, the FromContext due to its Dynamic case cannot be.
So, it the case you use annotations, you cannot get the DynamicFromContext.
The non-enum FromContext is really an impl detail.
And perhaps to avoid confusion, it can be renamed.
"adrian(a)jboss.org" wrote :
| All of these should just be enums throughout
|
| Cardinality
| FromContext
| InjectionOption (already is InjectOption???)
| AutowireType
|
The Cardinality and FromContext cannot be enums.
The Cardinality can be whatever, not just those 4 usual usages.
e.g. 2..7, 5..n, etc
For FromContext see DynamicFromContext.
"adrian(a)jboss.org" wrote :
| Since we are doing 2.0.0 we could also decde to change ControllerMode to an Enum as well?
|
Since I'll change a few of them anyway, I don't see why not this one as well.
"adrian(a)jboss.org" wrote :
| Also the FromContext is a misuse of generics.
| The purpose of generics is to produce compile time errors, the way this class is used, it is simply not possible for the compiler to do so.
|
| It looks to me like the generic is only here to avoid having to manually code the check/cast of ControllerContext -> KernelControllerContext
| but you should do that by hand anyway to give a better error message than CCE.
|
I'm already doing validation, so the error msg is useful.
But you're right, this is a misuse. A handy one, but a misuse. :-)
I'll remove the generics.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134782#4134782
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134782
18 years, 1 month
[Design of JBossXB] - Re: Attributes problem
by alex.loubyansky＠jboss.com
"adrian(a)jboss.org" wrote : The @XmlChild from some other part of the group
| needs to replace the CDATA. The CDATA and subelements are mutually
| exclusive. You can't have
|
| | <key class="java.lang.Integer">12
| | <list ...>
| | </key>
| |
|
| It doesn't make sense. :-)
Ok, if that doesn't make sense we can throw an exception. My question is then does the following make sense? Not in the given MC example but in general. Can this be useful?
| <wrapper attr="val1">
| <child ...>
| </wrapper>
| <wrapper attr="val2">
| <wildcard-content ...>
| </wrapper>
| <wrapper attr="val3">12</wrapper>
|
My point was it didn't matter what the content of wrapper was, the attr should still be set in the same way.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134779#4134779
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134779
18 years, 1 month
[Design of JBossXB] - Re: Attributes problem
by adrian＠jboss.org
I've fixed this by creating a WrapperBeanAdapter.
It's not very clean though. I think it shows we need better support
for being able to bind to a group and know how the group is processed.
The strategy I've used is to "steal" the BeanAdapter
(and other information) from the xml type
of the wrapping class then delegate to it from a WrapperBeanAdapter
| if (groupText != null && groupText.wrapper() != Object.class)
| {
| BeanInfo wrapperInfo = JBossXBBuilder.configuration.getBeanInfo(groupText.wrapper());
| TypeBinding wrapperTypeBinding = resolveTypeBinding(wrapperInfo.getClassInfo());
| // Steal the attributes
| Collection<AttributeBinding> otherAttributes = wrapperTypeBinding.getAttributes();
| if (otherAttributes != null)
| {
| for (AttributeBinding other : otherAttributes)
| elementTypeBinding.addAttribute(other);
| }
| ParticleHandler particleHandler = wrapperTypeBinding.getHandler();
| if (particleHandler instanceof BeanHandler == false)
| throw new IllegalStateException("Cannot wrap " + wrapperInfo.getName() + " not a bean type " + particleHandler);
| BeanHandler beanHandler = (BeanHandler) particleHandler;
| WrapperBeanAdapterFactory wrapperFactory = new WrapperBeanAdapterFactory(beanHandler.getBeanAdapterFactory(), propertyType.getType());
| elementTypeBinding.setHandler(new BeanHandler(wrapperInfo.getName(), wrapperFactory));
| elementTypeBinding.setSimpleType(wrapperTypeBinding.getSimpleType());
| }
|
The idea of the wrapper is that it will delegate requests to the wrapped BeanAdapter
until it spots an element from some other part of the group
then it will just return that element's object.
| @Override
| public Object getValue()
| {
| if (notWrapped != null)
| return notWrapped;
| else
| return wrapped.getValue();
| }
|
| @Override
| public void set(PropertyInfo propertyInfo, Object child) throws Throwable
| {
| Class<?> stopWrapping = getBeanAdapterFactory().getStopWrapping();
| if (child != null && stopWrapping != null && stopWrapping.isInstance(child))
| notWrapped = child;
| else
| wrapped.set(propertyInfo, child);
| }
|
Of course, it isn't really doing that. It's just using the property type
(the stopWrapping) to detect when it is another element from the group
which is obviously a kludge that could be fixed by knowing more
about the group.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134774#4134774
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134774
18 years, 1 month
[Design of JBoss jBPM] - Re: how crucial are exception handlers ?
by tom.baeyens＠jboss.com
@estaub: point taken.
i definitely see that the docs need to be more rigorous in that respect.
i don't yet see how we could define more rigorous behaviour in the engine itself. because i don't want to be limited to the bonita behaviour that you describe.
this is also a performance issue. for simple processes that don't do heavy operations, spanning the transaction over multiple activities reduces the number of transactions. the transaction has an overhead and also, for each transaction, the runtime data has to be read again from the db.
by default, i would like to keep the same behaviour in the process execution itself. but we can definitely provide better choice to the client. my current idea is that we enhance the command based session facade that sits in front of the jbpm-context-blocks. in such a session facade, you could choose to have it operate synchronously or asynchronously.
this gives already the easy flexibility for a user to choose whether he wants the process operation to be in the same thread versus a separate thread. but in the process execution, i think we should keep the strategy as it is now, but only document it better.
let me know if this doesn't matches your expectations
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134763#4134763
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134763
18 years, 1 month