Re: seam-servlet stuff to deltaspike

Jozef Hartinger Tue, 16 Oct 2012 05:34:57 -0700

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 wasinterpreted that way it would only help us with 2a) which we can dealwith anyway. It would be no help for 2b) ". That is because, as youwrite above, other changes to the spec would be necessary. A differentinterpretation of @ApplicationScoped alone would not be sufficient.

If we would need to wait for another (clarified) version of CDI toallows us to implement this then these features would end up redundantsince 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 <[email protected]>
To: [email protected]
Cc: Mark Struberg <[email protected]>; Pete Muir <[email protected]>
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 <[email protected]>
   To: Mark Struberg <[email protected]>
   Cc: deltaspike <[email protected]>; Pete Muir

<[email protected]>

   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 <[email protected]>
     To: Mark Struberg <[email protected]>
     Cc: deltaspike <[email protected]>;

Pete Muir

   <[email protected]>

     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 <[email protected]>
      To: Mark Struberg <[email protected]>
      Cc: "[email protected]"

     <[email protected]>

      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

<[email protected]>

        To: Jozef Hartinger

<[email protected]>

        Cc: [email protected]
        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

        <[email protected]>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

      <[email protected]>

        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

        <[email protected]>

          wrote:

          +1

          On Sat, Oct 13, 2012 at

10:56 AM,

   Christian

     Kaltepoth

[email protected]> 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

      <[email protected]>

          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 <

   [email protected]>

     wrote:

           +1 for an own

module.

          regards,
          gerhard



          2012/10/12

Mark

   Struberg

      <[email protected]>

           +1 for

   modules/servlet :)

LieGrue,

          strub




          -----

Original

   Message

     -----

From: Jason

   Porter

        <[email protected]>

To:

deltaspike-dev@incubator.**apache.org<[email protected]>

Cc:

Sent: Friday,

   October

     12, 2012

      5:12 PM

Subject: Re:

     seam-servlet stuff

to

        deltaspike

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

      <[email protected]>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

        <[email protected]>

   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

Re: seam-servlet stuff to deltaspike

Reply via email to