Re: Upgrade to the latest Pluto

[Richard Jacob <ja...@apache.org>]

Rudnev, Alex (OCTO) wrote:

>Hi Richard,
>
>  
>
>>>There are a few irrelevant and not important fixes that I probably
>>>      
>>>
>>mentioned
>>    
>>
>>>in my previous messages:
>>>a) /provider/pluto/war/WEB-INF/data/xml/*.xml - DOCTYPE definitions
>>>      
>>>
>>changed
>>    
>>
>>>according to content of the files
>>>
>>>      
>>>
>>Changed also in cvs since mapping files changed in pluto, too.
>>    
>>
>
>I synchronized my *.xml files with those in repository before preparing this
>patch, but problem with the files in repository (as well as with ones in
>Pluto's repository) is that they are invalid. They have "DOCTYPE databases"
>instead of "DOCTYPE mapping", which breaks XML validation (I have WebSphere
>Application Developer, and it catches this kind of stuff).
>
I see, since these files are copied from the pluto project maybe the 
correct source for changing this is the pluto project.
I'll crosspost this.

> 
>  
>
>>>b) /producer/war/wsdl/(*.wsdl | *.xsd) - updated to be consistent with
>>>/wsdl/(*.wsdl | *.xsd).
>>>
>>>      
>>>
>>Thanks for catching this, reflected update in cvs.
>>    
>>
>
>Thanks, I've noticed that. By the way, I assume that axis-generated classes
>correspond to 1.0, not 0.95 :)?
>
Correct, the wsdls in /wsdl are were used to generate the code.
The ones in the war file are just used for description of the service, 
i.e. others can get the wsdl and discover the service's caps.
We should have a servlet doing this, to dynamically generate the correct 
endpoint URLs.
Another ToDo....

>
>  
>
>>>There are changes in the following files from
>>>/src/org/apache/wsrp4j/producer/provider/pluto/driver:
>>>a) DynamicInformationProviderImpl - some old methods, which have
>>>      
>>>
>>different
>>    
>>
>>>signature now and were added by you with correct signature, are removed.
>>>b) PortletInvokerImpl - updated to support request.remoteUser (taken from
>>>WSRP's request.userContext.userContextKey) and response.characterEncoding
>>>(taken from WSRP's request.markupParams.markupCharacterSets)
>>>c) StoredResponse - updated with temporary fix for characterEncoding (to
>>>      
>>>
>>be
>>    
>>
>>>discussed)
>>>d) WSRPPortletEntityImpl - doesn't create Boolean
>>>e) WSRPServletRequestWrapperImpl - updated with temporary fix for
>>>      
>>>
>>remoteUser
>>    
>>
>>>(to be discussed).
>>>      
>>>
>
>With request.remoteUser situation is simple (it should be implemented
>differently, but it doesn't matter at this point), but
>response.characterEncoding requires some additional explanation. 
>Long story short - getPortletOutputStream() after several layers gets
>delegated to org.apache.pluto.core.impl.PortletResponseImpl, which creates
>org.apache.pluto.util.PrintWriterServletOutputStream with code like this:
>...
>wrappedWriter = new PrintWriterServletOutputStream(
>	_getHttpServletResponse().getWriter(),
>	_getHttpServletResponse().getCharacterEncoding()
>);
>...
>
>This PrintWriterServletOutputStream has funny code like this:
>...
>public void write(int b) throws IOException {
>	// this is slow but it works for now
>	writer.write(new String(new byte[] {(byte)b}, encoding));
>}
>...
>, which in addition to performance problems also leads to
>NullPointerException if encoding (which is initialized by
>_getHttpServletResponse().getCharacterEncoding()) is null.
>
>I did not have time to figure out why they use this
>PrintWriterServletOutputStream (it would not help me anyway, because in
>org.apache.wsrp4j.producer.provider.pluto.driver.StoredResponse method
>getOutputStream returns null), but implementation of getCharacterEncoding in
>StoredResponse (return System.getProperty("default.client.encoding");) did
>not work in my environment for obvious reasons :) And wee need this
>getOutpuStream because our portlets implemented in Cocoon and it outputs
>internally to OutputStream, not Writer, as you would have in JSPs.
>Whow :)
>Long story long ...
>  
>
Ok I see.
yet another ToDo...
Need to investigate here.
Do you have any patches for this yet?

>  
>
>>>This patch is based on version from cvs as of 6:20 pm EST(GMT-5:00).
>>>
>>>Thanks,
>>>Ru
>>>
>>>
>>>      
>>>
>>Thanks, let's discuss these tomorrow or on monday (don't know if I can
>>look into it tomorrow).
>>Now it's 1:35am in Germany and time to shut down :)
>>    
>>
>
>Isn't it Halloween night there?
>
>  
>
>>-cheers
>>Richard
>>    
>>
>
>Have to go,
>Cheers,
>Ru
>
>P.S. I've noticed that you rearranged libraries, but still keep two copies
>of commons-logging.(jar|LICENSE) - is it just a legacy, or it has some
>hidden value?
>
just legacy, no value :) .... need to fix that

-cheers
Richard