deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: seam-servlet stuff to deltaspike
Date Tue, 16 Oct 2012 16:15:15 GMT
Jozef and I had a meeting on hangout and I think we agreed that we will move the @ApplicationScoped
discussion over to the EG.

I personally still do see no showstopper. If a container delivers a broken @ApplicationScoped
then this is no problem of DeltaSpike.

LieGrue,
strub




----- Original Message -----
> From: Jozef Hartinger <jharting@redhat.com>
> To: Mark Struberg <struberg@yahoo.de>
> Cc: "deltaspike-dev@incubator.apache.org" <deltaspike-dev@incubator.apache.org>;
Pete Muir <pmuir@redhat.com>
> Sent: Tuesday, October 16, 2012 2:34 PM
> Subject: Re: seam-servlet stuff to deltaspike
> 
> Comments inline
> 
> On 10/16/2012 01:16 PM, Mark Struberg wrote:
>>  Hi Jozef!
>> 
>> 
>> 
>>>  I think that *all* the other scopes would suffer from that
>>  sorry, imo plain wrong. This works perfectly fine and we have exactly that 
> running in our installation.
>> 
>>  read  6.2. The Context interface "At a particular point in the 
> execution of the program a context object may be active with respect to the 
> current thread. When a context object is active the isActive() method returns 
> true. Otherwise, we say that the context object is inactive and the isActive() 
> method returns false."
>> 
>>  plus
>> 
>> 
>>  6.5.1. The active context object for a scope
>> 
>>  "From time to time, the container must obtain an active context object 
> for a certain scope type. The container must search
>>  for an active instance of Context associated with the scope type."
>> 
>>  The Container will ONLY give you the @ApplicationScoped Beans and 
> Contextual Instances from your current WebApplication. For non-webapp requests 
> (this is the paragraph which some container builders misinterpreted as reason 
> for 1 per EAR) you will get an own ApplicationContext.
>> 
>>  There is a perfect way in JavaEE to share the results even in CDI-1.0 -> 
> EJBs in a shared ejb-jar.xml!
>> 
>> 
>> 
>>>  but let's take @Dependent as an example since that's probably 
> the easiest.
>>  Not a problem at all!
>> 
>>  read 10.4.3. Conditional observer methods:
>>  "Beans with scope @Dependent may not have conditional observer 
> methods. If a bean with scope @Dependent has an observer method declared 
> receive=IF_EXISTS, the container automatically detects the problem and treats it 
> as a definition error."
>> 
>>  What remains is that @Dependent beans which define an @Observes will ALWAYS 
> create a new Contextual Instance for each event getting fired! This doesn't 
> matter how the @ApplicationScoped is being interpreted.
>> 
>> 
>>  BUT if we clarify the behaviour, then only @Dependent beans picked up by 
> the BeanManager of the very WebApp will get created. What I currently observed 
> is that in EAR scenarios some containers currently (due to the fact that they 
> only have 1 BM for the whole EAR) als create @Dependent beans of FOREIGN 
> webapps. And then they obviously pretty often blow up with a 
> ClassNotFoundException or a class cast issue.
> Which brings us to my initial point which said: "Even if the spec was 
> interpreted that way it would only help us with 2a) which we can deal 
> with anyway. It would be no help for 2b) ". That is because, as you 
> write above, other changes to the spec would be necessary. A different 
> interpretation of @ApplicationScoped alone would not be sufficient.
> 
> If we would need to wait for another (clarified) version of CDI to 
> allows us to implement this then these features would end up redundant 
> since CDI 1.1 will support propagation of Servlet events in the first place.
> 
>> 
>>>  This is offtopic. There is no point in trying to convince the 
> deltaspike
>>>  user list that your interpretation is correct because that does not 
> help
>>>  us solve the DS issue. Leave those arguments for the CDI expert group
>>>  where this can be argued about.
>>  No, it is imo not offtopic. We need this to get all our Extensions right. 
> And if we do not know if our Extension or @ApplicationScoped beans are shared 
> over multiple WebApps then we cannot build our Extensions properly. So this is 
> essential for all DeltaSpike imo
>> 
>>  I'm tempted to call some VOTE on a public list to get a picture about 
> what people would expect from @ApplicationScoped.
>> 
>>  The answers I got so far was kind of the following "Better make 
> WebApps run smoothly, because EARs are totally messed up anyway".
>> 
>>  Any end users like to chime in?
>> 
>>  I'm happy to be both a container architect AND a user of that stuff. 
> That allowed me to get precious feedback from our team very early on. I've 
> built and actively run a FAT EAR application and I'm still not able to
>>  run it on Glassfish or JBossAS because it bombs out heavily because of
>>  such issues.
>>  (I really like JBossAS7 otherwise, it's fast and for WARs it is 
> perfectly suited - but it sucks on EAR handling right now).
>> 
>> 
>> 
>>  LieGrue,
>>  strub
>> 
>> 
>>  ----- Original Message -----
>>>  From: Jozef Hartinger <jharting@redhat.com>
>>>  To: deltaspike-dev@incubator.apache.org
>>>  Cc: Mark Struberg <struberg@yahoo.de>; Pete Muir 
> <pmuir@redhat.com>
>>>  Sent: Tuesday, October 16, 2012 12:53 PM
>>>  Subject: Re: seam-servlet stuff to deltaspike
>>> 
>>>  Comments inline.
>>> 
>>>  On 10/16/2012 12:36 PM, Mark Struberg wrote:
>>>>     Jozef, WHICH other scopes?
>>>> 
>>>>     @SessionScoped -> NO
>>>>     @ApplicationScoped -> NO
>>>>     @RequestScoped -> NO
>>>>     @ConversationScoped -> NO
>>>  I think that *all* the other scopes would suffer from that but 
> let's
>>>  take @Dependent as an example since that's probably the easiest.
>>>>     The only way would be the new proposed 
> @EnterpriseApplicationScoped and
>>>  that would be perfectly fine as you would KNOW you would get it. Maybe 
> you like
>>>  to count the number of activated wars or whatever.
>>>>     Now let's look at other @ApplicationScoped definitions in 
> this world
>>>  This is offtopic. There is no point in trying to convince the 
> deltaspike
>>>  user list that your interpretation is correct because that does not 
> help
>>>  us solve the DS issue. Leave those arguments for the CDI expert group
>>>  where this can be argued about.
>>>>     * Servlet -> 1 per webapp
>>>>     * JSF -> 1 per webapp
>>>>     * Spring -> 1 per webapp
>>>>     * Guice -> 1 per webapp
>>>>     * Tapestry -> 1 per webapp
>>>> 
>>>>     You like to add one more?
>>>> 
>>>>     And now tell me which existing @ApplicationScoped means 1 per 
> EAR? NADA
>>>  there is none!
>>>>     And don't come with the EE spec. This stuff is inconsistent 
> in itself
>>>  sometimes meaning the Enterprise Application with 'application' 
> and
>>>  sometimes meaning the WebApplication with 'application'.
>>>> 
>>>>     "If language is not correct, then what is said is not what 
> is meant;
>>>> 
>>>>     if what is said is not what is meant,
>>>>     then what must be done remains undone; if this remains undone, 
> morals
>>>>     and art will deteriorate; if justice goes astray, the people 
> will stand
>>>>     about in helpless confusion. Hence there must be no 
> arbitrariness in
>>>>     what is said. This matters above everything.”
>>>> 
>>>>     Confucius, ~520 BC
>>>> 
>>>> 
>>>>     LieGrue,
>>>>     strub
>>>> 
>>>>     ----- Original Message -----
>>>>>     From: Jozef Hartinger <jharting@redhat.com>
>>>>>     To: Mark Struberg <struberg@yahoo.de>
>>>>>     Cc: deltaspike <deltaspike-dev@incubator.apache.org>; 
> Pete Muir
>>>  <pmuir@redhat.com>
>>>>>     Sent: Tuesday, October 16, 2012 12:23 PM
>>>>>     Subject: Re: seam-servlet stuff to deltaspike
>>>>> 
>>>>>     No, the other war could still have observer methods defined 
> on beans
>>>>>     with other scope than @ApplicationScoped that would still be 
> invoked.
>>>>>     Therefore, this is not much of a help.
>>>>> 
>>>>>     On 10/16/2012 12:07 PM, Mark Struberg wrote:
>>>>>>       2b is NOT a problem if we interpret @ApplicationScoped 
> as 1 per
>>>  WebApp.
>>>>>     Because those beans will 'not be active i respect to the 
> current
>>>  Thread'
>>>>>     (spec wording). So those beans would also NOT get those 
> events.
>>>>>>       This is simular to an event not being sent to a 
> @SessionScoped
>>>  bean of
>>>>>     another session...
>>>>>>       LieGrue,
>>>>>> 
>>>>>>       strub
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>       ----- Original Message -----
>>>>>>>       From: Jozef Hartinger <jharting@redhat.com>
>>>>>>>       To: Mark Struberg <struberg@yahoo.de>
>>>>>>>       Cc: deltaspike 
> <deltaspike-dev@incubator.apache.org>;
>>>  Pete Muir
>>>>>     <pmuir@redhat.com>
>>>>>>>       Sent: Tuesday, October 16, 2012 10:58 AM
>>>>>>>       Subject: Re: seam-servlet stuff to deltaspike
>>>>>>> 
>>>>>>>       Even if the spec was interpreted that way it would 
> only help
>>>  us with
>>>>>     2a)
>>>>>>>       which we can deal with anyway. It would be no help 
> for 2b)
>>>>>>> 
>>>>>>>       On 10/16/2012 10:48 AM, Mark Struberg wrote:
>>>>>>>>        Another argument for interpreting 
> @ApplicationScoped as
>>>>>     web-application
>>>>>>>       singleton like suggested in  CDI-129.
>>>>>>>>        I f****n care what some containers got wrong 
> by taking
>>>  it as 1
>>>>>     per EAR.
>>>>>>>>        I now talked with
>>>>>>>> 
>>>>>>>>        * serlvet EG members
>>>>>>>>        * Ed, JSF spec lead
>>>>>>>>        * Spring folks
>>>>>>>>        * tons of user
>>>>>>>>        * even you JBoss Seam guys
>>>>>>>> 
>>>>>>>>        ALL of them AND THE CDI SPEC (see 2.4.1 
> "The
>>>  @RequestScoped,
>>>>>>>       @ApplicationScoped and @SessionScoped annotations 
> defined in
>>>  Section
>>>>>     6.7,
>>>>>>>       “Context management for built-in scopes” represent

> the
>>>  standard scopes
>>>>>     defined
>>>>>>>       by the Java Servlets specification.") 
> interpret
>>>  @ApplicationScoped
>>>>>     as 1 per
>>>>>>>       webapp.
>>>>>>>>        damn, I really f***n care what some 
> containers did
>>>  wrong so far
>>>>>     (including
>>>>>>>       our own)! All what is important is to fix the 
> behaviour in
>>>  the future.
>>>>>     It's
>>>>>>>       also that ALL CDI Extensions expect an own 
> BeanManager per
>>>>>     WebApplication. That
>>>>>>>       would be perfectly broken now as well and cause 
> lots of
>>>>>     non-portability.
>>>>>>>>          LieGrue,
>>>>>>>>        strub
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>        ----- Original Message -----
>>>>>>>>>        From: Jozef Hartinger 
> <jharting@redhat.com>
>>>>>>>>>        To: Mark Struberg 
> <struberg@yahoo.de>
>>>>>>>>>        Cc: 
> "deltaspike-dev@incubator.apache.org"
>>>>>>>       <deltaspike-dev@incubator.apache.org>
>>>>>>>>>        Sent: Tuesday, October 16, 2012 8:19 AM
>>>>>>>>>        Subject: Re: seam-servlet stuff to 
> deltaspike
>>>>>>>>> 
>>>>>>>>>        #2 could be split into two issues:
>>>>>>>>> 
>>>>>>>>>        2a) Injection of Servlet artefacts
>>>>>>>>> 
>>>>>>>>>        Solder stores ServletContext in an
>>>  @ApplicationScoped holder
>>>>>     which
>>>>>>>>>        caused a clash between multiple 
> ServletContexts in
>>>  a multiwar
>>>>>     ear
>>>>>>>>>        deployment. This can be solved easily by 
> using
>>>  something
>>>>>     other than
>>>>>>>>>        @ApplicationScoped holder for holding the
>>>  reference.
>>>>>>>>>        2b) Lifecycle events
>>>>>>>>> 
>>>>>>>>>        Solder propagates servlet lifecyce events 
> e.g.
>>>  @Initialized
>>>>>>>>>        ServletContext. In a multi-war ear 
> deployment an
>>>  event with
>>>>>     payload
>>>>>>>       that
>>>>>>>>>        represents a servlet context of war1 is 
> fired to
>>>  all matching
>>>>>     observer
>>>>>>>>>        methods including those in different wars 
> which may
>>>  be
>>>>>     confusing.
>>>>>>>>>        We got this right in Weld but we were 
> able to do
>>>  that because
>>>>>     we have
>>>>>>>>>        much more information about a deployment 
> structure
>>>  compared
>>>>>     what a CDI
>>>>>>>>>        extension has. I am not sure if this can 
> be
>>>  implemented
>>>>>     properly as a
>>>>>>>>>        CDI extension.
>>>>>>>>> 
>>>>>>>>>        On 10/15/2012 05:22 PM, Mark Struberg 
> wrote:
>>>>>>>>>>          what was the problem actually?
>>>>>>>>>> 
>>>>>>>>>>          LieGrue,
>>>>>>>>>>          strub
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>          ----- Original Message -----
>>>>>>>>>>>          From: Jason Porter
>>>  <lightguard.jp@gmail.com>
>>>>>>>>>>>          To: Jozef Hartinger
>>>  <jharting@redhat.com>
>>>>>>>>>>>          Cc: 
> deltaspike-dev@incubator.apache.org
>>>>>>>>>>>          Sent: Monday, October 15, 2012 
> 5:19 PM
>>>>>>>>>>>          Subject: Re: seam-servlet stuff

