[JBoss AOP] - Re: IllegalAccessException using reflection on private field
by flavia.rainone＠jboss.com
Making the wrapper public is a very delicate question. On one hand, there is the fact that making it private might be incompatible with the security configuration of the user's application. One doesn't have to be aware that a private method will be generated inside his/her class, nor that ReflectionAspect needs security permission to make that method accessible. On the other hand, we have the problem you said, a client can call reflectively the wrapper if it is public. But, again, the client shouldn't know that this method exists, and its name is purposely awkward for that matter.
We can also write a public wrapper that calls Field.set and Field.get.. This one could be public, because Field.set and Field.get would only be accessible if the field was accessible.
All this needs to be discussed... thanks for your input on the subject :).
Let's wait for Kabir to return from his training, so we can know what he makes of this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048398#4048398
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4048398
18 years, 11 months
[JBoss Seam] - Using enum for component attribute
by mustaghattack
Hello,
I'm wondering if there is a simple way to bind a model property to a component attribute.
Here is a simple example :
I would like to persist the selectManyCheckbox layout attribute. In the model I would typically use an enum (independent of the UI values) like
enum Alignment { HORIZONTAL, VERTICAL }
and expect to use it this way
<h:selectManyCheckbox layout="#{myBean.alignment}" ...> where getAlignment in myBean return an Alignment object.
Obviously we need to define somewhere conversions rules which are pretty straightforward : Alignment.HORIZONTAL -> "lineDirection" etc ...
The ValueExpression mechanism call ELResolver to get myBean.alignment but then coerce the enum to a String by calling the name() method (as defined in the unified EL spec), which of course doesn't work.
I'm using Seam so I don't want to write a backed bean just to convert this value.
I though to write an EL function but it's supposed to be a view stuff isn't it ?
Any idea ?
Thanks,
Bruno
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048395#4048395
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4048395
18 years, 11 months
[JBoss jBPM] - Re: Un expected behavior observed with Token details
by estaub
I suspect there are more problems here.
If I'm not mistaken, when an actionhandler is invoked, the transaction will have started at the last asynchronous event that caused something to be written persistently. If all the nodes are asynchronous, this is fine. But if there's a sequence of synchronous nodes, the process may unwind quite far back. This seems like it would be surprising to the developer. If any of the external actions in the rolled-back sequence aren't transactional, the process will now be "skewed", living in the past, relative to the real-world process being performed, probably waiting for an event that has already happened and now will never occur again.
If there are any actionhandlers or other elements that may or may not signal synchronously, the amount of rollback becomes somewhat unpredictable. This is common when waiting for an event that may have already happened, e.g., a timer that may have already expired.
I'm not saying that the JBPM internal process integrity is lost, just that the distance rolled back in the graph seems likely to be unexpected and/or uncertain, and hence difficult to design error-handling for.
Did I miss something? Is there an easy workaround? A best practice to propose?
-Ed Staub
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4048394#4048394
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4048394
18 years, 11 months