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