> to
>>>  deltaspike
>>>>>>>>>>>          No problem at all with #1, #2 
> is a bit
>>>  difficult to
>>>>>     solve.
>>>>>>>       Jozef, have
>>>>>>>>>        you
>>>>>>>>>>>          solved this in Weld 2.0? If so,

> how do
>>>  you propose
>>>>>     we solve
>>>>>>>       it in DS?
>>>>>>>>>>>          On Mon, Oct 15, 2012 at 2:46 
> AM, Jozef
>>>  Hartinger
>>>>>>>>>>>         
> <jharting@redhat.com>wrote:
>>>>>>>>>>> 
>>>>>>>>>>>>            There are two issues I am

> aware of:
>>>>>>>>>>>> 
>>>>>>>>>>>>            1) The injectable Servlet

> artifacts
>>>  should
>>>>>     define a
>>>>>>>>>        deltaspike-specific
>>>>>>>>>>>>            qualifier in order to 
> prevent
>>>  conflict with
>>>>>     CDI 1.1
>>>>>>>       which defines
>>>>>>>>>        these
>>>>>>>>>>>>            artifacts in the @Default

> space.
>>>>>>>>>>>> 
>>>>>>>>>>>>            2) There was an issue in

> solder
>>>  related to
>>>>>     multi-war
>>>>>>>       ear
>>>>>>>>>        deployment which
>>>>>>>>>>>>            is hard to get right
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>            On 10/13/2012 07:39 PM, 
> Jason
>>>  Porter wrote:
>>>>>>>>>>>>>            Were there other 
> issues? That
>>>  one is easy
>>>>>     to fix. I
>>>>>>>       thought
>>>>>>>>>        there was
>>>>>>>>>>>>>            something with the 
> producers
>>>  at some
>>>>>     point.
>>>>>>>>>>>>>            Sent from my iPhone
>>>>>>>>>>>>> 
>>>>>>>>>>>>>            On Oct 13, 2012, at 
> 11:17, Cody
>>>  Lerum
>>>>>>>>>        <cody.lerum@gmail.com>
>>>>>>>>>>>          wrote:
>>>>>>>>>>>>>             This was one major

