[seek-dev] potential unified ant build file for seek/ecogrid

Jing Tao tao at nceas.ucsb.edu
Mon Sep 12 09:02:52 PDT 2005 

Hi, Kevin:

EcogridFactoryQueryClient is the one we need to be kept and maintained. At 
first, we used EcogridQueryClient. But we found Ecogrid had problem to 
handle lots of request at same time. So we changed service to factory 
pattern and changed the client to factory client. But the all ecogrid 
service (Metacat, Digir and SRB) didn't update to factory pattern at same 
time. So we kept both clients. Since every service is update to factory 
pattern now, we can remove EcogridQueryClient from archive.

Jing



Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Sun, 11 Sep 2005, Kevin Ruland wrote:

> Date: Sun, 11 Sep 2005 14:44:41 -0500
> From: Kevin Ruland <kruland at ku.edu>
> To: Bing Zhu <bzhu at sdsc.edu>
> Cc: seek-dev at ecoinformatics.org
> Subject: Re: [seek-dev] potential unified ant build file for seek/ecogrid
> 
> Bing,
>
> Thanks for the information.  So is it correct that EcogridQueryClient is
> the source code to be kept and maintained, and EcogridFactoryQueryClient
> is old and out of date?  If this is true, why does Kepler use
> EcogridFactoryQueryClient exclusively?
>
> If one is not to be used, it should be removed from the archive to
> prevent such confusions.
>
> Kevin
>
> Bing Zhu wrote:
>
>> The 'EcogridQueryClient' was modified long ago to handle both
>> factory and non-factory ecogrid service with following syntax.
>>  $java [-DFACTORY=no] EcogridQueryClient query local_filename GSH
>>
>> (This is documented in displaying Usage in the code.)
>>
>> The default is for factory service. e.g.
>>   $ java EcogridQueryClient query local_filename GSH
>>
>> In case for a non-factory service,
>>    $ java -DFACTORY=no EcogridQueryClient query local_filename GSH
>>
>> BTW, the ecogrid client package, organized before workshop and targeted to
>> be released to users has followings.
>>  EcogridQueryClient
>>  EcogridAuthClient
>>  EcogridPutClient
>>  EcogridRegistryClient
>>
>> Documents with descriptions of these clients, syntax and examples
>> for systems within Ecogrid are:
>>  Ecogrid.readme.txt
>>  Metacat.readme.txt
>>  SRB.readme.txt
>>  DiGIR.readme.txt
>>  registry.readme.txt
>> .
>>
>> These documents are all in Ecogrid cvs place at /seek/projects/ecogrid/docs.
>>
>>
>> Bing
>>
>>
>>
>> -----Original Message-----
>> From: seek-dev-bounces at ecoinformatics.org
>> [mailto:seek-dev-bounces at ecoinformatics.org]On Behalf Of Kevin Ruland
>> Sent: Friday, September 09, 2005 6:57 AM
>> To: Kevin Ruland
>> Cc: seek-dev at ecoinformatics.org
>> Subject: Re: [seek-dev] potential unified ant build file for
>> seek/ecogrid
>>
>>
>>
>> Jing,
>>
>> I now have commit privs in ecogrid and have committed this as
>> build_new.xml.  After it has been verified to generate the proper code,
>> I suggest we mv it to build.xml and remove the other build files (like
>> build_digir.xml).
>>
>> I have set it up to include all the client/*.class files in the stub
>> jar.  It can be broken out if anybody objects.
>>
>> Also, I have noticed in the client source directory there are two
>> different "client" java classes, one including "Factory" in its name, on
>> one without.  After hacking the kepler code some, I noticed that
>> EcogridQueryClient is no used -- I suspect it was an older client code.
>> Rather than keeping dead code in the repository, I suggest it be removed
>> (Attic'd).
>>
>> Kevin
>>
>> Kevin Ruland wrote:
>>
>>
>>
>>> Jing,
>>>
>>> I try to follow this tenet, "Minimize resource requirements of the
>>> client."  It is very generate but has a couple of implications.
>>>
>>> 1)  Write client code in a way to minimize external requirements such as
>>> additional jar files and classes.
>>>
>>> 2)  Attempt to ease the programmer's burdon for coding and deployment.
>>>
>>> #1 implies that we should not require lots of additional things for the
>>> client code.  This includes such things as the additional client code
>>> required for Digir (I'm working on this now) and attempt to write code
>>> which operates with multiple versions of 3rd party jars.
>>>
>>> #2 means make the api as easy as possible and try to reduce the jar
>>> count required for deployment.
>>>
>>> Reducing the jar count helps in a few ways.  It makes the software
>>> easier to use because the client code doesn't need to track multiple
>>> jars.  It also makes the application faster because the class loader
>>> doesn't have as many jar files to scan through in order to find a
>>> particular class.
>>>
>>> If can can deliver a single client side jar which contains all the
>>> required goodies (EcogridFactory*.class) and all the stubs I think that
>>> would be useful.  I would support having a different seperation based on
>>> more functional lines:  Query stub classes + Query client class in one
>>> jar, Registry stub classes + Registry classes in another jar, etc.
>>>
>>> As for the webapp having one additional class in a jar file, the overall
>>> impact of that is rather minimal.  In addition, it is not uncommon for
>>> the server side code to require the client code anyway (EJB is like
>>> this, but here it is not, of course.)
>>>
>>> Kevin
>>>
>>> Jing Tao wrote:
>>>
>>>
>>>
>>>
>>>
>>>> Hi, Kevin:
>>>>
>>>> The only reason i think, that client class is not in the stub jar is
>>>> we don't want to put the client class into web app though it wouldn't
>>>> hurt anything. I am not quite sure which way is better: seperate stub
>>>> and client jar files, but have two jar files; or merge stub and client
>>>> into same jar, but client class will go to web apps. At that time, we
>>>> chose the first option. What is your opinion?
>>>>
>>>> Thanks,
>>>>
>>>> Jing
>>>>
>>>> Jing Tao
>>>> National Center for Ecological
>>>> Analysis and Synthesis (NCEAS)
>>>> 735 State St. Suite 204
>>>> Santa Barbara, CA 93101
>>>>
>>>> On Thu, 8 Sep 2005, Kevin Ruland wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Date: Thu, 08 Sep 2005 16:51:28 -0500
>>>>> From: Kevin Ruland <kruland at ku.edu>
>>>>> To: Jing Tao <tao at nceas.ucsb.edu>
>>>>> Cc: seek-dev at ecoinformatics.org
>>>>> Subject: Re: [seek-dev] potential unified ant build file for
>>>>> seek/ecogrid
>>>>>
>>>>>
>>>>> Jing,
>>>>>
>>>>> Couple of things.  I don't seem to have commit privs on
>>>>> seek/projects/ecogrid so it won't get in there by me.  And I did see
>>>>> that Digir had a clientJar task and I'm attempting to add that now.
>>>>> However, after I remove all the yucky digir stuff  from that jar, about
>>>>> the only thing left will be EcogridFactoryQueryClient.class.  Is there
>>>>> any reason this file cannot be bundled up with the stubs jar, since
>>>>> kepler needs to have the stubs too?  It of course won't hurt the web app
>>>>> at all to have it in there.
>>>>>
>>>>> Kevin
>>>>>
>>>>> Jing Tao wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Sure, I will add metacat to it.
>>>>>>
>>>>>> Jing
>>>>>>
>>>>>>
>>>>>> Jing Tao
>>>>>> National Center for Ecological
>>>>>> Analysis and Synthesis (NCEAS)
>>>>>> 735 State St. Suite 204
>>>>>> Santa Barbara, CA 93101
>>>>>>
>>>>>> On Thu, 8 Sep 2005, Kevin Ruland wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>> _______________________________________________
>>> Seek-dev mailing list
>>> Seek-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Seek-dev mailing list
>> Seek-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>>
>>
>>
>
> _______________________________________________
> Seek-dev mailing list
> Seek-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-dev
>
>

More information about the Seek-dev mailing list