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