> outstanding
>>>  issue.
>>> 
> https://issues.jboss.org/**browse/SOLDER-312<https://issues.jboss.org/browse/SOLDER-312>
>>>>>>>>>>>>>>            On Sat, Oct 13, 
> 2012 at
>>>  4:22 AM,
>>>>>     Charles
>>>>>>>       Moulliard
>>>>>>>>>>>          <ch007m@gmail.com>
>>>>>>>>>>>>>>            wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>            +1
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>            On Sat, Oct 
> 13, 2012 at
>>>  10:56 AM,
>>>>>     Christian
>>>>>>>       Kaltepoth
>>>>>>>>>        <
>>>>>>>>>>>>>>>           
>>>  christian@kaltepoth.de> wrote:
>>>>>>>>>>>>>>>             +1 for 
> adding it to
>>>  0.4 as a
>>>>>     separate
>>>>>>>       servlet
>>>>>>>>>        module.
>>>>>>>>>>>>>>>>            I think 
> these are
>>>  very
>>>>>     important
>>>>>>>       features.
>>>>>>>>>        Especially the
>>>>>>>>>>>          event
>>>>>>>>>>>>>>>>           
> propagation and the
>>>  injection
>>>>>     of
>>>>>>>       servlet-related
>>>>>>>>>        objects.
>>>>>>>>>>>>>>>>            Christian
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>           
> 2012/10/12 Jason
>>>  Porter
>>>>>>>>>        <lightguard.jp@gmail.com>
>>>>>>>>>>>>>>>>>           
> Sounds like
>>>  we're
>>>>>     good to add
>>>>>>>       it. Shall
>>>>>>>>>        we add it
>>>>>>>>>>>          for v0.4?
>>>>>>>>>>>>>>>>>            On 
> Fri, Oct 12,
>>>  2012 at
>>>>>     11:04 AM,
>>>>>>>       Gerhard
>>>>>>>>>        Petracek <
>>>>>>>>>>>>>>>>>           
>>>>>     gerhard.petracek@gmail.com>
>>>>>>>       wrote:
>>>>>>>>>>>>>>>>>             +1

