Totally agree. That makes it much more flexible. Please, feel free to 
change the code.

Pawel

Nicklas Nordborg wrote:
> Thanks for the code. It was something like this that I had in mind. The 
> one thing I don't like is to pass the type as an 'int' parameter in the 
> constructor and having a switch statement that creates the actual object 
> to use. This makes it impossible for others to use their own 
> implementations of 'RPCServiceClientCreator'. Wouldn't it be better to 
> pass a 'RPCServiceClientCreator' directly to the constructor?
> 
> Eg.
> 
> protected AbstractRPCClient(
>    String url, String service,
>    RPCServiceClientCreator serviceCreator)
> {
> ...
> }
> 
> /Nicklas
> 
> Pawel Sztromwasser wrote:
>> Hi Nicklas,
>>
>> I had some time and implemented the 'ServiceFactory' functionality.
>> Gzipped java files are attached. To summarize changes:
>>
>> 1) three new classes/interfaces were created (I put them in
>> net.sf.basedb.ws.client.added package):
>>     a) RPCServiceClientCreator - interface containing RPCServiceClient 
>> getService(String serviceUrl) method for creating RPCServiceClient objects
>>     b) DefaultRPCServiceClientCreator - factory class implementing 
>> interface above. It creates RPCServiceClient objects in the way they 
>> were created in AbstractRPCClient.getService() method.
>>     c) NoChunkRPCServiceClientCreator - the same as above but with CHUNK 
>> option set to false.
>>
>> 2) AbstractRPCClient class uses own RPCServiceClientCreator object to 
>> create objects in getService() method. Creator object is initialized in 
>> constructor (type of creator is an argument of additional constructor). 
>> The creator type can be chosen between values supported by 
>> AbstractRPCClient, available as public static constants (currently only 
>> DEFAULT_RPC_SERVICE_CLIENT and NO_CHUNK_RPC_SERVICE_CLIENT). If no 
>> creator type is supplied, default one is used.
>>
>> 3) all the subclasses of AbstractRPCClient have additional constructor 
>> with last argument being type of RPCServiceClientCreator which refers to 
>> constructor in superclass. This makes possible to choose creator type 
>> when programming BASE2 webservices clients.
>>
>> I attached diffs.txt file which contains diff output on
>> net/sf/basedb/ws/client/ folders for my version and 2.7.1. Just thought, 
>> it might be helpful.
>>
>> I hope the code will be useful.
>>
>> Best wishes,
>> Pawel
>>
>>
>> Nicklas Nordborg wrote:
>>> Pawel Sztromwasser wrote:
>>>> Hello BASE developers,
>>>>
>>>> We have been recently trying to enable retrieving some data from
>>>> BASE2 installation directly into our 'home made' analysis tool. We
>>>> use webservices for that and have to say that you are doing a great
>>>> job.
>>> Thanks.
>>>
>>>> We are really looking forward to use them more extensively.
>>>>
>>>> Recently, when I started testing the tool not only within the local 
>>>> network I noticed that the webservice client does not switch off 
>>>> chunking. It results in attached exception cascade. Chunking is on by
>>>>  default in axis2 and some servers (i.e. our gateway to BASE which 
>>>> apparently uses HTTP1.0 and not 1.1) have problems with it. The
>>>> remedy is to use
>>>>
>>>> options.setProperty(HTTPConstants.CHUNKED, false);
>>>>
>>>> in net.sf.basedb.ws.client.AbstractRPCClient.getService(). I don't
>>>> know what are the drawbacks of it, but that was the only way I could
>>>> run the services in our current setup (BASE2.6 accessible by
>>>> proxypass from exposed webserver). Could this option be set off by
>>>> default or configurable somewhere? Or maybe there is some other
>>>> workaround?
>>> I am afraid that I am not very familiar with all possible options that 
>>> is available in the Axis API:s. There seems to be a lot of them and 
>>> their Javadoc is not very informative about what many of the options 
>>> are used for. The CHUNKED option seems to be related to the way HTTP 
>>> requests are made, but I have to admit that this is the first time I 
>>> have heard of it. This means that I probably know even less than you 
>>> about this.
>>>
>>> I think that, in the future, there may be more requests about being 
>>> able to set other options. So, it may be better to think ahead and try 
>>> to figure out some way to be able to do this as easy as possible. With 
>>> the current BASE API the only workaround that doesn't involve changing 
>>> the BASE code is to subclass all AbstractRPCClient subclasses and 
>>> override the 'getService()' method. This is not very elegent since 
>>> there are several such classes and the new 'getService()' will be 
>>> added to each one of them.
>>>
>>> A better approach may be to create a 'ServiceFactory' interface which 
>>> has a 'createService()' method. The default implementation would then 
>>> work as the AbstractRPCClient.getService() does today. The last step 
>>> is to figure out a way to switch to another 'ServiceFactory' 
>>> implementation either by having a configuration file or by being able 
>>> to specify it programmatically.
>>>
>>> I have opened a ticket for this issue 
>>> http://base.thep.lu.se/ticket/1057. It falls under the 'contributions 
>>> welcome' category since right now we are forced to prioritize other 
>>> things.
>>>
>>> /Nicklas
>>>
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> basedb-devel mailing list
>>> basedb-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/basedb-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> basedb-devel mailing list
>> basedb-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/basedb-devel
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> basedb-devel mailing list
> basedb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/basedb-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
basedb-devel mailing list
basedb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/basedb-devel

Reply via email to