[
http://jira.nuxeo.org/browse/NXP-1720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_30372
]
Radu Darlea commented on NXP-1720:
----------------------------------
"> I am looking at the LiveEdit implementation (NuxeoRemotingBean.java). As far
as I can tell, the
> - DocumentProperty.name is storing XPath (without the schema name)
> - DocumentProperty.value is storing the value "encoded" as string.
> Q: how can the client tell which schema contain a particular property (XPath)?
> OTOH I see that saving the document is expecting client to send 3 maps
> identified by the keys dublincore, file and content.
> Q: how can the client tell which schema contain a particular property and
> compose the appropriate maps?
>
> I suppose the client has a hardcoded perspective on the Nuxeo Documents. Is
> that correct?
> I intend to introduce the schema name as parameter to break this aspect. The
> client has to take first the list of the forming schemas and for each one
> call the "getProperties()" methods.
> Another option would be to encode the DocumentProperty.name as schema name +
> XPath. The client and server will have to decode/encode the name to obtain
> the schema and the XPath, which also is not very elegant.
> And maybe a third option is to compose on server the composed map simulating
> the schemas. This could make the communication less simple and harder to
> maintain.
> I am for first option. Maybe the API will be a little longer, but simpler and
> more intuitive.
>
> Well, a forth option is to preserve the current perspective and let client
> decide which property belongs to which schema. But I think is not very nice...
For any new uses of "XPath" paths in Nuxeo, I want us to use the full
prefixed-based property names. That's the way to be extensible and useable in
an XML setting. An that's what real XPath expects.
All the Nuxeo schemas we manipulate should be associated with a prefix, for
instance "dc" with the schema "dublincore". When using these properties in
XPath paths, the prefix must be included: dc:title. If we had complex
properties, that could be for instance my:addresses[2]/my:firstName.
Now, for backward compatibility reasons there are three things that enter into
play:
- not all schemas are specified with a prefix, in that case we use the schema
name itself as a prefix. For instance file:content. But this should be
discouraged.
- some APIs have to be ready for uses where the prefix is missing, in that case
it has to be deduced by asking the type service for the first schema having
this field name. So my:addresses[2]/firstName or addresses[2]/firstName would
be recognized by APIs that take backward compatibility into account.
- in the nuxeo schema system the subfields of a complex type currently are not
associated with a prefix, but eventually they should be.
This is all to plan for a clean future."
"A java EJB client is sending blobs to server by using the StreamingBlob
implementation.
This implementation is able to transfer the content as a real stream.
EJB remoting is not able to stream large content of data. You cannot pass
InputStreams as arguments to a remote method.
Because they are not serializable.
You may think then, ok no pb - I am implementing a serializable inputstream
that overrides default java serialization and write directly on the output
stream the blob content. You can try but it will not work. Simply because java
RMI is not designed for this.
In fact the output stream where you will serialize your content will be a
memory output stream so in fact you are writing your blob in memory.
We faced this problem in the early implementation of our Blobs.
First we used in memory blobs. Obviously this limit blob size.
Then we used the FileBlob implementation that is doing exactly what I described
above. This doubled the maximum blob size but still
impose blob size limits (as I explained above). If I remember well uploading
blobs over ~200MB on a regular installation was not working.
Then we implemented StreamingBlob whih is the recommended implementation to be
used when blobs need to be transfered over network.
The streaming blob is in fat using a runtime service : the streaming service.
When it is serialized it will upload the blob content to the
streaming server (there is only one in a nuxeo cluster) and then instead of
sending the content to the server it sends an URI identifying the blob uploaded
on the streaming server. Then the server is using that URI to retrieve content.
This way blobs an be transfered with no limitation on their size.
So a normal java client must use this implementation.
In your case I see a single solution: break your blob in its constituent parts
and send the byte[] array using MTOM.
But you should check if MTOM impl. enables you to write the blob content
directly to the output network stream
and not in memory first and then to transfer it on the network stream (as RMI
is doing). If it is doing first a copy in memory
then we will have a limitation on the blob size.
If MTOM is not working as expected there is another possible approach: Use a
similar approach as the one we use with EJB remoting.
This means you upload the blob content using the streaming service (that is
returning back an unique id for the blob - the blob URI)
and then you send only the blob URI as part of the soap message.
The problem here is that the streaming service is java specific. So you cannot
use it from .NET for example.
To solve this we can implement an HTTP servlet that is uploading the blob into
the streaming service.
(I think this is someting like a home made MTOM) "
> Implement LiveEdit Web Service on top of JAXWS
> ----------------------------------------------
>
> Key: NXP-1720
> URL: http://jira.nuxeo.org/browse/NXP-1720
> Project: Nuxeo Enterprise Platform 5
> Issue Type: New Feature
> Affects Versions: 5.2
> Reporter: Radu Darlea
> Assignee: Radu Darlea
> Fix For: 5.2
>
>
> Implement the new LiveEdit Web Service.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.nuxeo.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
ECM-tickets mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm-tickets