> for an own
>>>  module.
>>>>>>>>>>>>>>>>>>           
> regards,
>>>>>>>>>>>>>>>>>>           
> gerhard
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>           
> 2012/10/12
>>>  Mark
>>>>>     Struberg
>>>>>>>>>        <struberg@yahoo.de>
>>>>>>>>>>>>>>>>>>            

> +1 for
>>>>>     modules/servlet :)
>>>>>>>>>>>>>>>>>>>         
>   
>>>  LieGrue,
>>>>>>>>>>>>>>>>>>>         
>    strub
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>         
>    -----
>>>  Original
>>>>>     Message
>>>>>>>       -----
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  From: Jason
>>>>>     Porter
>>>>>>>>>>>          <lightguard.jp@gmail.com>
>>>>>>>>>>>>>>>>>>>>     
>        To:
>>> 
> deltaspike-dev@incubator.**apache.org<deltaspike-dev@incubator.apache.org>
>>>>>>>>>>>>>>>>>>>>     
>        Cc:
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Sent: Friday,
>>>>>     October
>>>>>>>       12, 2012
>>>>>>>>>        5:12 PM
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Subject: Re:
>>>>>>>       seam-servlet stuff
>>>>>>>>>        to
>>>>>>>>>>>          deltaspike
>>>>>>>>>>>>>>>>>>>>     
>        I
>>>  have no
>>>>>     problem
>>>>>>>       adding it. It
>>>>>>>>>        certainly
>>>>>>>>>>>          should be its own module
>>>>>>>>>>>>>>>>>>>         
>    though.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>     
>        We
>>>  may also
>>>>>     need to
>>>>>>>       rethink some
>>>>>>>>>        of how the
>>>>>>>>>>>          code was working. I
>>>>>>>>>>>>>>>>>>>         
>   
>>>  remember
>>>>>>>>>>>>>>>>>>>         
>    there
>>>  being
>>>>>     problems, but
>>>>>>>       maybe
>>>>>>>>>        it's simply
>>>>>>>>>>>          because we put it into
>>>>>>>>>>>>>>>>>>>         
>    solder.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>     
>        On
>>>  Fri, Oct
>>>>>     12, 2012 at
>>>>>>>       9:08 AM,
>>>>>>>>>        Romain
>>>>>>>>>>>          Manni-Bucau
>>>>>>>>>>>>>>>>>>>>     
>       
>>>>>>>>>        <rmannibucau@gmail.com>wrote:
>>>>>>>>>>>>>>>>>>>>     
>         +1
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  *Romain
>>>>>>>       Manni-Bucau*
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  *Twitter:
>>>>>>>       @rmannibucau
>>>>>>> 
>>> 
> <https://twitter.com/**rmannibucau<https://twitter.com/rmannibucau>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>>  *
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  *Blog:
>>> 
> **http://rmannibucau.**wordpress.com/*<http://rmannibucau.wordpress.com/*>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  <
>>> 
> http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>>>     *LinkedIn:
>>>>> 
>>> 
> **http://fr.linkedin.com/in/**rmannibucau*<http://fr.linkedin.com/in/rmannibucau*>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  *Github:
>>> 
> https://github.com/**rmannibucau*<https://github.com/rmannibucau*>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>>>     2012/10/12 Adrian
>>>>>>>       Mitev
>>>>>>>>>>>          <adrian.mitev@gmail.com>
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>     Hi all!
>>>>>     The stuff
>>>>>>>       in the old
>>>>>>>>>>>          seam-servlet module [1], [2] 
> and
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  [3]
>>>>>>>>>>>>>>>>>            (now
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  merged in
>>>>>     seam-solder)
>>>>>>>       are quite
>>>>>>>>>        useful and
>>>>>>>>>>>          are great
>>>>>>>>>>>>>>>>>>>>>   
>         
>>>  candidate
>>>>>     for
>>>>>>>>>>>>>>>>>             
> adding
>>>>>>>>>>>>>>>>>>>>>>  

