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:02 GMT
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.

> 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