Hi Stuart, thanks for answering. In fact we will change the CodeBase and CommandPath according to our engine, I just wanted to know if there was any problem on that. Thanks again, Ayla Stuart Schaefer wrote:
Ayla,
I have looked into providing "stock" components. My implementation is based on the .NET Framework. I know that everyone else is using some Java based technology like Tomcat or otherwise. I don't think this will be feasible to provide, as the engine differences are not small.
The CDL snippet you outlined below presumes that you will change the CodeBase element to be some .war file for your implementation. The CommandPath should be changed as well to suit your engine.
Stuart
-----Original Message----- From: owner-cddlm-wg@ggf.org [mailto:owner-cddlm-wg@ggf.org] On Behalf Of Ayla Debora Dantas de Souza - Projeto Ourgrid Sent: Wednesday, April 05, 2006 1:13 PM To: cddlm-wg@ggf.org Subject: [cddlm] CodeBase semantics
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.