Hi Slava/Alexey, Have you seen this thread: http://seamframework.org/Community/SecurityCannotResolveMemberInNodeSecur... referenced from http://community.jboss.org/message/630545#630545 It sounds very wrong that the Impl name is the correct one. Is the tool not validating wrong here ? /max http://about.me/maxandersen _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

I'm not convinced that's an error. In that case the docs and examples would be wrong. Do you get errors using the nonimpl class at runtime ?

Remember the whole point is that you can configure beans abstractly and then at runtime they are instantiated with the concrete instances. /max (sent from my phone) On 07/10/2011, at 18.54, Viacheslav Kabanovich<scabanovich(a)exadel.com> wrote: > Hi, Max > > org.jboss.seam.security.Identity is an interface and cannot be configured as a managed bean in config xml. > org.jboss.seam.security.IdentityImpl is ok to be configured. > > I added validation that marks configuring abstract types as errors in JBIDE-9834 last week. > > Slava > > On 10/07/2011 04:53 AM, Max Rydahl Andersen wrote: >> Hi Slava/Alexey, >> >> Have you seen this thread: http://seamframework.org/Community/SecurityCannotResolveMemberInNodeSecur... >> referenced from http://community.jboss.org/message/630545#630545 >> >> It sounds very wrong that the Impl name is the correct one. >> >> Is the tool not validating wrong here ? >> >> /max >> http://about.me/maxandersen >> >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> Remember the whole point is that you can configure beans abstractly > and then at runtime they are instantiated with the concrete instances. On 10/07/2011 11:25 AM, All examples in http://docs.jboss.org/seam/3/config/latest/reference/en-US/html_single/ configure concrete classes for managed beans. The only case that seems an exception is 'Virtual Producer Fields', here an abstract type may be declared as a bean, but concrete bean instance must be set as its value by <s:value> child tag. If an abstract type were allowed to be configured as a managed bean, it had to be treated first as an injection point of a regular CDI bean and second as configuring that bean. I would expect docs to say something explicitly about that, but nothing in docs supports it. I think such a feature would be not only great but also unpredictable. Suppose there are 10 implementations of Identity in classpath, each with its own set of qualifiers and each used in its own way. What node <security:Identity><s:modifies/></security:Identity> is supposed to do? Should it replace all 10 beans with one configured by this node? Which of 10 implementations should be selected for that? Slava Max Rydahl Andersen wrote: > I'm not convinced that's an error. > > In that case the docs and examples would be wrong. Do you get errors > using the nonimpl class at runtime ? > > Remember the whole point is that you can configure beans abstractly > and then at runtime they are instantiated with the concrete instances. > > /max (sent from my phone) > > > On 07/10/2011, at 18.54, Viacheslav Kabanovich&lt;scabanovich(a)exadel.com&gt; wrote: > >> Hi, Max >> >> org.jboss.seam.security.Identity is an interface and cannot be configured as a managed bean in config xml. >> org.jboss.seam.security.IdentityImpl is ok to be configured. >> >> I added validation that marks configuring abstract types as errors in JBIDE-9834 last week. >> >> Slava >> >> On 10/07/2011 04:53 AM, Max Rydahl Andersen wrote: >>> Hi Slava/Alexey, >>> >>> Have you seen this thread: http://seamframework.org/Community/SecurityCannotResolveMemberInNodeSecur... >>> referenced from http://community.jboss.org/message/630545#630545 >>> >>> It sounds very wrong that the Impl name is the correct one. >>> >>> Is the tool not validating wrong here ? >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> Remember the whole point is that you can configure beans abstractly > and then at runtime they are instantiated with the concrete instances. On 10/07/2011 11:25 AM, All examples in http://docs.jboss.org/seam/3/config/latest/reference/en-US/html_single/ configure concrete classes for managed beans. The only case that seems an exception is 'Virtual Producer Fields', here an abstract type may be declared as a bean, but concrete bean instance must be set as its value by <s:value> child tag. If an abstract type were allowed to be configured as a managed bean, it had to be treated first as an injection point of a regular CDI bean and second as configuring that bean. I would expect docs to say something explicitly about that, but nothing in docs supports it. I think such a feature would be not only great but also unpredictable. Suppose there are 10 implementations of Identity in classpath, each with its own set of qualifiers and each used in its own way. What node <security:Identity><s:modifies/></security:Identity> is supposed to do? Should it replace all 10 beans with one configured by this node? Which of 10 implementations should be selected for that? Slava Max Rydahl Andersen wrote: > I'm not convinced that's an error. > > In that case the docs and examples would be wrong. Do you get errors > using the nonimpl class at runtime ? > > Remember the whole point is that you can configure beans abstractly > and then at runtime they are instantiated with the concrete instances. > > /max (sent from my phone) > > > On 07/10/2011, at 18.54, Viacheslav Kabanovich&lt;scabanovich(a)exadel.com&gt; wrote: > >> Hi, Max >> >> org.jboss.seam.security.Identity is an interface and cannot be configured as a managed bean in config xml. >> org.jboss.seam.security.IdentityImpl is ok to be configured. >> >> I added validation that marks configuring abstract types as errors in JBIDE-9834 last week. >> >> Slava >> >> On 10/07/2011 04:53 AM, Max Rydahl Andersen wrote: >>> Hi Slava/Alexey, >>> >>> Have you seen this thread: http://seamframework.org/Community/SecurityCannotResolveMemberInNodeSecur... >>> referenced from http://community.jboss.org/message/630545#630545 >>> >>> It sounds very wrong that the Impl name is the correct one. >>> >>> Is the tool not validating wrong here ? >>> >>> /max >>> http://about.me/maxandersen >>> >>> >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Looks like a typo in the doc. They have four code snippets in the docs which configure Identity bean. Two of them use IdentityImpl and the other two use Identity.

