[cddlm] CodeBase semantics

[Ayla Debora Dantas de Souza - Projeto Ourgrid]

Hi,

regarding the discussion about CodeBase and CommandPath semantics that 
can vary from implementation to implementation and the Component Model 
test plan, I have an initial doubt. In the CDLs from the test plan, 
there is a part:

<!-- change these per your system -->

<cmp:CodeBase>http://localhost/test1.jar</cmp:CodeBase>

<cmp:CommandPath>com.exns.Test1</cmp:CommandPath>


I was not sure if the code that will be provided in source forge will be 
the code for this class (com.exns.Test1) or if we should change  
CodeBase and CommandPath values.

In this latter case, can we totally replace both the CodeBase and 
CommandPath to something that is understandable by our engine or should 
the engine support  CodeBases specified as a ".jar" file and simply 
execute (someway) one of the classes from this jar that should be able 
to provide a service endpoint for the component?

In our Engine, for example, we are only supporting now the deployment of 
"war" files, and then, the "war" file once deployed will originate the 
service whose endpoint will manage the component lifecycle. Is this ok?

Thanks,
  Ayla

Milojicic, Dejan S (HP Labs) wrote:

>Attendees: Jun, Ayla, Satish, Guilherme, Flavio, Steve, Stuart, Dejan.
>
>Note taker: Dejan.
>
>  
>
>>0. Reference implementation status update 
>>1. Update on the testing of interoperability 
>>    
>>
>
>Ayla: did some additional tests, would like some more examples of CDL.
>Will be working on tests from Stuart, not sure about how component model
>is going. Still beginning, will make questions as soon as we have them.
>
>Steve: was out last week. Given up completely from Apache Axes 2, and
>instead rolling back to his own. Targeting next week, automating process
>with bringing up endpoint. First release will be atrociously bad and
>broken. A lot of interoperability problems because SOAP stack will be
>new, then ramp up quickly. Serve it up from home rather than from behind
>the firewall. SmartFrog will use and interesting implications about
>security, limit it to a small set of components (1 out of 10) for
>security reasons.
>
>Stuart: their plan is to leverage Ayla's endpoint to test their end
>point and then they will put up their own endpoint. Released component
>model spec test. Source forge was down, so did not put it in the source
>forge.  Steve: source forge has broken file system, do not trust it.
>
>Jun/Satish: get access some time this week, has not heard from the sys
>admin in Princeton, they should have the end point up and running by
>Friday, currently testing Ayla's EPR. Also looking into component model
>test plan.
>
>CDL is pretty good. Jun will work on it next week and Steve will run the
>automation of inclusion thereafter.
>
>  
>
>>2. OGSA and CDDLM F2F meeting on Thursday 
>>    
>>
>
>Jun and Dejan will attend, Stuart will attend remotely.
>
>  
>
>>3. Going over the BLAST example that Jun provided 
>>    
>>
>
>Steve: We should have quotes right, turn off autocorrect smart quotes.
>
>Ayla: uncertain about specifying "code base", how the engine would not
>that. How does the engine work, each implementation should chose to
>understand the code base. Jun: this example is not meant to have a
>running code, but describe how it is used for BLAST code, in the real
>code one would have to write a real URI and some appropriate URI.
>Guilherme: too much flexibility and decision on implementation could
>lead to different understanding of "code base", this should be a problem
>for interoperability. In other words, CDL can not work in certain
>implementation. Steve agrees with that. 
>
>  
>
>>4. Going over the scenarios that Steven Newhouse provided 
>>    
>>
>
>Team will review the document.
>
>  
>
>>5. Various
>>    
>>
>
>Update on the documents. CDL is almost done with the reviewing.
>Deployment APIs will go through the steering committee review shortly.
> 
>Thanks,
>
>Dejan.
>
>
>  
>