On Tue, Aug 19, 2008 at 4:37 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Sat, Aug 16, 2008 at 8:42 AM, ant elder <[EMAIL PROTECTED]> wrote: > >> One thing I think could be better is the way applications get hold of the >> ComponentContext. Currently its done using a context attribute but I think >> it may be better to have something like a static method >> o.a.t.s.api.ComponentContext.getComponentContext() that returns the >> ComponentContext for the current thread. We could implement that by having >> the Tuscany Servlet Filter put the current ComponentContext in a thread >> local for the getComponentContext to use. That also has the advantage as >> conversational services would work transparently to the user code whereas >> right now (if conversational webapps worked) they'd have to know to pull the >> ComponentContext from the Servlet request instead of the Servlet context. >> >> ...ant >> >> On Sat, Aug 16, 2008 at 1:57 AM, Raymond Feng <[EMAIL PROTECTED]>wrote: >> >>> Nice document. I'll try a few samples before I can give any feedback. >>> >>> Thanks, >>> Raymond >>> >>> *From:* ant elder <[EMAIL PROTECTED]> >>> *Sent:* Wednesday, August 13, 2008 11:38 PM >>> *To:* [email protected] >>> *Subject:* Re: Tuscany integration with Geronimo: What's common to SCA >>> and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany SCA >>> support in the Geronimo admin Console >>> >>> FYI, there is now some doc on the current state of implementation.web at >>> http://tuscany.apache.org/sca-java-implementationweb.html and samples >>> demonstrating some scenarios: helloworld-servlet, helloworld-jsp, and >>> helloworld-web. >>> >>> Would be great to start trying to integrate this with some of the JEE >>> introspection code thats been added recently, is there any doc on that or >>> explanations of how it could be used? >>> >>> ...ant >>> >>> On Mon, Jul 28, 2008 at 12:15 PM, ant elder <[EMAIL PROTECTED]> wrote: >>> >>>> While thats being done I'd like to do some more work on >>>> implementation.web and section 5.4 of the sca jee spec. I'd already started >>>> on this a while back but now i'd like to getting it going properly >>>> intergrated in to the build and our existing runtime support. Eventually >>>> i'd >>>> like webapps and implementation.web to support using the Tuscany >>>> distributed >>>> domain but it will take some smaller steps before it gets to there. >>>> >>>> ...ant >>>> >>>> On Fri, Jul 18, 2008 at 3:55 PM, Vamsavardhana Reddy < >>>> [EMAIL PROTECTED]> wrote: >>>> >>>>> As a first step towards the integration, here are some items that I >>>>> have identified with Raymond and Sebastien's help (Raymond, Sebastien, >>>>> please correct me if I failed to capture the essence): >>>>> >>>>> 1. Model an EAR/WAR/EJB-JAR as an SCA contribution: By this I mean, >>>>> given a Java EE archive (non-SCA-enhanced for now), compute by >>>>> introspecting >>>>> the archive, the SCA composite that represents the archive as an SCA >>>>> contribution as per SCA JEE Integration Spec [1]. In this step, all the >>>>> business interfaces implemented by session beans result in SCA services >>>>> and >>>>> all the EJB references (used in session beans, MDBs and web components) >>>>> result in SCA references. >>>>> >>>>> 2. Get binding.ejb work with services. Currently binding.ejb works only >>>>> with references. Once binding.ejb works with services, the references >>>>> computed in step 1 above can be wired to the services in the domain using >>>>> ejb binding. >>>>> >>>>> 3. Common Administration view. Once a JEE contribution is added to a >>>>> domain, it should be administrable like any other SCA contribution. The >>>>> fact that the contribution may actually be run as a Java EE application >>>>> on a >>>>> Java EE server should be transparent to the administrator. >>>>> >>>>> These three items should enable the coverage of scenarios 2.1-2.3 in >>>>> section 2 of SCA JEE Spec [1]. There is no Geronimo specific stuff yet in >>>>> this. >>>>> >>>>> I have done a little bit of experimentation with EJB jars. Using >>>>> openejb-core and openejb-jee modules, it seems fairly simple to introspect >>>>> EJB3 jars (even though I already ran into some glitches with the interface >>>>> definitions). Will post to the list soon on my findings. >>>>> >>>>> ++Vamsi >>>>> >>>>> [1] >>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf >>>>> >>>>> On Wed, Jul 9, 2008 at 9:37 PM, ant elder <[EMAIL PROTECTED]> >>>>> wrote: >>>>> >>>>>> Ok, from the initial email there were only two points labelled [Common >>>>>> to SCA]: >>>>>> >>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a SCA >>>>>> domain [Common to SCA] >>>>>> * Resolve the wirings at SCA domain level for the top-level composites >>>>>> [Common to SCA] >>>>>> >>>>>> and all the other points are labelled [Specific to Geronimo]. I guess >>>>>> on the surface of it that all sounds fine to me as long as [Common to >>>>>> SCA] >>>>>> means its the APIs and code behind the APIs which are provided in a >>>>>> common >>>>>> way by Tuscany. For something like the GSoC project doing the Geronimo >>>>>> console management plugin that still needs to elements to be specific to >>>>>> Geronimo to be integrated as part of the Geronimo admin console doesn't >>>>>> it? >>>>>> >>>>>> ...ant >>>>>> >>>>>> >>>>>> On Wed, Jul 9, 2008 at 4:21 PM, Raymond Feng <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> It's good to add the use cases from SCA/JEE spec into this >>>>>>> discussion. But I want to make sure the purpose of this thread is to >>>>>>> identify what's common to SCA in all hosting environment and what's >>>>>>> specific >>>>>>> to Geronimo. Base on the classification, we should implement the common >>>>>>> features in a generic way and specific things in a Geronimo way. >>>>>>> >>>>>>> Thanks, >>>>>>> Raymond >>>>>>> >>>>>>> *From:* ant elder <[EMAIL PROTECTED]> >>>>>>> *Sent:* Wednesday, July 09, 2008 12:56 AM >>>>>>> *To:* [email protected] >>>>>>> *Subject:* Re: Tuscany integration with Geronimo: What's common to >>>>>>> SCA and what's sepcific to Geronimo?, was: Re: GSoC Project - Tuscany >>>>>>> SCA >>>>>>> support in the Geronimo admin Console >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 3, 2008 at 11:43 AM, ant elder <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 1, 2008 at 12:57 AM, Raymond Feng <[EMAIL PROTECTED]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I would like to extend the discussion a bit to help us better >>>>>>>>> understand what user experience we would like to bring to Geronimo >>>>>>>>> developers/users with Tuscany/SCA. >>>>>>>>> >>>>>>>>> I suggest that we use a usage scenario-driven approach to create a >>>>>>>>> list of tasks/features and mark them either it's common to SCA >>>>>>>>> independent >>>>>>>>> of the hosting environment or it's specific to Geronimo. >>>>>>>>> >>>>>>>>> Here is a few roles a Geronimo instance can play in the SCA domain: >>>>>>>>> >>>>>>>>> 1) Geronimo is a member of a SCA domain to deploy/run SCA >>>>>>>>> applications >>>>>>>>> >>>>>>>>> * Connect to the SCA domain admin app to get the image of a >>>>>>>>> resolved composite application >>>>>>>>> * Be able to deploy the resolved composite application in the VM of >>>>>>>>> Geronimo, either as JEE application or standalone [Specific to >>>>>>>>> Geronimo] >>>>>>>>> * Run the resolved composite application >>>>>>>>> * Provide the binding/implementation/policy extensions to realize >>>>>>>>> SCA binding/implementation/policy types.[[Specific to Geronimo] >>>>>>>>> * Hook with the other containers in Geronimo to provide various >>>>>>>>> bindings, such as HTTP connectors with Tomcat >>>>>>>>> * Hook with the QoSs such Transaction and Security provided by >>>>>>>>> Geronimo to implement the SCA policies >>>>>>>>> * Create/manage related resources for some bindings, such as JMS >>>>>>>>> connection factories and queues [Specific to Geronimo] >>>>>>>>> >>>>>>>>> 2) Geronimo hosts the SCA domain admin application >>>>>>>>> >>>>>>>>> * Manage the configuration (Contributions/Composites/Nodes) for a >>>>>>>>> SCA domain [Common to SCA] >>>>>>>>> * Resolve the wirings at SCA domain level for the top-level >>>>>>>>> composites [Common to SCA] >>>>>>>>> * Deploy the resolved composite image to a in-process or remote >>>>>>>>> host [A Geronimo or JSR88 Deployer may be specific to Geronimo] >>>>>>>>> >>>>>>>>> 3) Geronimo hosts (some) contributions for a SCA domain >>>>>>>>> * Expose them as URLs to the SCA domain admin application. In this >>>>>>>>> case, It functions as a repo for SCA contributions. [Specific to >>>>>>>>> Geronimo] >>>>>>>>> >>>>>>>>> I think we should only try to implement a feature in a >>>>>>>>> geronimo-specific way only if it's specific to Geronimo. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Raymond >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Now that the 1.0 version of the SCA JEE spec [1] is out that defines >>>>>>>> several concrete use cases and scenarios we can use to define the >>>>>>>> tasks and >>>>>>>> features we need. For example, how about one goal be running in >>>>>>>> Geronimo the >>>>>>>> application.ear shown at line 1131 page 41 "Appendix A – use cases" of >>>>>>>> the >>>>>>>> SCA JEE spec. >>>>>>>> >>>>>>>> ...ant >>>>>>>> >>>>>>>> [1] >>>>>>>> http://www.osoa.org/download/attachments/35/SCA_JAVAEE_Integration_V100.pdf >>>>>>>> >>>>>>> >>>>>>> Any comments on this or does silence mean that example from the JEE >>>>>>> spec is an ok use case to be working towards for our first try at the >>>>>>> new >>>>>>> Geronimo integration? >>>>>>> >>>>>>> ...ant >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > Hi > > The SCA JEE spec [1] does say we have to support @Context for > implementation.web although the first time it's mentioned it's not clear if > it means ComponentContext or RequestContext. Your suggestion sounds like you > are making the ComponentContext request specific. Is that becomming a > RequestContext? > > Can you say a little more about how this might help with conversations? > Each call to ComponetContext.getServiceReference() is intended to start a > new conversation so regardless of where you get the component context from > you are going to have to cache service references independently if you want > to continue the conversation across HTTP servlet requests. Maybe that's not > what you are getting at. > > The JEE spec does talk about threads and conversations but I've read it a > couple of times and it doean't make sense to me either in the context of > cross service request calls. Maybe they did this on purpose as they assume > that service references are cached out of band in this situation. > > Simon > > [1] > http://www.oasis-open.org/committees/download.php/28799/SCA_JAVAEE_Integration_V100.doc > We don't support conversations in webapp clients right now, and i agree the spec isn't that clear, so i've not thought much at all about how we could support it, we'll probably need a way to get at both the ComponentContext and RequestContext. What i was asking about was if there is any preference to use a method like getComponentContext()/getRequestContext() over using the context attributes directly? ...ant