On 10/07/2011 01:02 PM, Max Rydahl Andersen wrote: > I found this http://seamframework.org/166557.lace using impl in config too. > > So sounds like docs bug. Weird. > > /max (sent from my phone) > > > On 07/10/2011, at 21.09, Viacheslav Kabanovich&lt;scabanovich(a)exadel.com&gt; wrote: > >>> Remember the whole point is that you can configure beans abstractly >>> and then at runtime they are instantiated with the concrete instances. On 10/07/2011 11:25 AM, >> All examples in http://docs.jboss.org/seam/3/config/latest/reference/en-US/html_single/ configure concrete classes for managed beans. The only case that seems an exception is 'Virtual Producer Fields', here an abstract type may be declared as a bean, but concrete bean instance must be set as its value by<s:value> child tag. >> >> If an abstract type were allowed to be configured as a managed bean, it had to be treated first as an injection point of a regular CDI bean and second as configuring that bean. I would expect docs to say something explicitly about that, but nothing in docs supports it. I think such a feature would be not only great but also unpredictable. Suppose there are 10 implementations of Identity in classpath, each with its own set of qualifiers and each used in its own way. What node<security:Identity><s:modifies/></security:Identity> is supposed to do? Should it replace all 10 beans with one configured by this node? Which of 10 implementations should be selected for that? >> >> Slava >> >> Max Rydahl Andersen wrote: >>> I'm not convinced that's an error. >>> >>> In that case the docs and examples would be wrong. Do you get errors >>> using the nonimpl class at runtime ? >>> >>> Remember the whole point is that you can configure beans abstractly >>> and then at runtime they are instantiated with the concrete instances. >>> >>> /max (sent from my phone) >>> >>> >>> On 07/10/2011, at 18.54, Viacheslav Kabanovich&lt;scabanovich(a)exadel.com&gt; wrote: >>> >>>> Hi, Max >>>> >>>> org.jboss.seam.security.Identity is an interface and cannot be configured as a managed bean in config xml. >>>> org.jboss.seam.security.IdentityImpl is ok to be configured. >>>> >>>> I added validation that marks configuring abstract types as errors in JBIDE-9834 last week. >>>> >>>> Slava >>>> >>>> On 10/07/2011 04:53 AM, Max Rydahl Andersen wrote: >>>>> Hi Slava/Alexey, >>>>> >>>>> Have you seen this thread: http://seamframework.org/Community/SecurityCannotResolveMemberInNodeSecur... >>>>> referenced from http://community.jboss.org/message/630545#630545 >>>>> >>>>> It sounds very wrong that the Impl name is the correct one. >>>>> >>>>> Is the tool not validating wrong here ? >>>>> >>>>> /max >>>>> http://about.me/maxandersen >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> jbosstools-dev mailing list >>>>> jbosstools-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev