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 11:16:58 GMT
If the impls bomb out cracy with ClassCastExceptions or ClassNotFoundE then you cannot deal
with them but you need to fix em.




----- Original Message -----
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Tuesday, October 16, 2012 1:00 PM
> Subject: Re: seam-servlet stuff to deltaspike
> 
> +1,
> 
> DS should deal with implementatiosn (based on the spec but we really deal
> with impl in reality)
> 
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: 
> **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
> 
> 
> 
> 
> 2012/10/16 Jozef Hartinger <jharting@redhat.com>
> 
>>  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<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<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>
>>>>>>>>  "
>>>>>>>> 
>>>>>>>     
> <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<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>
>>>> 
> <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.**apa**che.org<http://apache.org>
>>>> 
> <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>
>>>>  <https://twitter.**com/rmannibucau 
> <https://twitter.com/rmannibucau>>
>>>> 
>>>>>             >*
>>>>>>>>>>>>>>>>>>>>     
>      *Blog:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
> **http://rmannibucau.**wordpre**ss.com/*<http://wordpress.com/*>
>>>> 
> <http://rmannibucau.**wordpress.com/*<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*>
>>>> 
> <http://fr.**linkedin.com/in/rmannibucau*<http://fr.linkedin.com/in/rmannibucau*>
>>>>  >
>>>> 
>>>>>             *Github:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
> https://github.com/****rmannibucau*<https://github.com/**rmannibucau*>
>>>>  <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/****<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<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/****<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<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/****<http://docs.jboss.org/seam/3/**3.1.0.Final/reference/en-US/**>
>>>>  html/exception-handling.html<h**ttp://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://lightguard-jp.blogspot.com>>
>>>>  http://twitter.com/****lightguardjp 
> <http://twitter.com/**lightguardjp><
>>>>  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://lightguard-jp.blogspot.com>>
>>>> 
>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
> http://twitter.com/****lightguardjp<http://twitter.com/**lightguardjp>
>>>> 
>>>>>         
> <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://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
>>>>>>>>>> 
>>>>>>>>>> 
>> 
> 

Mime
View raw message