1:14 a.m.
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for
Seam Faces, and we've discovered that there is a new fact of life for
consumers of portable CDI extensions. Due to the fact that @Interceptors
cannot be enabled in the extensions themselves (due to restrictions on
beans.xml for purposes of absolute ordering in the application. See:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
- Exposed to the developer
- Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
- Consistently named and packaged to prevent refactoring / backwards
compatibility issues
- Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor
We would like to propose the following conventions in order to address the
above concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we forgot to
tie the ladder.)
3. A protected namespace so that when we refactor, we don't break their
world. (Even though #2 would catch it.)
I've updated the Seam 3 Development
Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines>to
reflect these conventions - they can be changed as needed pending the
outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
1:27 a.m.
This will be a major inconvenience for our users if we expect them to
manually add all the interceptors they need for conversations, security,
transactions, and who knows what else. Is there absolutely no other way
that we can automatically register these in the extension? Also I'm not
a big fan of having to use the org.jboss.seam.intercept namespace, I
don't want to have to include a lone class in this package if all my
other classes are in (for example the security module)
org.jboss.seam.security.
On 26/03/10 10:14, Lincoln Baxter, III wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation
support for Seam Faces, and we've discovered that there is a new fact
of life for consumers of portable CDI extensions. Due to the fact that
@Interceptors cannot be enabled in the extensions themselves (due to
restrictions on beans.xml for purposes of absolute ordering in the
application. See:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
* Exposed to the developer
* Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
* Consistently named and packaged to prevent refactoring /
backwards compatibility issues
* Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor
We would like to propose the following conventions in order to address
the above concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not
registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we
forgot to tie the ladder.)
3. A protected namespace so that when we refactor, we don't break
their world. (Even though #2 would catch it.)
I've updated the Seam 3 Development Guidelines
<http://seamframework.org/Seam3/DevelopmentGuidelines> to reflect
these conventions - they can be changed as needed pending the outcome
of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
1:31 a.m.
We could possibly add a non-portable way of doing this automatically for weld, document
that if you are using a different CDI provider you need to do this manually and push to
get it included in a later revision of the spec?
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
Shane Bryzak [sbryzak(a)redhat.com]
Sent: Friday, 26 March 2010 11:27 AM
To: Lincoln Baxter, III
Cc: Seam Dev List
Subject: Re: [seam-dev] Interceptor packaging convention
This will be a major inconvenience for our users if we expect them to manually add all the
interceptors they need for conversations, security, transactions, and who knows what else.
Is there absolutely no other way that we can automatically register these in the
extension? Also I'm not a big fan of having to use the org.jboss.seam.intercept
namespace, I don't want to have to include a lone class in this package if all my
other classes are in (for example the security module) org.jboss.seam.security.
On 26/03/10 10:14, Lincoln Baxter, III wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for Seam Faces,
and we've discovered that there is a new fact of life for consumers of portable CDI
extensions. Due to the fact that @Interceptors cannot be enabled in the extensions
themselves (due to restrictions on beans.xml for purposes of absolute ordering in the
application. See: http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good out-of-box experience,
but interceptors must be registered manually.
This means that @Interceptor classes must be:
* Exposed to the developer
* Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
* Consistently named and packaged to prevent refactoring / backwards compatibility
issues
* Checked at startup in order to warn devs that they are using annotations with no
enabled @Interceptor
We would like to propose the following conventions in order to address the above
concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using interceptable
@Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via
BeanManager.resolveInterceptors(type, interceptorBindings)
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we forgot to tie the
ladder.)
3. A protected namespace so that when we refactor, we don't break their world. (Even
though #2 would catch it.)
I've updated the Seam 3 Development
Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines> to reflect these
conventions - they can be changed as needed pending the outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org<mailto:seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
2:05 a.m.
That seems like an appropriate interim solution to me. We really need
to be on our toes when it comes to "complexity creep", and having
auto-registered interceptors should be a given seeing as our long-time
modus operandi has always been about providing sensible defaults.
On 26/03/10 10:31, Stuart Douglas wrote:
We could possibly add a non-portable way of doing this automatically
for weld, document that if you are using a different CDI provider you need to do this
manually and push to get it included in a later revision of the spec?
Stuart
________________________________________
From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org] On Behalf Of
Shane Bryzak [sbryzak(a)redhat.com]
Sent: Friday, 26 March 2010 11:27 AM
To: Lincoln Baxter, III
Cc: Seam Dev List
Subject: Re: [seam-dev] Interceptor packaging convention
This will be a major inconvenience for our users if we expect them to manually add all
the interceptors they need for conversations, security, transactions, and who knows what
else. Is there absolutely no other way that we can automatically register these in the
extension? Also I'm not a big fan of having to use the org.jboss.seam.intercept
namespace, I don't want to have to include a lone class in this package if all my
other classes are in (for example the security module) org.jboss.seam.security.
On 26/03/10 10:14, Lincoln Baxter, III wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for Seam Faces,
and we've discovered that there is a new fact of life for consumers of portable CDI
extensions. Due to the fact that @Interceptors cannot be enabled in the extensions
themselves (due to restrictions on beans.xml for purposes of absolute ordering in the
application. See: http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good out-of-box experience,
but interceptors must be registered manually.
This means that @Interceptor classes must be:
* Exposed to the developer
* Registered manually by the developer in beans.xml
-<interceptors>...</interceptors>
* Consistently named and packaged to prevent refactoring / backwards compatibility
issues
* Checked at startup in order to warn devs that they are using annotations with no
enabled @Interceptor
We would like to propose the following conventions in order to address the above
concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using interceptable
@Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via
BeanManager.resolveInterceptors(type, interceptorBindings)
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we forgot to tie the
ladder.)
3. A protected namespace so that when we refactor, we don't break their world.
(Even though #2 would catch it.)
I've updated the Seam 3 Development
Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines> to reflect these
conventions - they can be changed as needed pending the outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org<mailto:seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
4:25 a.m.
Agreed - Dan and I were both very upset when we found out about this
restriction. Then we spent a little while establishing these guidelines -
We're open to other options, but assuming we had to deal with what we have
today, that's what we came up with. I think it's a decent approach until we
can get some automatic registration support.
On Thu, Mar 25, 2010 at 9:05 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
That seems like an appropriate interim solution to me. We really
need to
be on our toes when it comes to "complexity creep", and having
auto-registered interceptors should be a given seeing as our long-time modus
operandi has always been about providing sensible defaults.
On 26/03/10 10:31, Stuart Douglas wrote:
> We could possibly add a non-portable way of doing this automatically for
> weld, document that if you are using a different CDI provider you need to do
> this manually and push to get it included in a later revision of the spec?
>
> Stuart
>
>
> ________________________________________
> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org]
> On Behalf Of Shane Bryzak [sbryzak(a)redhat.com]
> Sent: Friday, 26 March 2010 11:27 AM
> To: Lincoln Baxter, III
> Cc: Seam Dev List
> Subject: Re: [seam-dev] Interceptor packaging convention
>
> This will be a major inconvenience for our users if we expect them to
> manually add all the interceptors they need for conversations, security,
> transactions, and who knows what else. Is there absolutely no other way
> that we can automatically register these in the extension? Also I'm not a
> big fan of having to use the org.jboss.seam.intercept namespace, I don't
> want to have to include a lone class in this package if all my other classes
> are in (for example the security module) org.jboss.seam.security.
>
> On 26/03/10 10:14, Lincoln Baxter, III wrote:
> Seam Devs,
>
> Dan and I have been working on the @Begin and @End conversation support
> for Seam Faces, and we've discovered that there is a new fact of life for
> consumers of portable CDI extensions. Due to the fact that @Interceptors
> cannot be enabled in the extensions themselves (due to restrictions on
> beans.xml for purposes of absolute ordering in the application. See:
> http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
>
> This presents an interesting issue; we want to be providing a good
> out-of-box experience, but interceptors must be registered manually.
>
> This means that @Interceptor classes must be:
>
> * Exposed to the developer
> * Registered manually by the developer in beans.xml
> -<interceptors>...</interceptors>
> * Consistently named and packaged to prevent refactoring / backwards
> compatibility issues
> * Checked at startup in order to warn devs that they are using
> annotations with no enabled @Interceptor
>
> We would like to propose the following conventions in order to address the
> above concerns:
>
> All @Interceptor classes must:
>
> 1. Adhere to the following package and naming scheme:
> org.jboss.seam.intercept.*Interceptor
> 2. Warn users (or Error out when appropriate) if they are using
> interceptable @Annotations when the @Inteceptor itself is not registered:
> (@Interceptor registration can be checked in the Extension class
> AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
> interceptorBindings)
>
> This presents users with:
>
> 1. A consistent naming scheme to help prevent typos.
> 2. A safety net to catch them when they fall down (because we forgot to
> tie the ladder.)
> 3. A protected namespace so that when we refactor, we don't break their
> world. (Even though #2 would catch it.)
>
> I've updated the Seam 3 Development Guidelines<
> http://seamframework.org/Seam3/DevelopmentGuidelines> to reflect these
> conventions - they can be changed as needed pending the outcome of this
> discussion :)
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev@lists.jboss.org<mailto:seam-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5:32 a.m.
I should add, if anyone finds a way to get around this limitation -- it will
help all of us avoid a lot of pain.
On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Agreed - Dan and I were both very upset when we found out about this
restriction. Then we spent a little while establishing these guidelines -
We're open to other options, but assuming we had to deal with what we have
today, that's what we came up with. I think it's a decent approach until we
can get some automatic registration support.
On Thu, Mar 25, 2010 at 9:05 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> That seems like an appropriate interim solution to me. We really need to
> be on our toes when it comes to "complexity creep", and having
> auto-registered interceptors should be a given seeing as our long-time modus
> operandi has always been about providing sensible defaults.
>
>
> On 26/03/10 10:31, Stuart Douglas wrote:
>
>> We could possibly add a non-portable way of doing this automatically for
>> weld, document that if you are using a different CDI provider you need to do
>> this manually and push to get it included in a later revision of the spec?
>>
>> Stuart
>>
>>
>> ________________________________________
>> From: seam-dev-bounces(a)lists.jboss.org [seam-dev-bounces(a)lists.jboss.org]
>> On Behalf Of Shane Bryzak [sbryzak(a)redhat.com]
>> Sent: Friday, 26 March 2010 11:27 AM
>> To: Lincoln Baxter, III
>> Cc: Seam Dev List
>> Subject: Re: [seam-dev] Interceptor packaging convention
>>
>> This will be a major inconvenience for our users if we expect them to
>> manually add all the interceptors they need for conversations, security,
>> transactions, and who knows what else. Is there absolutely no other way
>> that we can automatically register these in the extension? Also I'm not a
>> big fan of having to use the org.jboss.seam.intercept namespace, I don't
>> want to have to include a lone class in this package if all my other classes
>> are in (for example the security module) org.jboss.seam.security.
>>
>> On 26/03/10 10:14, Lincoln Baxter, III wrote:
>> Seam Devs,
>>
>> Dan and I have been working on the @Begin and @End conversation support
>> for Seam Faces, and we've discovered that there is a new fact of life for
>> consumers of portable CDI extensions. Due to the fact that @Interceptors
>> cannot be enabled in the extensions themselves (due to restrictions on
>> beans.xml for purposes of absolute ordering in the application. See:
>> http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
>>
>> This presents an interesting issue; we want to be providing a good
>> out-of-box experience, but interceptors must be registered manually.
>>
>> This means that @Interceptor classes must be:
>>
>> * Exposed to the developer
>> * Registered manually by the developer in beans.xml
>> -<interceptors>...</interceptors>
>> * Consistently named and packaged to prevent refactoring / backwards
>> compatibility issues
>> * Checked at startup in order to warn devs that they are using
>> annotations with no enabled @Interceptor
>>
>> We would like to propose the following conventions in order to address
>> the above concerns:
>>
>> All @Interceptor classes must:
>>
>> 1. Adhere to the following package and naming scheme:
>> org.jboss.seam.intercept.*Interceptor
>> 2. Warn users (or Error out when appropriate) if they are using
>> interceptable @Annotations when the @Inteceptor itself is not registered:
>> (@Interceptor registration can be checked in the Extension class
>> AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
>> interceptorBindings)
>>
>> This presents users with:
>>
>> 1. A consistent naming scheme to help prevent typos.
>> 2. A safety net to catch them when they fall down (because we forgot to
>> tie the ladder.)
>> 3. A protected namespace so that when we refactor, we don't break their
>> world. (Even though #2 would catch it.)
>>
>> I've updated the Seam 3 Development Guidelines<
>> http://seamframework.org/Seam3/DevelopmentGuidelines> to reflect these
>> conventions - they can be changed as needed pending the outcome of this
>> discussion :)
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>>
>>
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev@lists.jboss.org<mailto:seam-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>>
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
6:28 p.m.
On Thu, Mar 25, 2010 at 11:25 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com
wrote:
Agreed - Dan and I were both very upset when we found out about this
restriction. Then we spent a little while establishing these guidelines -
We're open to other options, but assuming we had to deal with what we have
today, that's what we came up with. I think it's a decent approach until we
can get some automatic registration support.
I should add the pretext that Lincoln and I discussed this for two hours,
so we
didn't come to our conclusion lightly :)
On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls(a)gmail.com
wrote:
Perhaps I'm missing something here but can't the
ProcessModule event from
11.5.5 fix this with List<Class> getInterceptors()?
Two things. First, the ProcessModule did not make CDI 1.0, but was added
later. I'm not sure if the version containing it has been "released" or
approved. Second, that only gets you the interceptors. Lincoln and I were
tricked by that a couple of times...what we need is to modify the
*enabled*interceptors. That's where we keep getting bitten.
If you think long and hard about it, though, there is no way getting around
the fact that you need a single place (at least per module) where
interceptors are ordered absolutely. And that place must know about all the
interceptors that are to be used. Although interceptor ordering might not
often apply to an invocation, you need 100% assurance here, that is
consistent across all beans that join more than one interceptor.
Remember, in EJB 3.0, we had @Interceptors({Foo.class, Bar.class}), but
another developer could write it @Interceptors({Bar.class, Foo.class}) and
that potential for inconsistency is bad.
Maybe you'll be surprised (since I value simplicity as does Lincoln and
others) that Gavin's insistence on having this defined in the module's
beans.xml is the right thing. I don't like it for the same reasons as you,
because we are putting the interceptor classes right in the developer's face
and making him/her deal with enabling them in the right order.
The alternative, which is how it was done in Seam 2, is to have relative
ordering. So you say "this interceptor comes before these but after those
other ones". You could do that at the interceptor-level or by the bean
archive's beans.xml (this beans.xml comes before these but after those other
ones). <- same as listeners in JSF 2 and Servlet 3
In conclusion, let me remind you that the reason we have this problem is
because CDI extensions are not a closed system like Seam 2. In Seam 2, we
knew about every interceptor that existed and we could calculate the right
order for them. Now, any number of extensions can supply any interceptor and
not every extension can know about every other extension. And it may even
come down to the fact that a developer might want an interceptor from one
extension to be applied in a different order than another developer. It all
depends on what the interceptor is doing.
So what Lincoln and I decided was to make this as *easy* as possible on the
developer. And the consistent packaging of interceptors in Seam is
paramount. One possible alternative is to give interceptors aliases (@Named)
so the developer can activate the function ("seam.security") and not the
class ("org.jboss.seam.intercept.SecurityInterceptor").
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:35 p.m.
On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls(a)gmail.com
> wrote:
> Perhaps I'm missing something here but can't the ProcessModule event from
> 11.5.5 fix this with List<Class> getInterceptors()?
Two things. First, the ProcessModule did not make CDI 1.0, but was added
later. I'm not sure if the version containing it has been "released" or
approved. Second, that only gets you the interceptors. Lincoln and I were
tricked by that a couple of times...what we need is to modify the *enabled
* interceptors. That's where we keep getting bitten.
Oops! I was wrong. It does give you read/write access to the enabled
interceptors. Okay, so this would be a possibility to either add
interceptors or warn the developer to add them. But this listener would have
to still know about any and all interceptors that need to be enabled (if the
modules beans.xml is empty as we want it to be).
So we could provide a seam-interceptor-enabler.jar that would enable any
Seam interceptors on the classpath. We would only provide one such JAR file.
This is the right way to go. It only requires that we depend on the latest
version of the spec, which Weld doesn't yet support fully (not ProcessModule
at least).
Therefore, we have two possible ways forward. The developer lists out the
interceptors or we provide an enabler JAR. But remember, observer call order
is not portable, so if you have another enabler JAR from another extension
library, then how to order them gets tricky. The enabler really needs to be
a closed system.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
8:28 a.m.
I think AfterBeanDiscovery is enough (which is already in the spec) for the
autoenablement extension, right?
We could cast the BeanManager parameter to BeanManagerImpl and enable (and
perhaps sort) all org.seam.* interceptors etc that the BM is aware of. Since
there is a limited number of CDI implementations, we could also cast to
other implementations after checking (non-imported, reflection) which one we
are dealing with.
We could also throw in a
@AutoEnable(before="org.jboss.seam.foo.Interceptor")
annotation if want to control the order manually or if we want to offer
others to use this feature (in a seam context)
On Fri, Mar 26, 2010 at 7:35 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen
<dan.j.allen(a)gmail.com> wrote:
>
> On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls(a)gmail.com
> > wrote:
>
>> Perhaps I'm missing something here but can't the ProcessModule event
from
>> 11.5.5 fix this with List<Class> getInterceptors()?
>
>
> Two things. First, the ProcessModule did not make CDI 1.0, but was added
> later. I'm not sure if the version containing it has been "released"
or
> approved. Second, that only gets you the interceptors. Lincoln and I were
> tricked by that a couple of times...what we need is to modify the *
> enabled* interceptors. That's where we keep getting bitten.
>
Oops! I was wrong. It does give you read/write access to the enabled
interceptors. Okay, so this would be a possibility to either add
interceptors or warn the developer to add them. But this listener would have
to still know about any and all interceptors that need to be enabled (if the
modules beans.xml is empty as we want it to be).
So we could provide a seam-interceptor-enabler.jar that would enable any
Seam interceptors on the classpath. We would only provide one such JAR file.
This is the right way to go. It only requires that we depend on the latest
version of the spec, which Weld doesn't yet support fully (not ProcessModule
at least).
Therefore, we have two possible ways forward. The developer lists out the
interceptors or we provide an enabler JAR. But remember, observer call order
is not portable, so if you have another enabler JAR from another extension
library, then how to order them gets tricky. The enabler really needs to be
a closed system.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
9:31 a.m.
a) I still cannot find the paragraph in the spec where it is stated that only one single
beans.xml may contain a <interceptors> section.
En contraire, if you interpret the following sentences from 9.4
"If the same class is listed twice under the <interceptors> element, the
container automatically detects the problem and treats it as a deployment problem."
and
"An interceptor is said to be enabled if it is enabled in at least one bean
archive."
Especially the last sentence definitely makes clear that Lincolns use case should
'just work'. I think this is only a bug in Weld being overly strict and not in the
spec (this works in OWB btw).
b) such a enabler.jar would not work imo in a modular environment, because "If there
is no class with the specified name, or if the class with the specified name is not an
interceptor class, the container automatically detects the problem and treats it as a
deployment problem." So if one jar is not in the dependencies, the list must not
contain the Interceptors from this jar.
LieGrue,
strub
--- Nicklas Karlsson <nickarls(a)gmail.com> schrieb am Sa, 27.3.2010:
Von: Nicklas Karlsson <nickarls(a)gmail.com>
Betreff: Re: [seam-dev] Interceptor packaging convention
An: "Dan Allen" <dan.j.allen(a)gmail.com>
CC: "Seam Dev List" <seam-dev(a)lists.jboss.org>
Datum: Samstag, 27. März, 2010 08:28 Uhr
I think AfterBeanDiscovery is enough (which is already in the spec) for the autoenablement
extension, right?
We could cast the BeanManager parameter to BeanManagerImpl and enable (and perhaps sort)
all org.seam.* interceptors etc that the BM is aware of. Since there is a limited number
of CDI implementations, we could also cast to other implementations after checking
(non-imported, reflection) which one we are dealing with.
We could also throw in a
@AutoEnable(before="org.jboss.seam.foo.Interceptor")
annotation if want to control the order manually or if we want to offer others to use this
feature (in a seam context)
On Fri, Mar 26, 2010 at 7:35 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
Perhaps I'm missing something here but can't the ProcessModule event from 11.5.5
fix this with List<Class> getInterceptors()?
Two things. First, the ProcessModule did not make CDI 1.0, but was added later. I'm
not sure if the version containing it has been "released" or approved. Second,
that only gets you the interceptors. Lincoln and I were tricked by that a couple of
times...what we need is to modify the enabled interceptors. That's where we keep
getting bitten.
Oops! I was wrong. It does give you read/write access to the enabled interceptors. Okay,
so this would be a possibility to either add interceptors or warn the developer to add
them. But this listener would have to still know about any and all interceptors that need
to be enabled (if the modules beans.xml is empty as we want it to be).
So we could provide a seam-interceptor-enabler.jar that would enable any Seam interceptors
on the classpath. We would only provide one such JAR file. This is the right way to go. It
only requires that we depend on the latest version of the spec, which Weld doesn't yet
support fully (not ProcessModule at least).
Therefore, we have two possible ways forward. The developer lists out the interceptors or
we provide an enabler JAR. But remember, observer call order is not portable, so if you
have another enabler JAR from another extension library, then how to order them gets
tricky. The enabler really needs to be a closed system.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
-----Integrierter Anhang folgt-----
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
12:09 p.m.
>>Especially the last sentence definitely makes clear that Lincolns use
case should 'just work'. I think this is only a bug in Weld being overly
strict and not in the spec (this works in OWB btw).
And that should be checked against trunk since I made some changes there and
the stack trace origins from a place that no longer exists...
b) such a enabler.jar would not work imo in a modular environment,
because
"If there is no class with the specified name, or if the class with the
specified name is not an interceptor class, the container automatically
detects the problem and treats it as a deployment problem." So if one jar is
not in the dependencies, the list must not contain the Interceptors from
this jar.
I don't think that's an issue since we would only enable stuff already
known
to the bean manager. In fact, it would be safer than enablement through
beans.xml, not?
LieGrue,
strub
--- Nicklas Karlsson *<nickarls(a)gmail.com>* schrieb am *Sa, 27.3.2010:
*
*
Von: Nicklas Karlsson <nickarls(a)gmail.com>
Betreff: Re: [seam-dev] Interceptor packaging convention
An: "Dan Allen" <dan.j.allen(a)gmail.com>
CC: "Seam Dev List" <seam-dev(a)lists.jboss.org>
Datum: Samstag, 27. März, 2010 08:28 Uhr
*
*I think AfterBeanDiscovery is enough (which is already in the spec) for
the autoenablement extension, right?*
*
*
*We could cast the BeanManager parameter to BeanManagerImpl and enable
(and perhaps sort) all org.seam.* interceptors etc that the BM is aware of.
Since there is a limited number of CDI implementations, we could also cast
to other implementations after checking (non-imported, reflection) which one
we are dealing with.*
*
*
*We could also throw in a*
*
*
*(a)AutoEnable(before="org.jboss.seam.foo.Interceptor") *
*
*
*annotation if want to control the order manually or if we want to offer
others to use this feature (in a seam context)*
*
*
*On Fri, Mar 26, 2010 at 7:35 PM, Dan Allen
<dan.j.allen@gmail.com<http://mc/compose?to=dan.j.allen@gmail.com>
> wrote:
*
>
> *On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen
<dan.j.allen@gmail.com<http://mc/compose?to=dan.j.allen@gmail.com>
> > wrote:
> *
>>
>> *
>> *
>> *On Thu, Mar 25, 2010 at 11:25 PM, Nicklas Karlsson
<nickarls@gmail.com<http://mc/compose?to=nickarls@gmail.com>
>> > wrote:*
>>
>>> *Perhaps I'm missing something here but can't the ProcessModule
event
>>> from 11.5.5 fix this with List<Class> getInterceptors()?*
>>
>> *
>> *
>> *Two things. First, the ProcessModule did not make CDI 1.0, but was
>> added later. I'm not sure if the version containing it has been
"released"
>> or approved. Second, that only gets you the interceptors. Lincoln and I were
>> tricked by that a couple of times...what we need is to modify the
>> enabled interceptors. That's where we keep getting bitten.*
>>
> *
> *
> *Oops! I was wrong. It does give you read/write access to the enabled
> interceptors. Okay, so this would be a possibility to either add
> interceptors or warn the developer to add them. But this listener would have
> to still know about any and all interceptors that need to be enabled (if the
> modules beans.xml is empty as we want it to be).*
> *
> *
> *So we could provide a seam-interceptor-enabler.jar that would enable any
> Seam interceptors on the classpath. We would only provide one such JAR file.
> This is the right way to go. It only requires that we depend on the latest
> version of the spec, which Weld doesn't yet support fully (not ProcessModule
> at least).*
> *
> *
> *Therefore, we have two possible ways forward. The developer lists out
> the interceptors or we provide an enabler JAR. But remember, observer call
> order is not portable, so if you have another enabler JAR from another
> extension library, then how to order them gets tricky. The enabler really
> needs to be a closed system.*
> *
> *
> *
> -Dan
>
> *
> *--
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
> *
> *
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org <http://mc/compose?to=seam-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
> *
*
--
---
Nik
*
*
-----Integrierter Anhang folgt-----
*
*_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org <http://mc/compose?to=seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
*
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz
gegen Massenmails.
http://mail.yahoo.com
--
---
Nik
7:07 p.m.
On Sat, Mar 27, 2010 at 4:31 AM, Mark Struberg <struberg(a)yahoo.de> wrote:
a) I still cannot find the paragraph in the spec where it is stated
that
only one single beans.xml may contain a <interceptors> section.
En contraire, if you interpret the following sentences from 9.4
"If the same class is listed twice under the <interceptors> element, the
container automatically detects the problem and treats it as a deployment
problem."
and
"An interceptor is said to be enabled if it is enabled in at least one bean
archive."
Especially the last sentence definitely makes clear that Lincolns use case
should 'just work'. I think this is only a bug in Weld being overly strict
and not in the spec (this works in OWB btw).
You know, I'm sensing some inconsistency here in the information I've heard.
I've seen Gavin explain that interceptors are only enabled by module, yet
that isn't explicitly stated in the spec. Also, the section you found gives
no indication of the limitation we've been talking about.
To me, the restriction makes sense because what order is used if two
interceptors applied to the same class are activated in different bean
archives. But the spec does seem to allow for that case after all. Mark,
what order would OWB use? Nik, if this is fixed in Weld, what order does
Weld use?
b) such a enabler.jar would not work imo in a modular environment, because
"If there is no class with the specified name, or if the class with the
specified name is not an interceptor class, the container automatically
detects the problem and treats it as a deployment problem." So if one jar is
not in the dependencies, the list must not contain the Interceptors from
this jar.
Naturally we would check to see if the class is registered as a bean before
adding it to the enabled interceptor list, if we took this approach.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
7:08 p.m.
On Sat, Mar 27, 2010 at 3:28 AM, Nicklas Karlsson <nickarls(a)gmail.com>wrote:
I think AfterBeanDiscovery is enough (which is already in the spec)
for the
autoenablement extension, right?
We could cast the BeanManager parameter to BeanManagerImpl and enable (and
perhaps sort) all org.seam.* interceptors etc that the BM is aware of. Since
there is a limited number of CDI implementations, we could also cast to
other implementations after checking (non-imported, reflection) which one we
are dealing with.
We could also throw in a
@AutoEnable(before="org.jboss.seam.foo.Interceptor")
annotation if want to control the order manually or if we want to
offer
others to use this feature (in a seam context)
True, we could go down that road.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:38 p.m.
On Fri, Mar 26, 2010 at 1:28 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
Maybe you'll be surprised (since I value simplicity as does Lincoln and
others) that Gavin's insistence on having this defined in the module's
beans.xml is the right thing.
That sentence got garbled. I defend Gavin's insistence, though I share the
distaste of it spoiling simplicity.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:40 p.m.
One possible alternative is to give interceptors aliases (@Named) so the
developer can activate the function ("seam.security") and not the class
("org.jboss.seam.intercept.SecurityInterceptor").
But that, of course, would require a spec change (or a non-portable
extension).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:30 p.m.
I think you guys have got this wrong. CDI was deliberately designed to
require explicit declaration of interceptors. We thought VERY HARD
about this, and realized that this was the best way to go. Any
auto-registration of interceptors runs into all kinds of problems down
the road:
(1) When I use two frameworks together, or add my own interceptor to
the interceptors defined by a framework, what is its ordering with
respect to the interceptors that already exist?
(2) How do I turn an interceptor off?
Look, CDI is supposed to be an ecosystem for multiple portable
extensions that play nicely together. Auto-enablement of interceptors
gets you into the total clusterfuck of phase listeners in JSF.
Don't go down this path.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
8:03 p.m.
Tools might also be helpful in setting up interceptors based on what you
have available, I suppose. And the list of interceptors for a normal Seam 3
application is hopefully shorter than that from a Seam 2 app.
On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <gavin.king(a)gmail.com> wrote:
I think you guys have got this wrong. CDI was deliberately designed
to
require explicit declaration of interceptors. We thought VERY HARD
about this, and realized that this was the best way to go. Any
auto-registration of interceptors runs into all kinds of problems down
the road:
(1) When I use two frameworks together, or add my own interceptor to
the interceptors defined by a framework, what is its ordering with
respect to the interceptors that already exist?
(2) How do I turn an interceptor off?
Look, CDI is supposed to be an ecosystem for multiple portable
extensions that play nicely together. Auto-enablement of interceptors
gets you into the total clusterfuck of phase listeners in JSF.
Don't go down this path.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
8:10 p.m.
It depends -- each module could have a number of interceptors. You'd turn
the interceptors off by excluding the global enabler dependency that Dan
described, or re-including it as <provided> - whichever you see fit.
Perhaps yet another option would be to separate auto-registered interceptors
into their own maven sub-modules, if we REALLY need to be that specific.
This way you could include to enable each interceptor manually:
- seam-faces
- seam-faces-conversations
- seam-faces-security
But again, and I am going to stand by this vehemently: I want automatic
registration of interceptors. Provide what users want 95% of the time, and
allow them to become more granular ONLY if they are in that 5% case -- but
don't require every user to understand the ugly, complicated 5%. That's how
Java EE, JSF, EJB, SOAP, etc, all lost their reputations.
Developer experience is crucial when designing this kind of interaction in a
framework. These things will be the difference between adoption and
abandonment.
--Lincoln
On Mon, Mar 29, 2010 at 2:03 PM, Nicklas Karlsson <nickarls(a)gmail.com>wrote:
Tools might also be helpful in setting up interceptors based on what
you
have available, I suppose. And the list of interceptors for a normal Seam 3
application is hopefully shorter than that from a Seam 2 app.
On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <gavin.king(a)gmail.com> wrote:
> I think you guys have got this wrong. CDI was deliberately designed to
> require explicit declaration of interceptors. We thought VERY HARD
> about this, and realized that this was the best way to go. Any
> auto-registration of interceptors runs into all kinds of problems down
> the road:
>
> (1) When I use two frameworks together, or add my own interceptor to
> the interceptors defined by a framework, what is its ordering with
> respect to the interceptors that already exist?
>
> (2) How do I turn an interceptor off?
>
> Look, CDI is supposed to be an ecosystem for multiple portable
> extensions that play nicely together. Auto-enablement of interceptors
> gets you into the total clusterfuck of phase listeners in JSF.
>
> Don't go down this path.
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
--
---
Nik
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
8:32 p.m.
This topic was already discussed here:
http://relation.to/Bloggers/OnCDIInterceptorBindings
and here:
http://www.seamframework.org/Community/EnablingAnInterceptorInALibrary
so far no-one has proposed any solution that allows auto-registration
and avoids the multiple-portable-extension clusterfuck.
Trust me, this stuff was *very* carefully thought out by the expert
group. It is the way it is for very good reasons.
On Mon, Mar 29, 2010 at 2:10 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
It depends -- each module could have a number of interceptors.
You'd turn
the interceptors off by excluding the global enabler dependency that Dan
described, or re-including it as <provided> - whichever you see fit.
Perhaps yet another option would be to separate auto-registered interceptors
into their own maven sub-modules, if we REALLY need to be that specific.
This way you could include to enable each interceptor manually:
seam-faces
seam-faces-conversations
seam-faces-security
But again, and I am going to stand by this vehemently: I want automatic
registration of interceptors. Provide what users want 95% of the time, and
allow them to become more granular ONLY if they are in that 5% case -- but
don't require every user to understand the ugly, complicated 5%. That's how
Java EE, JSF, EJB, SOAP, etc, all lost their reputations.
Developer experience is crucial when designing this kind of interaction in a
framework. These things will be the difference between adoption and
abandonment.
--Lincoln
On Mon, Mar 29, 2010 at 2:03 PM, Nicklas Karlsson <nickarls(a)gmail.com>
wrote:
>
> Tools might also be helpful in setting up interceptors based on what you
> have available, I suppose. And the list of interceptors for a normal Seam 3
> application is hopefully shorter than that from a Seam 2 app.
>
> On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <gavin.king(a)gmail.com> wrote:
>>
>> I think you guys have got this wrong. CDI was deliberately designed to
>> require explicit declaration of interceptors. We thought VERY HARD
>> about this, and realized that this was the best way to go. Any
>> auto-registration of interceptors runs into all kinds of problems down
>> the road:
>>
>> (1) When I use two frameworks together, or add my own interceptor to
>> the interceptors defined by a framework, what is its ordering with
>> respect to the interceptors that already exist?
>>
>> (2) How do I turn an interceptor off?
>>
>> Look, CDI is supposed to be an ecosystem for multiple portable
>> extensions that play nicely together. Auto-enablement of interceptors
>> gets you into the total clusterfuck of phase listeners in JSF.
>>
>> Don't go down this path.
>>
>> --
>> Gavin King
>> gavin.king(a)gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> --
> ---
> Nik
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
8:47 p.m.
I understand the technical reasons why interceptor ordering is important,
but I disagree completely with the lack of options, or ability to ignore
said technical reasons. The reason the enabler jar works well is because it
provides a consistent way to order interceptors *within* the Seam framework.
95% of the time that is going to be enough. 5% of the time it's not.
Why should we force people to work extra hard to get things working, when
they should only have to work extra hard if there is a problem? Think of it
from the POV of a user: Do they want to fix things to get started? Or do
they want to fix things only if they are broken?
This isn't a matter of technical correctness, we can ensure technical
correctness by allowing users to exclude the Seam-enabler.jar from their POM
and fall back to Beans.xml for manual interceptor registration.
This is a matter of usability, and being developer-centric:
Technical constraints cannot enforce social practices (as CDI is doing by
preventing automatic interceptor registration), so it's best to try not to
-- this is the perfect example. We have several people who are already
willing to violate best practices of "Designing to the Interface," by
referencing the implementation specifics, to get this working. If CDI
provided a standard "incorrect" way of doing it, we could do things "the
bad
way" without breaking any more rules.
It doesn't matter how much technical thought went into it -- if CDIs
consumers want to do something, they'll figure out how to do it anyway --
the question is purely, "how annoyed do we want them to feel at the end of
the day?"
I think the enabler JAR is a good way to hide complexity, while still
allowing for technical correctness *if required.*
--Lincoln
On Mon, Mar 29, 2010 at 2:32 PM, Gavin King <gavin.king(a)gmail.com> wrote:
This topic was already discussed here:
http://relation.to/Bloggers/OnCDIInterceptorBindings
and here:
http://www.seamframework.org/Community/EnablingAnInterceptorInALibrary
so far no-one has proposed any solution that allows auto-registration
and avoids the multiple-portable-extension clusterfuck.
Trust me, this stuff was *very* carefully thought out by the expert
group. It is the way it is for very good reasons.
On Mon, Mar 29, 2010 at 2:10 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
> It depends -- each module could have a number of interceptors. You'd turn
> the interceptors off by excluding the global enabler dependency that Dan
> described, or re-including it as <provided> - whichever you see fit.
>
> Perhaps yet another option would be to separate auto-registered
interceptors
> into their own maven sub-modules, if we REALLY need to be that specific.
> This way you could include to enable each interceptor manually:
>
> seam-faces
> seam-faces-conversations
> seam-faces-security
>
> But again, and I am going to stand by this vehemently: I want automatic
> registration of interceptors. Provide what users want 95% of the time,
and
> allow them to become more granular ONLY if they are in that 5% case --
but
> don't require every user to understand the ugly, complicated 5%. That's
how
> Java EE, JSF, EJB, SOAP, etc, all lost their reputations.
>
> Developer experience is crucial when designing this kind of interaction
in a
> framework. These things will be the difference between adoption and
> abandonment.
>
> --Lincoln
>
> On Mon, Mar 29, 2010 at 2:03 PM, Nicklas Karlsson <nickarls(a)gmail.com>
> wrote:
>>
>> Tools might also be helpful in setting up interceptors based on what you
>> have available, I suppose. And the list of interceptors for a normal
Seam 3
>> application is hopefully shorter than that from a Seam 2 app.
>>
>> On Mon, Mar 29, 2010 at 7:30 PM, Gavin King <gavin.king(a)gmail.com>
wrote:
>>>
>>> I think you guys have got this wrong. CDI was deliberately designed to
>>> require explicit declaration of interceptors. We thought VERY HARD
>>> about this, and realized that this was the best way to go. Any
>>> auto-registration of interceptors runs into all kinds of problems down
>>> the road:
>>>
>>> (1) When I use two frameworks together, or add my own interceptor to
>>> the interceptors defined by a framework, what is its ordering with
>>> respect to the interceptors that already exist?
>>>
>>> (2) How do I turn an interceptor off?
>>>
>>> Look, CDI is supposed to be an ecosystem for multiple portable
>>> extensions that play nicely together. Auto-enablement of interceptors
>>> gets you into the total clusterfuck of phase listeners in JSF.
>>>
>>> Don't go down this path.
>>>
>>> --
>>> Gavin King
>>> gavin.king(a)gmail.com
>>> http://in.relation.to/Bloggers/Gavin
>>> http://hibernate.org
>>> http://seamframework.org
>>> _______________________________________________
>>> seam-dev mailing list
>>> seam-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>>
>> --
>> ---
>> Nik
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
8:56 p.m.
On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
I understand the technical reasons why interceptor ordering is
important,
but I disagree completely with the lack of options, or ability to ignore
said technical reasons. The reason the enabler jar works well is because it
provides a consistent way to order interceptors *within* the Seam framework.
95% of the time that is going to be enough. 5% of the time it's not.
I just don't buy this. It's going to work fine when you ONLY have the
Seam interceptors, and don't have any other interceptors. As soon as
you start adding your own interceptors, or the interceptors of another
framework, it's HIGHLY likely that you're going to need to specify
their precedence w.r.t. the Seam interceptors.
Why should we force people to work extra hard to get things working,
when
they should only have to work extra hard if there is a problem? Think of it
from the POV of a user: Do they want to fix things to get started? Or do
they want to fix things only if they are broken?
Thanks for the lecture on the need to make things easy for users.
Clearly it's an issue that had not occurred to me before. Wow, I had
never considered thinking of things from the POV of a user!
This isn't a matter of technical correctness, we can ensure
technical
correctness by allowing users to exclude the Seam-enabler.jar from their POM
and fall back to Beans.xml for manual interceptor registration.
And how is this solution easier than just giving people a standard,
pre-written beans.xml file that they include in their Seam projects as
a starting point? It can even be added automatically by JBoss Tools or
the Maven archectype. Then, when they come to add their own
interceptors, it's easy to just edit this file.
Including a jar in the classpath is actually much more work than
including a pre-written beans.xml file!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:03 p.m.
Thanks for the lecture on the need to make things easy for users.
Clearly it's an issue that had not occurred to me before. Wow, I had
never considered thinking of things from the POV of a user!
It's a point I seem to make frequently.
Including a jar in the classpath is actually much more work than
including a pre-written beans.xml file!
That's why the JAR is included by default via Maven -- or provided in the
"Dump these jars into your app" folder that we have in the Dist-releases. No
extra work required to include it.
You mentioned this a few times, so I'll bite: What other kind of frameworks,
those that would provide interceptors, do you see people needing to use,
specifically those that would conflict with our interceptors? Frameworks
that more than 5% of people will be using.
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
9:21 p.m.
On Mon, Mar 29, 2010 at 3:03 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
> Thanks for the lecture on the need to make things easy for users.
> Clearly it's an issue that had not occurred to me before. Wow, I had
> never considered thinking of things from the POV of a user!
It's a point I seem to make frequently.
Then stop now. Because I guarantee you that everyone on this team
spends a lot of time thinking about usability and doesn't need to be
lectured on the topic.
> Including a jar in the classpath is actually much more work than
> including a pre-written beans.xml file!
That's why the JAR is included by default via Maven -- or provided in the
"Dump these jars into your app" folder that we have in the Dist-releases. No
extra work required to include it.
And so I repeat my question: how is this better than a pre-written XML
file that is included by default?
You mentioned this a few times, so I'll bite: What other kind of
frameworks,
those that would provide interceptors, do you see people needing to use,
specifically those that would conflict with our interceptors? Frameworks
that more than 5% of people will be using.
I expect that a very high percentage (>50%) of CDI portable extensions
will include at least one interceptor. And if Seam is the only
portable extension that users are going to be using then CDI has, by
definition, failed. The whole reason for doing this stuff was to
create a platform for portable extensions to the programming model of
Java EE.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
9:50 p.m.
> That's why the JAR is included by default via Maven -- or
provided in the
> "Dump these jars into your app" folder that we have in the Dist-releases.
No
> extra work required to include it.
And so I repeat my question: how is this better than a pre-written XML
file that is included by default?
What is required for a class to be interceptor?
(haven't been in JEE world for a while :-))
Does it need to implement some interface?
Or is proper api enough -- e.g. a plain class which has the right method?
(in JBoss AOP, afair, it was enough to have single param method "invoke" with
InvocationContext param)
Just asking on how to easily recognize the interceptors,
since I've just written a single-pass scanning MC lib [1],
where it would be trivial to add recognized interceptors by default to Weld'
metadata.
(we already do/add a bunch of default things for things we recognize as Weld in
JBossAS/MC)
But I guess we then introduce ordering issue?
[1] - no more need to do multiple scans in diff JBossAS components
e.g. Hibernate Scanner impl:
http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/sr...
10:02 p.m.
It would probably work for us but would be non-portable, right?
*IF* we go down the route of auto-enablement, it would probably be easy to
have the Seam 3 config @Injected into the extension and check from a field
if the enabling is turned on or off (set in XML or wherever) so no need to
exclude/include jars.
On Mon, Mar 29, 2010 at 10:50 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
>> That's why the JAR is included by default via Maven --
or provided in
the
>> "Dump these jars into your app" folder that we have in the
Dist-releases. No
>> extra work required to include it.
>
> And so I repeat my question: how is this better than a pre-written XML
> file that is included by default?
What is required for a class to be interceptor?
(haven't been in JEE world for a while :-))
Does it need to implement some interface?
Or is proper api enough -- e.g. a plain class which has the right method?
(in JBoss AOP, afair, it was enough to have single param method "invoke"
with InvocationContext param)
Just asking on how to easily recognize the interceptors,
since I've just written a single-pass scanning MC lib [1],
where it would be trivial to add recognized interceptors by default to
Weld' metadata.
(we already do/add a bunch of default things for things we recognize as
Weld in JBossAS/MC)
But I guess we then introduce ordering issue?
[1] - no more need to do multiple scans in diff JBossAS components
e.g. Hibernate Scanner impl:
http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/sr...
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
10:32 p.m.
For documentation (not conversation) purposes -- this approach has already
been discussed:
/**
* A small non-portable Weld PoC enabler that does not take many factors
(incl. class runtime availability) into account:
*/
public class SeamInterceptorEnablerExtension implements Extension
{
public void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery
event, final BeanManager manager)
{
if (manager instanceof BeanManagerImpl)
{
BeanManagerImpl impl = (BeanManagerImpl) manager;
// Enable interceptors in order here
// enableInterceptor(impl, YourInterceptor1.class);
// enableInterceptor(impl, YourInterceptor2.class);
// enableInterceptor(impl, YourInterceptor3.class); ... and more
}
}
private void enableInterceptor(final BeanManagerImpl impl, final Class<?>
type)
{
List<Class<?>> list = new ArrayList<Class<?>>();
list.addAll(impl.getEnabledInterceptorClasses());
list.add(type);
impl.setEnabledInterceptorClasses(list);
}
}
On Mon, Mar 29, 2010 at 4:02 PM, Nicklas Karlsson <nickarls(a)gmail.com>wrote:
It would probably work for us but would be non-portable, right?
*IF* we go down the route of auto-enablement, it would probably be easy to
have the Seam 3 config @Injected into the extension and check from a field
if the enabling is turned on or off (set in XML or wherever) so no need to
exclude/include jars.
On Mon, Mar 29, 2010 at 10:50 PM, Ales Justin <ales.justin(a)gmail.com>wrote:
> >> That's why the JAR is included by default via Maven -- or provided in
> the
> >> "Dump these jars into your app" folder that we have in the
> Dist-releases. No
> >> extra work required to include it.
> >
> > And so I repeat my question: how is this better than a pre-written XML
> > file that is included by default?
>
> What is required for a class to be interceptor?
> (haven't been in JEE world for a while :-))
>
> Does it need to implement some interface?
> Or is proper api enough -- e.g. a plain class which has the right method?
> (in JBoss AOP, afair, it was enough to have single param method "invoke"
> with InvocationContext param)
>
> Just asking on how to easily recognize the interceptors,
> since I've just written a single-pass scanning MC lib [1],
> where it would be trivial to add recognized interceptors by default to
> Weld' metadata.
> (we already do/add a bunch of default things for things we recognize as
> Weld in JBossAS/MC)
>
> But I guess we then introduce ordering issue?
>
> [1] - no more need to do multiple scans in diff JBossAS components
> e.g. Hibernate Scanner impl:
>
http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/sr...
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
--
---
Nik
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5:17 a.m.
I don't see the harm in prototyping this idea of auto-enablement. That's
exactly what the Seam sandbox is for [1]. I think if someone has an
approach, and other people in the community are interested in said approach,
then we should allow that idea to bloom. That's the spirit of open source
and community. Just because the experts deliberated over it and devised a
solution which that group considers ideal does not mean that developers will
just accept it. Maybe they want to include an extra JAR file. Let's let them
decide what it best for them. We are certainly not spoiling the modules nor
are we attempting to change CDI in any way. This is all in how you consume
it.
So, without further bickering, let's allow the visionaries to carry on with
their vision and see how it plays out. Developers can always choose to stick
with beans.xml if they want to be purists.
-Dan
[1] http://anonsvn.jboss.org/repos/seam/sandbox/trunk/modules/
On Mon, Mar 29, 2010 at 4:32 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
For documentation (not conversation) purposes -- this approach has
already
been discussed:
/**
* A small non-portable Weld PoC enabler that does not take many factors
(incl. class runtime availability) into account:
*/
public class SeamInterceptorEnablerExtension implements Extension
{
public void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery
event, final BeanManager manager)
{
if (manager instanceof BeanManagerImpl)
{
BeanManagerImpl impl = (BeanManagerImpl) manager;
// Enable interceptors in order here
// enableInterceptor(impl, YourInterceptor1.class);
// enableInterceptor(impl, YourInterceptor2.class);
// enableInterceptor(impl, YourInterceptor3.class); ... and more
}
}
private void enableInterceptor(final BeanManagerImpl impl, final
Class<?> type)
{
List<Class<?>> list = new ArrayList<Class<?>>();
list.addAll(impl.getEnabledInterceptorClasses());
list.add(type);
impl.setEnabledInterceptorClasses(list);
}
}
On Mon, Mar 29, 2010 at 4:02 PM, Nicklas Karlsson <nickarls(a)gmail.com>wrote:
> It would probably work for us but would be non-portable, right?
>
> *IF* we go down the route of auto-enablement, it would probably be easy to
> have the Seam 3 config @Injected into the extension and check from a field
> if the enabling is turned on or off (set in XML or wherever) so no need to
> exclude/include jars.
>
>
> On Mon, Mar 29, 2010 at 10:50 PM, Ales Justin <ales.justin(a)gmail.com>wrote:
>
>> >> That's why the JAR is included by default via Maven -- or provided
in
>> the
>> >> "Dump these jars into your app" folder that we have in the
>> Dist-releases. No
>> >> extra work required to include it.
>> >
>> > And so I repeat my question: how is this better than a pre-written XML
>> > file that is included by default?
>>
>> What is required for a class to be interceptor?
>> (haven't been in JEE world for a while :-))
>>
>> Does it need to implement some interface?
>> Or is proper api enough -- e.g. a plain class which has the right method?
>> (in JBoss AOP, afair, it was enough to have single param method
"invoke"
>> with InvocationContext param)
>>
>> Just asking on how to easily recognize the interceptors,
>> since I've just written a single-pass scanning MC lib [1],
>> where it would be trivial to add recognized interceptors by default to
>> Weld' metadata.
>> (we already do/add a bunch of default things for things we recognize as
>> Weld in JBossAS/MC)
>>
>> But I guess we then introduce ordering issue?
>>
>> [1] - no more need to do multiple scans in diff JBossAS components
>> e.g. Hibernate Scanner impl:
>>
http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/sr...
>>
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> --
> ---
> Nik
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
2:23 p.m.
This is a pretty nasty IMO, we won't include this in Seam 3.
I think Shane's approach of having your module log a warning if your required
interceptor is missing is a *much* better approach. We can add a utility method to
weld-extensions that you can call:
class Interceptors {
void warnIfDisabled(Class<?>... interceptorClasses) {
...
}
}
BTW A slightly better approach (which avoids at least the nastiness of this approach, but
doesn't avoid the issue of ordering - which IMO is insurmountable) is to write a
SeamInterceptor which can cope with using relative ordering semantics and require users to
just enable that.
On 30 Mar 2010, at 04:17, Dan Allen wrote:
I don't see the harm in prototyping this idea of auto-enablement.
That's exactly what the Seam sandbox is for [1]. I think if someone has an approach,
and other people in the community are interested in said approach, then we should allow
that idea to bloom. That's the spirit of open source and community. Just because the
experts deliberated over it and devised a solution which that group considers ideal does
not mean that developers will just accept it. Maybe they want to include an extra JAR
file. Let's let them decide what it best for them. We are certainly not spoiling the
modules nor are we attempting to change CDI in any way. This is all in how you consume
it.
So, without further bickering, let's allow the visionaries to carry on with their
vision and see how it plays out. Developers can always choose to stick with beans.xml if
they want to be purists.
-Dan
[1] http://anonsvn.jboss.org/repos/seam/sandbox/trunk/modules/
On Mon, Mar 29, 2010 at 4:32 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
wrote:
For documentation (not conversation) purposes -- this approach has already been
discussed:
/**
* A small non-portable Weld PoC enabler that does not take many factors (incl. class
runtime availability) into account:
*/
public class SeamInterceptorEnablerExtension implements Extension
{
public void beforeBeanDiscovery(@Observes final BeforeBeanDiscovery event, final
BeanManager manager)
{
if (manager instanceof BeanManagerImpl)
{
BeanManagerImpl impl = (BeanManagerImpl) manager;
// Enable interceptors in order here
// enableInterceptor(impl, YourInterceptor1.class);
// enableInterceptor(impl, YourInterceptor2.class);
// enableInterceptor(impl, YourInterceptor3.class); ... and more
}
}
private void enableInterceptor(final BeanManagerImpl impl, final Class<?> type)
{
List<Class<?>> list = new ArrayList<Class<?>>();
list.addAll(impl.getEnabledInterceptorClasses());
list.add(type);
impl.setEnabledInterceptorClasses(list);
}
}
On Mon, Mar 29, 2010 at 4:02 PM, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
It would probably work for us but would be non-portable, right?
*IF* we go down the route of auto-enablement, it would probably be easy to have the Seam
3 config @Injected into the extension and check from a field if the enabling is turned on
or off (set in XML or wherever) so no need to exclude/include jars.
On Mon, Mar 29, 2010 at 10:50 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
>> That's why the JAR is included by default via Maven -- or provided in the
>> "Dump these jars into your app" folder that we have in the
Dist-releases. No
>> extra work required to include it.
>
> And so I repeat my question: how is this better than a pre-written XML
> file that is included by default?
What is required for a class to be interceptor?
(haven't been in JEE world for a while :-))
Does it need to implement some interface?
Or is proper api enough -- e.g. a plain class which has the right method?
(in JBoss AOP, afair, it was enough to have single param method "invoke" with
InvocationContext param)
Just asking on how to easily recognize the interceptors,
since I've just written a single-pass scanning MC lib [1],
where it would be trivial to add recognized interceptors by default to Weld'
metadata.
(we already do/add a bunch of default things for things we recognize as Weld in
JBossAS/MC)
But I guess we then introduce ordering issue?
[1] - no more need to do multiple scans in diff JBossAS components
e.g. Hibernate Scanner impl:
http://anonsvn.jboss.org/repos/jbossas/projects/scanning/trunk/plugins/sr...
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
---
Nik
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
6:11 a.m.
On Wed, Apr 7, 2010 at 7:23 AM, Pete Muir <pmuir(a)redhat.com> wrote:
BTW A slightly better approach (which avoids at least the nastiness
of this approach, but
doesn't avoid the issue of ordering - which IMO is insurmountable) is to write a
SeamInterceptor which can cope with using relative ordering semantics and require users
to just enable that.
Sure, but the problem is that then you can't interleave other
interceptors with the Seam interceptors.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
1:26 p.m.
On 11 Apr 2010, at 05:11, Gavin King wrote:
On Wed, Apr 7, 2010 at 7:23 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> BTW A slightly better approach (which avoids at least the nastiness of this approach,
but
> doesn't avoid the issue of ordering - which IMO is insurmountable) is to write
a
> SeamInterceptor which can cope with using relative ordering semantics and require
users
> to just enable that.
Sure, but the problem is that then you can't interleave other
interceptors with the Seam interceptors.
Perhaps I should have prefaced it "a slightly better-than-terrible way" ;-)
9:16 p.m.
Ok - so this means we are back to square one. Can we discuss and agree on
the following guidelines?
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered,
and provide instructions to correct the configuration:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
All @Decorator classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.decorate.*Decorator
Let's discuss and resolve, since we're starting to release, and this is
important. (Affects Faces directly.)
Thanks,
Lincoln
On Mon, Apr 12, 2010 at 7:26 AM, Pete Muir <pmuir(a)redhat.com> wrote:
On 11 Apr 2010, at 05:11, Gavin King wrote:
> On Wed, Apr 7, 2010 at 7:23 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>> BTW A slightly better approach (which avoids at least the nastiness of
this approach, but
>> doesn't avoid the issue of ordering - which IMO is insurmountable) is
to write a
>> SeamInterceptor which can cope with using relative ordering semantics
and require users
>> to just enable that.
>
> Sure, but the problem is that then you can't interleave other
> interceptors with the Seam interceptors.
Perhaps I should have prefaced it "a slightly better-than-terrible way" ;-)
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
9:17 p.m.
I should add that I'm fine with using whatever packaging schema the
Interceptor would reside in without such a convention, but this protects us
from refactoring, so I think it's a good idea.
--Lincoln
On Fri, Apr 16, 2010 at 3:16 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
Ok - so this means we are back to square one. Can we discuss and
agree on
the following guidelines?
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered,
and provide instructions to correct the configuration:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
All @Decorator classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.decorate.*Decorator
Let's discuss and resolve, since we're starting to release, and this is
important. (Affects Faces directly.)
Thanks,
Lincoln
On Mon, Apr 12, 2010 at 7:26 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
> On 11 Apr 2010, at 05:11, Gavin King wrote:
>
> > On Wed, Apr 7, 2010 at 7:23 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> >
> >> BTW A slightly better approach (which avoids at least the nastiness of
> this approach, but
> >> doesn't avoid the issue of ordering - which IMO is insurmountable) is
> to write a
> >> SeamInterceptor which can cope with using relative ordering semantics
> and require users
> >> to just enable that.
> >
> > Sure, but the problem is that then you can't interleave other
> > interceptors with the Seam interceptors.
>
> Perhaps I should have prefaced it "a slightly better-than-terrible way"
> ;-)
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
9:19 p.m.
Ugh, though using this package convention means that hiding classes via
package-private is less appealing.
On Fri, Apr 16, 2010 at 3:17 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
I should add that I'm fine with using whatever packaging schema
the
Interceptor would reside in without such a convention, but this protects us
from refactoring, so I think it's a good idea.
--Lincoln
On Fri, Apr 16, 2010 at 3:16 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> Ok - so this means we are back to square one. Can we discuss and agree on
> the following guidelines?
>
> All @Interceptor classes must:
>
> 1. Adhere to the following package and naming scheme:
> org.jboss.seam.intercept.*Interceptor
> 2. Warn users (or Error out when appropriate) if they are using
> interceptable @Annotations when the @Inteceptor itself is not registered,
> and provide instructions to correct the configuration:
>
> (@Interceptor registration can be checked in the Extension class
> AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
> interceptorBindings)
>
> All @Decorator classes must:
>
> 1. Adhere to the following package and naming scheme:
> org.jboss.seam.decorate.*Decorator
>
> Let's discuss and resolve, since we're starting to release, and this is
> important. (Affects Faces directly.)
>
> Thanks,
> Lincoln
>
>
> On Mon, Apr 12, 2010 at 7:26 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>>
>> On 11 Apr 2010, at 05:11, Gavin King wrote:
>>
>> > On Wed, Apr 7, 2010 at 7:23 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>> >
>> >> BTW A slightly better approach (which avoids at least the nastiness of
>> this approach, but
>> >> doesn't avoid the issue of ordering - which IMO is insurmountable)
is
>> to write a
>> >> SeamInterceptor which can cope with using relative ordering semantics
>> and require users
>> >> to just enable that.
>> >
>> > Sure, but the problem is that then you can't interleave other
>> > interceptors with the Seam interceptors.
>>
>> Perhaps I should have prefaced it "a slightly better-than-terrible
way"
>> ;-)
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
11:48 a.m.
On 16 Apr 2010, at 20:19, Lincoln Baxter, III wrote:
Ugh, though using this package convention means that hiding classes
via package-private is less appealing.
It also goes against all guidelines for designing modular software, and will make adopting
either Jigsaw or OSGi much harder.
Watch a presentation on either for why :-)
On Fri, Apr 16, 2010 at 3:17 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
wrote:
I should add that I'm fine with using whatever packaging schema the Interceptor would
reside in without such a convention, but this protects us from refactoring, so I think
it's a good idea.
I don't understand how this "protects us from refactoring" - can you explain
what you mean?
--Lincoln
On Fri, Apr 16, 2010 at 3:16 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
wrote:
Ok - so this means we are back to square one. Can we discuss and agree on the following
guidelines?
All @Interceptor classes must:
• Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
No, why would we want to do this? Classes defined in a module should reside in a package
owned by that package. It prevents any risk of namespace clashes
• Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered, and provide
instructions to correct the configuration:
(@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via
BeanManager.resolveInterceptors(type, interceptorBindings)
Yes. We need a util method for this.
All @Decorator classes must:
• Adhere to the following package and naming scheme: org.jboss.seam.decorate.*Decorator
As above.
Let's discuss and resolve, since we're starting to release,
and this is important. (Affects Faces directly.)
This is all in the guidelines already...
5:22 p.m.
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> All @Interceptor classes must:
> • Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
No, why would we want to do this? Classes defined in a module should reside
in a package owned by that package. It prevents any risk of namespace
clashes
Referring back to Lincoln's suggestion, I though we were using
org.jboss.seam.{module}.intercept.*Interceptor? That would make them easier
to locate in the API docs yet still reside in a package owned by the module.
I just worry that if we scatter interceptors (and decorators) further down
in the packaging of a module, it will be harder to enforce consistency from
one module to the next. Is that a reasonable convention?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
5:43 p.m.
Referring to protection from refactoring:
- We have a class in:
org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptor
Three months later, we do some refactoring, and that interceptor moves
(because it doesn't really matter where it lives, as long as it is enabled
-- again, this problem would be solved by some sort of automatic enabling
and ordering.)
- The class is now in:
org.jboss.seam.faces.conversation.ConversationBoundaryInterceptor
We just broke all of our existing users -- now, this is of course easy to
prevent: don't move the class, but it is a concern that could lead to code
fragility and brittleness.
--Lincoln
On Mon, Apr 19, 2010 at 11:22 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> > All @Interceptor classes must:
> > • Adhere to the following package and naming scheme:
> org.jboss.seam.intercept.*Interceptor
>
> No, why would we want to do this? Classes defined in a module should
> reside in a package owned by that package. It prevents any risk of namespace
> clashes
>
> Referring back to Lincoln's suggestion, I though we were using
org.jboss.seam.{module}.intercept.*Interceptor? That would make them easier
to locate in the API docs yet still reside in a package owned by the module.
I just worry that if we scatter interceptors (and decorators) further down
in the packaging of a module, it will be harder to enforce consistency from
one module to the next. Is that a reasonable convention?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
5:50 p.m.
Ok. I *think* I might get what you are talking about now - you are concerned because the
interceptor has to go into the impl/ jar, not the API jar? And that therefore developers
are going to forget that it is actually part of the public API? Or?
Because otherwise, I don't have a clue how putting something in this special intercept
package can magically stop people refactoring... If I have
org.jboss.seam.intercept.ConversationBoundaryInterceptor
and someone renames it to
org.jboss.seam.intercept.ConversationEdgeInterceptor
it's just as broken for users...
On 19 Apr 2010, at 16:43, Lincoln Baxter, III wrote:
Referring to protection from refactoring:
• We have a class in:
org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptor
Three months later, we do some refactoring, and that interceptor moves (because it
doesn't really matter where it lives, as long as it is enabled -- again, this problem
would be solved by some sort of automatic enabling and ordering.)
• The class is now in:
org.jboss.seam.faces.conversation.ConversationBoundaryInterceptor
We just broke all of our existing users -- now, this is of course easy to prevent:
don't move the class, but it is a concern that could lead to code fragility and
brittleness.
--Lincoln
On Mon, Apr 19, 2010 at 11:22 AM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> All @Interceptor classes must:
> • Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
No, why would we want to do this? Classes defined in a module should reside in a package
owned by that package. It prevents any risk of namespace clashes
Referring back to Lincoln's suggestion, I though we were using
org.jboss.seam.{module}.intercept.*Interceptor? That would make them easier to locate in
the API docs yet still reside in a package owned by the module. I just worry that if we
scatter interceptors (and decorators) further down in the packaging of a module, it will
be harder to enforce consistency from one module to the next. Is that a reasonable
convention?
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
6:03 p.m.
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Ok. I *think* I might get what you are talking about now - you are
concerned because the interceptor has to go into the impl/ jar, not the API
jar? And that therefore developers are going to forget that it is actually
part of the public API? Or?
Because otherwise, I don't have a clue how putting something in this
special intercept package can magically stop people refactoring... If I have
org.jboss.seam.intercept.ConversationBoundaryInterceptor
and someone renames it to
org.jboss.seam.intercept.ConversationEdgeInterceptor
it's just as broken for users...
That's a great point and now I see this so clearly. Interceptors must be
considered part of the public API and a stable API is expected not to shift
(for backwards compatibility reasons). It's public API because the develop
must refer to the interceptors in beans.xml (according to spec, putting
workarounds aside).
If there is a refactoring, it must preserve backwards compatibility through
delegation (Seam 2 did this to prevent similar breakage in configuration
files).
So I guess the real issue at hand is...the consistent packaging of
interceptors is really about making the <interceptors> element as simple as
possible by making all the interceptors classes have the same number of
package segments. That need may or may not be contrived. I haven't stood in
the shoes of the developer yet being required to list out a bunch of
interceptor classes.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
7:45 p.m.
Same -- that is the question. Is it going to be annoying to register these
things? We don't know yet. So I suppose, let's stop worrying about it.
Pete does raise a good point, though. These classes are in the IMPL, not the
API, and will not be visible in the JavaDocs where they should be.
How do we address that?
--Lincoln
On Mon, Apr 19, 2010 at 12:03 PM, Dan Allen <dan.j.allen(a)gmail.com> wrote:
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> Ok. I *think* I might get what you are talking about now - you are
> concerned because the interceptor has to go into the impl/ jar, not the API
> jar? And that therefore developers are going to forget that it is actually
> part of the public API? Or?
>
> Because otherwise, I don't have a clue how putting something in this
> special intercept package can magically stop people refactoring... If I have
>
> org.jboss.seam.intercept.ConversationBoundaryInterceptor
>
> and someone renames it to
>
> org.jboss.seam.intercept.ConversationEdgeInterceptor
>
> it's just as broken for users...
>
> That's a great point and now I see this so clearly. Interceptors must be
considered part of the public API and a stable API is expected not to shift
(for backwards compatibility reasons). It's public API because the develop
must refer to the interceptors in beans.xml (according to spec, putting
workarounds aside).
If there is a refactoring, it must preserve backwards compatibility through
delegation (Seam 2 did this to prevent similar breakage in configuration
files).
So I guess the real issue at hand is...the consistent packaging of
interceptors is really about making the <interceptors> element as simple as
possible by making all the interceptors classes have the same number of
package segments. That need may or may not be contrived. I haven't stood in
the shoes of the developer yet being required to list out a bunch of
interceptor classes.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
8:06 p.m.
On 19 Apr 2010, at 18:45, Lincoln Baxter, III wrote:
Same -- that is the question. Is it going to be annoying to register
these things? We don't know yet. So I suppose, let's stop worrying about it.
Pete does raise a good point, though. These classes are in the IMPL, not the API, and
will not be visible in the JavaDocs where they should be.
Yes, I think this is a real concern ;-)
https://jira.jboss.org/jira/browse/SEAM-3
How do we address that?
Magic :-)
Actually, it should be possible with Maven.
7:52 p.m.
On 19 Apr 2010, at 17:03, Dan Allen wrote:
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
Ok. I *think* I might get what you are talking about now - you are concerned because the
interceptor has to go into the impl/ jar, not the API jar? And that therefore developers
are going to forget that it is actually part of the public API? Or?
Because otherwise, I don't have a clue how putting something in this special
intercept package can magically stop people refactoring... If I have
org.jboss.seam.intercept.ConversationBoundaryInterceptor
and someone renames it to
org.jboss.seam.intercept.ConversationEdgeInterceptor
it's just as broken for users...
That's a great point and now I see this so clearly. Interceptors must be considered
part of the public API and a stable API is expected not to shift (for backwards
compatibility reasons). It's public API because the develop must refer to the
interceptors in beans.xml (according to spec, putting workarounds aside).
Yup, it's definitely part of the API! IMO it's better to ensure this properly via
tests (e.g. we could add a tool like sigtest to our QA process, and verify all signature
changes as part of a release).
What I didn't get about the original discussion was that somehow putting interceptors
into a specific package somehow protects them from being changed - these are really
orthogonal concerns - not breaking an API and what package stuff goes in.
If there is a refactoring, it must preserve backwards compatibility through delegation
(Seam 2 did this to prevent similar breakage in configuration files).
So I guess the real issue at hand is...the consistent packaging of interceptors is really
about making the <interceptors> element as simple as possible by making all the
interceptors classes have the same number of package segments. That need may or may not be
contrived. I haven't stood in the shoes of the developer yet being required to list
out a bunch of interceptor classes.
It sounds contrived to me. Where does it come from? Given that a user might declare some
interceptors, where does that leave them?
7:53 p.m.
> So I guess the real issue at hand is...the consistent packaging
of
interceptors is really about making the <interceptors> element as simple as
possible by making all the interceptors classes have the same number of
package segments. That need may or may not be contrived. I haven't stood in
the shoes of the developer yet being required to list out a bunch of
interceptor classes.
It sounds contrived to me. Where does it come from? Given that a user might
declare some interceptors, where does that leave them?
They can call interceptors whatever they want ;)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
8:03 p.m.
On 19 Apr 2010, at 18:53, Lincoln Baxter, III wrote:
> So I guess the real issue at hand is...the consistent packaging of interceptors is
really about making the <interceptors> element as simple as possible by making all
the interceptors classes have the same number of package segments. That need may or may
not be contrived. I haven't stood in the shoes of the developer yet being required to
list out a bunch of interceptor classes.
It sounds contrived to me. Where does it come from? Given that a user might declare some
interceptors, where does that leave them?
They can call interceptors whatever they want ;)
??
Dan's point was that they would want to have the same number of package segments in
all the interceptor definitions. I don't think that they will ever achieve this, as
they might pull in a third-party interceptor, or define their own, which isn't in a
place with the same number of package segments.
Arguably, it's not the number of package segments that matters, it's the entire
prefix (for readability).
11:05 p.m.
Dan's point was that they would want to have the same number of package
segments in all the interceptor definitions. I don't think that they will
ever achieve this, as they might pull in a third-party interceptor, or
define their own, which isn't in a place with the same number of package
segments.
Well, naturally, we can't control everything. I was just thinking for our
own sanity, within Seam, we could ensure some sort of consistency.
Arguably, it's not the number of package segments that matters, it's the
entire prefix (for readability).
Right, my interest is being able to quickly scan our list of interceptors
and be able to recognize when there is a typo...or to be able to recall
interceptors from memory (based on pattern). Typical things to consider when
you are defining an API I would reason.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
2:54 a.m.
New subject: producing non-serializable beans from producers with passivating scope
Hi all, I ran into an issue with producing Drools
StatefulKnowledgeSession beans from my producers. Basically I need to
make sure that each produced session is in Conversation scope which is
passivating..but StatefulKnowledgeSession is not serializable which ends
up with exception:
org.jboss.weld.exceptions.IllegalProductException: WELD-000053 Producers
cannot declare passivating scope and return a non-serializable class
One idea was to declare the manager bean which includes the producer
method(s) in Conversation scope and make the producers request scoped
with a check for example:
if(ksession != null) { return ksession;} else { //create a new one and
save }
but my problem is that since I am specializing producer methods in the
module beans.xml (and so can the user in their beans.xml) I do not know
all possible specialized producer methods at runtime.
Any input on this is much appreciated as currently the following
injections for example:
@Inject @MySession StatefulKnowledgeSession ksession1;
and
@Inject @MySession StatefulKnowledgeSession ksession2;
end up being two different beans because dependent scope producer method
gets called twice.
Thanks.
12:08 p.m.
New subject: producing non-serializable beans from producers with passivating scope
On 20 Apr 2010, at 01:54, Tihomir Surdilovic wrote:
Hi all, I ran into an issue with producing Drools
StatefulKnowledgeSession beans from my producers. Basically I need to
make sure that each produced session is in Conversation scope which is
passivating..but StatefulKnowledgeSession is not serializable which ends
up with exception:
org.jboss.weld.exceptions.IllegalProductException: WELD-000053 Producers
cannot declare passivating scope and return a non-serializable class
One idea was to declare the manager bean which includes the producer
method(s) in Conversation scope and make the producers request scoped
with a check for example:
You mean put the manager bean in the conversation scoped?
if(ksession != null) { return ksession;} else { //create a new one and
save }
It would be cleaner to do this in the postconstruct. Remember all beans are lazy anyway.
but my problem is that since I am specializing producer methods in
the
module beans.xml (and so can the user in their beans.xml) I do not know
all possible specialized producer methods at runtime.
Can you explain more?
Any input on this is much appreciated as currently the following
injections for example:
@Inject @MySession StatefulKnowledgeSession ksession1;
and
@Inject @MySession StatefulKnowledgeSession ksession2;
end up being two different beans because dependent scope producer method
gets called twice.
If the manager is conversation scoped, it should be the same one?
12:01 a.m.
On 20/04/10 02:03, Dan Allen wrote:
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com
<mailto:pmuir@redhat.com>> wrote:
Ok. I *think* I might get what you are talking about now - you are
concerned because the interceptor has to go into the impl/ jar,
not the API jar? And that therefore developers are going to forget
that it is actually part of the public API? Or?
Because otherwise, I don't have a clue how putting something in
this special intercept package can magically stop people
refactoring... If I have
org.jboss.seam.intercept.ConversationBoundaryInterceptor
and someone renames it to
org.jboss.seam.intercept.ConversationEdgeInterceptor
it's just as broken for users...
That's a great point and now I see this so clearly. Interceptors must
be considered part of the public API and a stable API is expected not
to shift (for backwards compatibility reasons). It's public API
because the develop must refer to the interceptors in beans.xml
(according to spec, putting workarounds aside).
I don't really see it as part of the API - the user never imports the
class, never refers to it in any code. The one place where this might
be relevant is the API Javadoc, which the user might possibly be using
as their reference. I don't think that Javadoc is the right place for a
user to be going though to understand how to use any particular library,
especially in our case with the high standards we have for reference
documentation.
If there is a refactoring, it must preserve backwards compatibility
through delegation (Seam 2 did this to prevent similar breakage in
configuration files).
So I guess the real issue at hand is...the consistent packaging of
interceptors is really about making the <interceptors> element as
simple as possible by making all the interceptors classes have the
same number of package segments. That need may or may not be
contrived. I haven't stood in the shoes of the developer yet being
required to list out a bunch of interceptor classes.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
4:02 a.m.
They still have to put it in their beans.xml file in order to enable it;
that means they need to know the fully qualified class name :(
On Mon, Apr 19, 2010 at 6:01 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
On 20/04/10 02:03, Dan Allen wrote:
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> Ok. I *think* I might get what you are talking about now - you are
> concerned because the interceptor has to go into the impl/ jar, not the API
> jar? And that therefore developers are going to forget that it is actually
> part of the public API? Or?
>
> Because otherwise, I don't have a clue how putting something in this
> special intercept package can magically stop people refactoring... If I have
>
> org.jboss.seam.intercept.ConversationBoundaryInterceptor
>
> and someone renames it to
>
> org.jboss.seam.intercept.ConversationEdgeInterceptor
>
> it's just as broken for users...
>
> That's a great point and now I see this so clearly. Interceptors must
be considered part of the public API and a stable API is expected not to
shift (for backwards compatibility reasons). It's public API because the
develop must refer to the interceptors in beans.xml (according to spec,
putting workarounds aside).
I don't really see it as part of the API - the user never imports the
class, never refers to it in any code. The one place where this might be
relevant is the API Javadoc, which the user might possibly be using as their
reference. I don't think that Javadoc is the right place for a user to be
going though to understand how to use any particular library, especially in
our case with the high standards we have for reference documentation.
If there is a refactoring, it must preserve backwards compatibility
through delegation (Seam 2 did this to prevent similar breakage in
configuration files).
So I guess the real issue at hand is...the consistent packaging of
interceptors is really about making the <interceptors> element as simple as
possible by making all the interceptors classes have the same number of
package segments. That need may or may not be contrived. I haven't stood in
the shoes of the developer yet being required to list out a bunch of
interceptor classes.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
12:05 p.m.
Agreed, the interceptor is definitely part of the public API - they have to reference the
class in their beans.xml.
Having it in the javadoc is no replacement for a decent ref guide, but can be useful for
some IMO.
On 20 Apr 2010, at 03:02, Lincoln Baxter, III wrote:
They still have to put it in their beans.xml file in order to enable
it; that means they need to know the fully qualified class name :(
On Mon, Apr 19, 2010 at 6:01 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
On 20/04/10 02:03, Dan Allen wrote:
> On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> Ok. I *think* I might get what you are talking about now - you are concerned because
the interceptor has to go into the impl/ jar, not the API jar? And that therefore
developers are going to forget that it is actually part of the public API? Or?
>
> Because otherwise, I don't have a clue how putting something in this special
intercept package can magically stop people refactoring... If I have
>
> org.jboss.seam.intercept.ConversationBoundaryInterceptor
>
> and someone renames it to
>
> org.jboss.seam.intercept.ConversationEdgeInterceptor
>
> it's just as broken for users...
>
> That's a great point and now I see this so clearly. Interceptors must be
considered part of the public API and a stable API is expected not to shift (for backwards
compatibility reasons). It's public API because the develop must refer to the
interceptors in beans.xml (according to spec, putting workarounds aside).
I don't really see it as part of the API - the user never imports the class, never
refers to it in any code. The one place where this might be relevant is the API Javadoc,
which the user might possibly be using as their reference. I don't think that Javadoc
is the right place for a user to be going though to understand how to use any particular
library, especially in our case with the high standards we have for reference
documentation.
>
> If there is a refactoring, it must preserve backwards compatibility through
delegation (Seam 2 did this to prevent similar breakage in configuration files).
>
> So I guess the real issue at hand is...the consistent packaging of interceptors is
really about making the <interceptors> element as simple as possible by making all
the interceptors classes have the same number of package segments. That need may or may
not be contrived. I haven't stood in the shoes of the developer yet being required to
list out a bunch of interceptor classes.
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
> _______________________________________________
> seam-dev mailing list
>
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
4:21 a.m.
On Tue, Apr 20, 2010 at 6:05 AM, Pete Muir <pmuir(a)redhat.com> wrote:
Agreed, the interceptor is definitely part of the public API - they
have to
reference the class in their beans.xml.
Yep, and beans.xml must be considered "their code" (as a counter to Shane's
point).
Having it in the javadoc is no replacement for a decent ref guide, but can
be useful for some IMO.
Should we have Maven build merge JavaDoc for interceptors and decorators
into the JavaDoc for the api/ module? This should be possible based on name
filtering (i.e., *Interceptor, *Decorator). It will require some build
trickery, though.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
1:10 p.m.
On 23 Apr 2010, at 03:21, Dan Allen wrote:
On Tue, Apr 20, 2010 at 6:05 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
Agreed, the interceptor is definitely part of the public API - they have to reference the
class in their beans.xml.
Yep, and beans.xml must be considered "their code" (as a counter to Shane's
point).
Having it in the javadoc is no replacement for a decent ref guide, but can be useful for
some IMO.
Should we have Maven build merge JavaDoc for interceptors and decorators into the JavaDoc
for the api/ module? This should be possible based on name filtering (i.e., *Interceptor,
*Decorator).
Or presence of @Interceptor, @Decorator.
It will require some build trickery, though.
Yes. But if we do it once in the parent, should be ok.
5:45 p.m.
On 19 Apr 2010, at 16:22, Dan Allen wrote:
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)redhat.com>
wrote:
> All @Interceptor classes must:
> • Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
No, why would we want to do this? Classes defined in a module should reside in a package
owned by that package. It prevents any risk of namespace clashes
Referring back to Lincoln's suggestion, I though we were using
org.jboss.seam.{module}.intercept.*Interceptor? That would make them easier to locate in
the API docs yet still reside in a package owned by the module. I just worry that if we
scatter interceptors (and decorators) further down in the packaging of a module, it will
be harder to enforce consistency from one module to the next. Is that a reasonable
convention?
Not really IMO.
Personally, I find the convention of putting an interceptor into a package called
.intercept. rather cumbersome for a user. Where has this requirement come from? I feel
like I am missing the beginning of some discussion where the benefits of this approach
were discussed (actually, AFAIK we've already agreed on the points I am making -
http://lists.jboss.org/pipermail/seam-dev/2010-April/002303.html)
It's much better to organize the API along functional lines. Collect all the elements
of the API that form a coherent whole into (sub) package.
For example, to take the Security module, how is it better to structure the module like:
org.jboss.seam.security
.qualify.
.intercept.
.decorate.
.alternate.
than
org.jboss.seam.security.
.identity.
.jpa
.ldap
.authorization.
.authentication.
I find the latter much clearer. It allows me to browse a package using any tool, including
the command line, and see what options I have to solve my problem (rather than understand
up front what sort of thing I might want to use to solve my problem). This is especially
true if you are already calling your interceptor BlahInterceptor.
9:33 p.m.
+1 for Lincolns arguments
*) I DO use this in production already.
*) I have 3 frameworks with CDI interceptors now
*) they all DON't interfere currently. There are such cases, but they are way less
than 5% in my experience (from 4 years of working with spring interceptors).
*) it's nowhere mentioned in the spec that there must only be one beans.xml with a
<interceptor> section.
IF you really need a hard dependency, would providing a portable extension (in it's
own jar aka bean archive) which modifies the ProcessModule#getInterceptors() and fills it
with a extension specific configured ordered list of interceptors help?
LieGrue,
strub
--- Gavin King <gavin.king(a)gmail.com> schrieb am Mo, 29.3.2010:
Von: Gavin King <gavin.king(a)gmail.com>
Betreff: Re: [seam-dev] Interceptor packaging convention
An: "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
CC: "Seam Dev List" <seam-dev(a)lists.jboss.org>
Datum: Montag, 29. März, 2010 20:56 Uhr
On Mon, Mar 29, 2010 at 2:47 PM,
Lincoln Baxter, III
<lincolnbaxter(a)gmail.com>
wrote:
> I understand the technical reasons why interceptor
ordering is important,
> but I disagree completely with the lack of options, or
ability to ignore
> said technical reasons. The reason the enabler jar
works well is because it
> provides a consistent way to order interceptors
*within* the Seam framework.
>
> 95% of the time that is going to be enough. 5% of the
time it's not.
I just don't buy this. It's going to work fine when you
ONLY have the
Seam interceptors, and don't have any other interceptors.
As soon as
you start adding your own interceptors, or the interceptors
of another
framework, it's HIGHLY likely that you're going to need to
specify
their precedence w.r.t. the Seam interceptors.
> Why should we force people to work extra hard to get
things working, when
> they should only have to work extra hard if there is a
problem? Think of it
> from the POV of a user: Do they want to fix things to
get started? Or do
> they want to fix things only if they are broken?
Thanks for the lecture on the need to make things easy for
users.
Clearly it's an issue that had not occurred to me before.
Wow, I had
never considered thinking of things from the POV of a
user!
> This isn't a matter of technical correctness, we can
ensure technical
> correctness by allowing users to exclude the
Seam-enabler.jar from their POM
> and fall back to Beans.xml for manual interceptor
registration.
And how is this solution easier than just giving people a
standard,
pre-written beans.xml file that they include in their Seam
projects as
a starting point? It can even be added automatically by
JBoss Tools or
the Maven archectype. Then, when they come to add their
own
interceptors, it's easy to just edit this file.
Including a jar in the classpath is actually much more work
than
including a pre-written beans.xml file!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
9:35 p.m.
From the POV of a professional Seam 2.x user (and potential Weld/Seam
3
user) I'd like to state that one of the things I like about Seam is the
mostly static and minimal (e.g. components.xml, pages.xml, web.xml and
faces-config.xml) XML files I need to touch. Focusing on ease-of-use is
critical to adoption.
Regarding this particular argument, I'm going to side with GKing.
Realistically, as a user of this frmwk, how many times per day/week, on
average, would I have to update the beans.xml file for a large-sized project
(i.e. multi-module Mavenized Seam project)? I don't touch the above
mentioned Seam 2.x xml files every day or sometimes even every week/month
(thanks to annotations).
And it is possible that we will write and use custom interceptors from
time-to-time. So in this more complicated scenario (multiple portable
extensions, etc.) how shall we avoid the "clusterfuck" that GKing envisions
if we don't do it his (the spec's) way??
How much of an inconvenience is it to the dev on a daily basis??
On Mon, Mar 29, 2010 at 11:56 AM, Gavin King <gavin.king(a)gmail.com> wrote:
On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
> I understand the technical reasons why interceptor ordering is important,
> but I disagree completely with the lack of options, or ability to ignore
> said technical reasons. The reason the enabler jar works well is because
it
> provides a consistent way to order interceptors *within* the Seam
framework.
>
> 95% of the time that is going to be enough. 5% of the time it's not.
I just don't buy this. It's going to work fine when you ONLY have the
Seam interceptors, and don't have any other interceptors. As soon as
you start adding your own interceptors, or the interceptors of another
framework, it's HIGHLY likely that you're going to need to specify
their precedence w.r.t. the Seam interceptors.
> Why should we force people to work extra hard to get things working, when
> they should only have to work extra hard if there is a problem? Think of
it
> from the POV of a user: Do they want to fix things to get started? Or do
> they want to fix things only if they are broken?
Thanks for the lecture on the need to make things easy for users.
Clearly it's an issue that had not occurred to me before. Wow, I had
never considered thinking of things from the POV of a user!
> This isn't a matter of technical correctness, we can ensure technical
> correctness by allowing users to exclude the Seam-enabler.jar from their
POM
> and fall back to Beans.xml for manual interceptor registration.
And how is this solution easier than just giving people a standard,
pre-written beans.xml file that they include in their Seam projects as
a starting point? It can even be added automatically by JBoss Tools or
the Maven archectype. Then, when they come to add their own
interceptors, it's easy to just edit this file.
Including a jar in the classpath is actually much more work than
including a pre-written beans.xml file!
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
9:40 p.m.
And yes, ease-of-use is very important. That's one of the main reasons
Windows and .NET platforms and RoR are widely popular and successful. I
don't think Seam and the rest of the JBoss dev stack (JSF, RichFaces, EJB,
JPA/Hibernate, etc) is easy-to-use or learn quickly unfortunately.
Power and flexibility vs. ease-of-use and productivity. Fine line?
After 10 years in Java EE dev, I still think our productivity is nowhere
near where it can/should be. Hopefully Java EE 6 platform will prove me
wrong...
On Mon, Mar 29, 2010 at 12:35 PM, Arbi Sookazian <asookazian(a)gmail.com>wrote:
From the POV of a professional Seam 2.x user (and potential Weld/Seam
3
user) I'd like to state that one of the things I like about Seam is the
mostly static and minimal (e.g. components.xml, pages.xml, web.xml and
faces-config.xml) XML files I need to touch. Focusing on ease-of-use is
critical to adoption.
Regarding this particular argument, I'm going to side with GKing.
Realistically, as a user of this frmwk, how many times per day/week, on
average, would I have to update the beans.xml file for a large-sized project
(i.e. multi-module Mavenized Seam project)? I don't touch the above
mentioned Seam 2.x xml files every day or sometimes even every week/month
(thanks to annotations).
And it is possible that we will write and use custom interceptors from
time-to-time. So in this more complicated scenario (multiple portable
extensions, etc.) how shall we avoid the "clusterfuck" that GKing envisions
if we don't do it his (the spec's) way??
How much of an inconvenience is it to the dev on a daily basis??
On Mon, Mar 29, 2010 at 11:56 AM, Gavin King <gavin.king(a)gmail.com> wrote:
> On Mon, Mar 29, 2010 at 2:47 PM, Lincoln Baxter, III
> <lincolnbaxter(a)gmail.com> wrote:
> > I understand the technical reasons why interceptor ordering is
> important,
> > but I disagree completely with the lack of options, or ability to ignore
> > said technical reasons. The reason the enabler jar works well is because
> it
> > provides a consistent way to order interceptors *within* the Seam
> framework.
> >
> > 95% of the time that is going to be enough. 5% of the time it's not.
>
> I just don't buy this. It's going to work fine when you ONLY have the
> Seam interceptors, and don't have any other interceptors. As soon as
> you start adding your own interceptors, or the interceptors of another
> framework, it's HIGHLY likely that you're going to need to specify
> their precedence w.r.t. the Seam interceptors.
>
> > Why should we force people to work extra hard to get things working,
> when
> > they should only have to work extra hard if there is a problem? Think of
> it
> > from the POV of a user: Do they want to fix things to get started? Or do
> > they want to fix things only if they are broken?
>
> Thanks for the lecture on the need to make things easy for users.
> Clearly it's an issue that had not occurred to me before. Wow, I had
> never considered thinking of things from the POV of a user!
>
> > This isn't a matter of technical correctness, we can ensure technical
> > correctness by allowing users to exclude the Seam-enabler.jar from their
> POM
> > and fall back to Beans.xml for manual interceptor registration.
>
> And how is this solution easier than just giving people a standard,
> pre-written beans.xml file that they include in their Seam projects as
> a starting point? It can even be added automatically by JBoss Tools or
> the Maven archectype. Then, when they come to add their own
> interceptors, it's easy to just edit this file.
>
> Including a jar in the classpath is actually much more work than
> including a pre-written beans.xml file!
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
11:48 p.m.
On 30/03/10 04:56, Gavin King wrote:
And how is this solution easier than just giving people a standard,
pre-written beans.xml file that they include in their Seam projects as
a starting point? It can even be added automatically by JBoss Tools or
the Maven archectype. Then, when they come to add their own
interceptors, it's easy to just edit this file.
Including a jar in the classpath is actually much more work than
including a pre-written beans.xml file!
From a usability perspective I think this idea is the most sensible,
however if we generate a new project from Maven or JBoss Tools and are
including a beans.xml that contains all interceptors, then we must also
include all Seam module jars in the project (this is not really a
problem per se, it just adds extra bulkiness when the user doesn't
require certain features). Alternatively the user could select which
features/modules they require and the interceptors get added just for
those modules, and the remaining interceptors are added to beans.xml but
commented out so they can possibly add the other modules in later.
It may also be worth having a module check to see if its interceptors
are enabled on startup and log a warning message if not (can we do this
with the CDI SPI?) with instructions on how to enable that interceptor
in beans.xml.
2:15 p.m.
I hope our seam-gen-esque tool can ask a user:
"Do you want to use Seam security?"
and if so, add the relevant interceptor :-)
On 29 Mar 2010, at 22:48, Shane Bryzak wrote:
On 30/03/10 04:56, Gavin King wrote:
>
> And how is this solution easier than just giving people a standard,
> pre-written beans.xml file that they include in their Seam projects as
> a starting point? It can even be added automatically by JBoss Tools or
> the Maven archectype. Then, when they come to add their own
> interceptors, it's easy to just edit this file.
>
> Including a jar in the classpath is actually much more work than
> including a pre-written beans.xml file!
>
>
From a usability perspective I think this idea is the most sensible,
however if we generate a new project from Maven or JBoss Tools and are
including a beans.xml that contains all interceptors, then we must also
include all Seam module jars in the project (this is not really a
problem per se, it just adds extra bulkiness when the user doesn't
require certain features). Alternatively the user could select which
features/modules they require and the interceptors get added just for
those modules, and the remaining interceptors are added to beans.xml but
commented out so they can possibly add the other modules in later.
It may also be worth having a module check to see if its interceptors
are enabled on startup and log a warning message if not (can we do this
with the CDI SPI?) with instructions on how to enable that interceptor
in beans.xml.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
1:49 a.m.
+1 for that.
Even if you have 10 interceptors (or more) in a project, only few of them will get used on
the same class at a time. And even in this rare cases, in 95% the ordering will make
absolutely no difference at all.
Also I cannot read this restriction from the spec, please point me to the location.
IF there is any ordering needed, those interceptors have to be defined in the same
beans.xml.
So an algorithm like the following is imo enough:
if (beans.xml contains <interceptors>) {
if (interceptors.size() > 1) {
removeInterceptorsIfAlreadyDefined(interceptors);
addInterceptors(interceptors); //make sure they are now in the right order
} else {
addInterceptorIfNotYetDefined(interceptor);
}
}
or something like that.
This would remove most of the problems. The only problematic situation remains if 2
beans.xmls defines a different ordering for the same interceptors.
LieGrue,
strub
--- Shane Bryzak <sbryzak(a)redhat.com> schrieb am Fr, 26.3.2010:
Von: Shane Bryzak <sbryzak(a)redhat.com>
Betreff: Re: [seam-dev] Interceptor packaging convention
An: "Lincoln Baxter, III" <lincolnbaxter(a)gmail.com>
CC: "Seam Dev List" <seam-dev(a)lists.jboss.org>
Datum: Freitag, 26. März, 2010 01:27 Uhr
This will be a major inconvenience for our users if we expect them to
manually add all the interceptors they need for conversations,
security, transactions, and who knows what else. Is there absolutely
no other way that we can automatically register these in the
extension? Also I'm not a big fan of having to use the
org.jboss.seam.intercept namespace, I don't want to have to include a
lone class in this package if all my other classes are in (for example
the security module) org.jboss.seam.security.
On 26/03/10 10:14, Lincoln Baxter, III wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support
for Seam Faces, and we've discovered that there is a new fact of life
for consumers of portable CDI extensions. Due to the fact that
@Interceptors cannot be enabled in the extensions themselves (due to
restrictions on beans.xml for purposes of absolute ordering in the
application. See: http://seamframework.org/Community/EnablingAnInterceptorInALibrary
)
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
Exposed to the developer
Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
Consistently named and packaged to prevent refactoring /
backwards compatibility issues
Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor
We would like to propose the following conventions in order to address
the above concerns:
All @Interceptor classes must:
Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not
registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
A consistent naming scheme to help prevent typos.
A safety net to catch them when they fall down (because we
forgot to tie the ladder.)
A protected namespace so that when we refactor, we don't break
their world. (Even though #2 would catch it.)
I've updated the Seam 3 Development Guidelines to reflect these
conventions - they can be changed as needed pending the outcome of this
discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
-----Integrierter Anhang folgt-----
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
6:25 p.m.
It's an even worse major inconvenience to not be able to turn interceptors off.
On Thu, Mar 25, 2010 at 8:27 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
This will be a major inconvenience for our users if we expect them
to
manually add all the interceptors they need for conversations, security,
transactions, and who knows what else. Is there absolutely no other way
that we can automatically register these in the extension? Also I'm not a
big fan of having to use the org.jboss.seam.intercept namespace, I don't
want to have to include a lone class in this package if all my other classes
are in (for example the security module) org.jboss.seam.security.
On 26/03/10 10:14, Lincoln Baxter, III wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for
Seam Faces, and we've discovered that there is a new fact of life for
consumers of portable CDI extensions. Due to the fact that @Interceptors
cannot be enabled in the extensions themselves (due to restrictions on
beans.xml for purposes of absolute ordering in the application. See:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
Exposed to the developer
Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
Consistently named and packaged to prevent refactoring / backwards
compatibility issues
Checked at startup in order to warn devs that they are using annotations
with no enabled @Interceptor
We would like to propose the following conventions in order to address the
above concerns:
All @Interceptor classes must:
Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
Warn users (or Error out when appropriate) if they are using interceptable
@Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
A consistent naming scheme to help prevent typos.
A safety net to catch them when they fall down (because we forgot to tie the
ladder.)
A protected namespace so that when we refactor, we don't break their world.
(Even though #2 would catch it.)
I've updated the Seam 3 Development Guidelines to reflect these conventions
- they can be changed as needed pending the outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
6:24 p.m.
This sounds wrong to me.
It is part of the design of CDI that you are *supposed* to be able to
have an annotation with no enabled interceptor.
That let's you, for example, disable your transaction and security
interceptors in the test environment.
So I don't think that you guys should be doing any additional checking
at startup beyond what Weld does as required by the spec.
On Thu, Mar 25, 2010 at 8:14 PM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for
Seam Faces, and we've discovered that there is a new fact of life for
consumers of portable CDI extensions. Due to the fact that @Interceptors
cannot be enabled in the extensions themselves (due to restrictions on
beans.xml for purposes of absolute ordering in the application. See:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
Exposed to the developer
Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
Consistently named and packaged to prevent refactoring / backwards
compatibility issues
Checked at startup in order to warn devs that they are using annotations
with no enabled @Interceptor
We would like to propose the following conventions in order to address the
above concerns:
All @Interceptor classes must:
Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
Warn users (or Error out when appropriate) if they are using interceptable
@Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
A consistent naming scheme to help prevent typos.
A safety net to catch them when they fall down (because we forgot to tie the
ladder.)
A protected namespace so that when we refactor, we don't break their world.
(Even though #2 would catch it.)
I've updated the Seam 3 Development Guidelines to reflect these conventions
- they can be changed as needed pending the outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5369
days inactive
5397
days old
60 comments
11 participants
participants (11)
-
Ales Justin -
Arbi Sookazian -
Dan Allen -
Gavin King -
Lincoln Baxter, III -
Mark Struberg -
Nicklas Karlsson -
Pete Muir -
Shane Bryzak -
Stuart Douglas -
Tihomir Surdilovic