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.