Github user yasserzamani commented on the issue:
https://github.com/apache/struts/pull/133
> What do you mean by that? There is no bean name.
Users may set `class` attribute to a 1.class name or to a 2.bean name. I
meant I think it is not nice to use `class` attribute for, as you say, two
different topics. Additionally, in second use, S2 cannot know the config time
class of the action in any clean way.
> every action
Not every. `bean` attribute is and will be optional. Just actions which
their `class` attribute value can not be resolved to config time class of the
action by `ojectfactory.getInstanceClass`. For example `<action class=beanName`
with `<bean name=beanName class=com....` and if this bean is proxified e.g. by
AOP needs to be protected. This PR warns about these and continue.
> It is not about the amount of changes
Sorry I meant about docs, satisfying user with the new design or param and
maintain it for log time.
> Yet another is to compare action configuration class with the current
instance toString / getClass().toString
As I mentioned, when user uses `class` attribute as a bean name, S2 cannot
know the action configuration class in any clean way.
> You're mixing two very different topics together, security and chain
configuration.
No, I think about S2 borders. I'm trying to discuss that S2 should or
should not know the config time class of the action and then do not operate
outside of that border. Input Parameters, Chain and JSON are three example
operations of S2 which I discovered at first place. Then I discovered `<s:form
validate=true`. I see all of these are because S2 1.does not know and 2.do not
consider config time class of the action.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