>     
>>>        in
>>>>>     Deltaspike.
>>>>>>>>>>>>>>>>>>>>>>  

>     
>>>        1 -
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>  

>     
>>>         
>>>>>>>>>>>         
>>>>>     
> http://docs.jboss.org/seam/3/**3.1.0.Final/reference/en-US/**
>>>>> 
>>> 
> html/servlet-events.html<http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/servlet-events.html>
>>>>>>>>>>>>>>>>>             2 -
>>>>>>>>>>>>>>>>>>>>>>  

>     
>>>         
>>>>>>>>>>>         
>>>>>     
> http://docs.jboss.org/seam/3/**3.1.0.Final/reference/en-US/**
>>>>> 
>>> 
> html/injectablerefs.html<http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/injectablerefs.html>
>>>>>>>>>>>>>>>>>             3 -
>>>>>>>>>>>>>>>>>>>>>>  

>     
>>>         
>>>>>>>>>>>         
>>>>>     
> http://docs.jboss.org/seam/3/**3.1.0.Final/reference/en-US/**
>>>>> 
>>> 
> html/exception-handling.html<http://docs.jboss.org/seam/3/3.1.0.Final/reference/en-US/html/exception-handling.html>
>>>>>>>>>>>>>>>>>>>>     
>        --
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Jason Porter
>>> 
> http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>> 
> http://twitter.com/**lightguardjp<http://twitter.com/lightguardjp>
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Software
>>>>>     Engineer
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Open Source
>>>>>     Advocate
>>>>>>>>>>>>>>>>>>>>     
>       
>>>  Author of
>>>>>     Seam Catch -
>>>>>>>       Next
>>>>>>>>>        Generation Java
>>>>>>>>>>>          Exception Handling
>>>>>>>>>>>>>>>>>>>>     
>        PGP
>>>  key id:
>>>>>     926CCFF5
>>>>>>>>>>>>>>>>>>>>     
>        PGP
>>>  key
>>>>>     available at:
>>>>>>>>>        keyserver.net,
>>>>>>>>>>>          pgp.mit.edu
>>>>>>>>>>>>>>>>>            --
>>>>>>>>>>>>>>>>>            Jason

