Re: seam-servlet stuff to deltaspike

Tue, 16 Oct 2012 03:53:41 -0700 

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

        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

       

    <[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
































					Reply via email to