> Porter
>>>>>>>>>>>>>>>>> 
>>> 
> http://lightguard-jp.blogspot.**com<http://lightguard-jp.blogspot.com>
>>>>>>>>>>>>>>>>>           
>>>>>     http://twitter.com/**lightguardjp
>>>>>>>>>>>         
> <http://twitter.com/lightguardjp>
>>>>>>>>>>>>>>>>>           
> Software
>>>  Engineer
>>>>>>>>>>>>>>>>>            Open

> Source
>>>  Advocate
>>>>>>>>>>>>>>>>>           
> Author of Seam
>>>  Catch -
>>>>>     Next
>>>>>>>       Generation Java
>>>>>>>>>        Exception
>>>>>>>>>>>          Handling
>>>>>>>>>>>>>>>>>            PGP 
> key id:
>>>  926CCFF5
>>>>>>>>>>>>>>>>>            PGP 
> key
>>>  available at:
>>>>>>>       keyserver.net,
>>>>>>>>>        pgp.mit.edu
>>>>>>>>>>>>>>>>            --
>>>>>>>>>>>>>>>>            Christian

> Kaltepoth
>>>>>>>>>>>>>>>>            Blog:
>>>>>     http://chkal.blogspot.com/
>>>>>>>>>>>>>>>>            Twitter:
>>>>>     http://twitter.com/chkal
>>>>>>>>>>>>>>>            --
>>>>>>>>>>>>>>>            Charles 
> Moulliard
>>>>>>>>>>>>>>>            Apache 
> Committer / Sr.
>>>  Enterprise
>>>>>     Architect
>>>>>>>       (RedHat)
>>>>>>>>>>>>>>>            Twitter : 
> @cmoulliard |
>>>  Blog :
>>>>>>>>>       http://cmoulliard.blogspot.com
>>>>>>>>>>>          --
>>>>>>>>>>>          Jason Porter
>>>>>>>>>>>         
> http://lightguard-jp.blogspot.com
>>>>>>>>>>>         http://twitter.com/lightguardjp
>>>>>>>>>>> 
>>>>>>>>>>>          Software Engineer
>>>>>>>>>>>          Open Source Advocate
>>>>>>>>>>>          Author of Seam Catch - Next 
> Generation
>>>  Java
>>>>>     Exception
>>>>>>>       Handling
>>>>>>>>>>>          PGP key id: 926CCFF5
>>>>>>>>>>>          PGP key available at: 
> keyserver.net,
>>>  pgp.mit.edu
> 

Mime
View raw message