Obviously I am not a voting member but would like to ask: Will the samples/documentation be updated to cover the JSON browser binding (CMIS 1.1) and the Type Mutability (also CMIS 1.1). Primarily the http://chemistry.apache.org/java/developing/guide.html and the samples bundled in the source code from the SVN /trunk? I assume it will just take some time given all the development work on CMIS 1.1 that you're all doing. We are heavy users of OpenCMIS and are looking forward to these new features. (obviously realizing that that server vendor implementations have to support this :-) ) Thanks for all the great work. Mark On Tue, May 14, 2013 at 10:21 AM, Florian Müller <fmui@apache.org> wrote: > Hi, > > What do you think about releasing OpenCMIS 0.9.0? > The CMIS 1.1 implementation is complete for all bindings. The overall > performance has been improved and there are no major issues. > I think it's a good time to cut a release. > > - Florian > >
The @since tag is usually for the library version and this is the
specification version. I have also adapted the JavaDoc configuration in
the main pom.xml to recognize this custom tag and format it nicely.
The @cmis tag might avoid confusion later when OpenCMIS reaches the
versions 1.0 and 1.1.
But if there is consensus to use @since here, I'm fine with that.
- Florian
> This is extremely useful (and a lot of work thanks) but maybe we could
> use a standard Javadoc tag that tools will pick up and display nicely,
> like:
>
> @since CMIS 1.0
> @since CMIS 1.1
>
> A quick sed -i could do the change on all the files at once.
>
> Florent
>
> On Fri, May 17, 2013 at 6:05 PM,<fmui@apache.org> wrote:
>> more JavaDoc
>
>> @@ -61,60 +61,80 @@ public interface CmisObjectProperties {
>> /**
>> * Returns the name of this CMIS object (CMIS property
>> *<code>cmis:name</code>).
>> + *
>> + * @cmis 1.0
>> */
>> String getName();
>>
>> /**
>> * Returns the description of this CMIS object (CMIS property
>> *<code>cmis:description</code>).
>> + *
>> + * @cmis 1.1
>> */
>> String getDescription();
>>
>
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
>
This is extremely useful (and a lot of work thanks) but maybe we could
use a standard Javadoc tag that tools will pick up and display nicely,
like:
@since CMIS 1.0
@since CMIS 1.1
A quick sed -i could do the change on all the files at once.
Florent
On Fri, May 17, 2013 at 6:05 PM, <fmui@apache.org> wrote:
> more JavaDoc
> @@ -61,60 +61,80 @@ public interface CmisObjectProperties {
> /**
> * Returns the name of this CMIS object (CMIS property
> * <code>cmis:name</code>).
> + *
> + * @cmis 1.0
> */
> String getName();
>
> /**
> * Returns the description of this CMIS object (CMIS property
> * <code>cmis:description</code>).
> + *
> + * @cmis 1.1
> */
> String getDescription();
>
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
There are certainly use cases for self-signed certificates (althoug no good ones from a security perspective). But as I said, the Objective-CMIs lib perfectly supports these use cases in the authentication provider, there is no need to extend the HTTPRequest classes by an additional parameter. So the right place to implement such a feature is in an authentication provider and if there is concern that developers might struggle doing so we could either provide sample code for this or enhance the default provider (which I obviously would not prefer, but this is still the better option as you can completely swap out this (dangerous) provider and get back to a secure system). How about that for a proposal? Peter
I'd agree with Mike's assessment of the market drivers. We've seen the same kind of market pressure in some work we've done in this space. Lots of developers and IT shops will use self signed certs in dev environments. Any implementation that demands valid SSL certs will have trouble getting deployed and adopted in the real world. At least, that's been our experience for SDK level tooling we've done around remoting CMS capabilities to Android and iOS clients. thx, g George Florentine VP, Engineering Office: +1.303.542.5173 Mobile: +1.303.669.8628 Fax: +1.303.544.0522 www.FlatironsSolutions.com George.Florentine@FlatironsSolutions.com -----Original Message----- From: Mike Hatfield [mailto:mike.hatfield@alfresco.com] Sent: Friday, May 17, 2013 8:34 AM To: dev@chemistry.apache.org Cc: objective-cmis@googlegroups.com Subject: Re: kCMISSessionAllowUntrustedSSLCertificate Hi Peter, The primary driver for this flag is to support app deployments for development environments where the developers are building server-side applications (rather than mobile clients) and using self-signed SSL certificates. The vast majority of these engineers just aren't skilled in, nor tooled-up to implement *any* sort of iOS development, let alone to code and deploy a new authentication provider in a library wrapped in a library wrapped in an app. At Alfresco, we received many requests for our "Alfresco Mobile" app to support this scenario. Whilst our app exposes this setting via user preferences, we were mindful that this is far from ideal from a security standpoint - but had to weigh that against strong commercial drivers. That's why this behaviour has been designed to be off by default and must very explicitly be switched on during session creation; something app developers can choose to not expose at all should they wish. I believe not having this feature available at all would severely limit the usefulness of any app built upon Objective-CMIS and, I fear, therefore similarly limit interest in the platform. Regards, Mike -- Mike Hatfield Lead Engineer, Mobile Apps Alfresco Software, Inc. On 17 May 2013, at 13:54, "Eberlein, Peter" <peter.eberlein@sap.com> wrote: > Hi Peter, > > I noticed the new session parameter, kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, server certificate validation is skipped so SSL connections to untrusted servers can be established. > > I don't think that we should have such a parameter. The world is already insecure enough without encouraging people to deactivate essential security settings. If there is a need to accept untrusted server certificates temporarily, like during development, than this can easily be done by providing a custom authentication provider. This was already possible before this change, without extending the standard implementation with insecure code. Or did I miss something? I would feel a lot better if this whole "feature" was removed again and whoever needs to do such messy things does them in own code in a custom authentication provider. > > Or is it just me who is overly sensitive here? What does everyone else think? > > Peter > >
Hi Peter, The primary driver for this flag is to support app deployments for development environments where the developers are building server-side applications (rather than mobile clients) and using self-signed SSL certificates. The vast majority of these engineers just aren't skilled in, nor tooled-up to implement *any* sort of iOS development, let alone to code and deploy a new authentication provider in a library wrapped in a library wrapped in an app. At Alfresco, we received many requests for our "Alfresco Mobile" app to support this scenario. Whilst our app exposes this setting via user preferences, we were mindful that this is far from ideal from a security standpoint - but had to weigh that against strong commercial drivers. That's why this behaviour has been designed to be off by default and must very explicitly be switched on during session creation; something app developers can choose to not expose at all should they wish. I believe not having this feature available at all would severely limit the usefulness of any app built upon Objective-CMIS and, I fear, therefore similarly limit interest in the platform. Regards, Mike -- Mike Hatfield Lead Engineer, Mobile Apps Alfresco Software, Inc. On 17 May 2013, at 13:54, "Eberlein, Peter" <peter.eberlein@sap.com> wrote: > Hi Peter, > > I noticed the new session parameter, kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, server certificate validation is skipped so SSL connections to untrusted servers can be established. > > I don't think that we should have such a parameter. The world is already insecure enough without encouraging people to deactivate essential security settings. If there is a need to accept untrusted server certificates temporarily, like during development, than this can easily be done by providing a custom authentication provider. This was already possible before this change, without extending the standard implementation with insecure code. Or did I miss something? I would feel a lot better if this whole "feature" was removed again and whoever needs to do such messy things does them in own code in a custom authentication provider. > > Or is it just me who is overly sensitive here? What does everyone else think? > > Peter > >
Hi Peter many thanks for your comments. As I am about to leave Alfresco in less than a week I would like to pass this question on to Mike Hatfield (cc'd) Kind regards Peter On 17 May 2013 13:54, Eberlein, Peter <peter.eberlein@sap.com> wrote: > Hi Peter, > > I noticed the new session parameter, > kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, > server certificate validation is skipped so SSL connections to untrusted > servers can be established. > > I don't think that we should have such a parameter. The world is already > insecure enough without encouraging people to deactivate essential security > settings. If there is a need to accept untrusted server certificates * > temporarily*, like during development, than this can easily be done by > providing a custom authentication provider. This was already possible > before this change, without extending the standard implementation with > insecure code. Or did I miss something? I would feel a lot better if this > whole "feature" was removed again and whoever needs to do such messy things > does them in own code in a custom authentication provider. > > Or is it just me who is overly sensitive here? What does everyone else > think? > > Peter > > > -- Kind regards Peter ----------- *Peter Schmidt* *Alfresco Software Ltd.* *UK: 07748 185496* *Int.: +44 7748 185496* *Skype: pweschmidt*
Hi Peter, I noticed the new session parameter, kCMISSessionAllowUntrustedSSLCertificate, that you introduced. If set, server certificate validation is skipped so SSL connections to untrusted servers can be established. I don't think that we should have such a parameter. The world is already insecure enough without encouraging people to deactivate essential security settings. If there is a need to accept untrusted server certificates temporarily, like during development, than this can easily be done by providing a custom authentication provider. This was already possible before this change, without extending the standard implementation with insecure code. Or did I miss something? I would feel a lot better if this whole "feature" was removed again and whoever needs to do such messy things does them in own code in a custom authentication provider. Or is it just me who is overly sensitive here? What does everyone else think? Peter
[ https://issues.apache.org/jira/browse/CMIS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Peraza updated CMIS-652:
-------------------------------
Attachment: cmis_repository_wrapper.php
Patch for cmis_repository_wrapper.php
> Method CMISService::getFolderParent() throws a fatal error
> ----------------------------------------------------------
>
> Key: CMIS-652
> URL: https://issues.apache.org/jira/browse/CMIS-652
> Project: Chemistry
> Issue Type: Bug
> Components: cmis-phplib
> Affects Versions: PHPCMIS 0.1, PHPCMIS 0.2
> Environment: Ubuntu 12.10 x64, Apache Server 2.2.22, PHP 5.4
> Reporter: Daniel Peraza
> Assignee: Richard McKnight
> Labels: patch
> Fix For: PHPCMIS 0.1, PHPCMIS 0.2
>
> Attachments: cmis_repository_wrapper.php
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> On line 852 of cmis_repository_wrapper.php, there is an invocation to {code}extractObjectEntry(){code},
which is not implemented in the class, nor its parent, which is causing a fatal error in PHP.
> It should be changed to {code}CMISRepositoryWrapper::extractObjectFeed($ret->body){code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
I'll send you a summary of the changes and prepare the website for the release. - Florian > +1, sounds good to me. > > I can probably do it over the weekend, with some overflow into next > week. > > Can someone write a little blurb for the release and update the > relevant bit of the site in staging? > > Keep you posted, > > Gab > > On 16 May 2013 12:09, Florian Müller wrote: > There haven't been any objections. I assume we have consensus. > > @Gab: Would you please run the release? > > Thanks, > > Florian > > +1 for a 0.9.0 release. > > - Gi > > On Tuesday, May 14, 2013 at 10:11 AM, Florent Guillaume wrote: > > +1 thanks for all the changes. > > Florent > > On Tue, May 14, 2013 at 4:21 PM, Florian Müller wrote: > > Hi, > > > > What do you think about releasing OpenCMIS 0.9.0? > > The CMIS 1.1 implementation is complete for all bindings. The > overall > > performance has been improved and there are no major issues. > > I think it's a good time to cut a release. > > > > - Florian > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com [4] http://www.nuxeo.org [5] +33 1 40 33 79 87 > [6] > > -- > > Gabriele Columbro | Principal Architect, Consulting Services > twitter @mindthegabz > > [7] [8] [9] [10] [11] [12] > > [13] > > [14] > > Links: > ------ > [1] mailto:fmui@apache.org > [2] mailto:fmui@apache.org > [3] mailto:fmui@apache.org > [4] http://www.nuxeo.com > [5] http://www.nuxeo.org > [6] http://webmailer.hosteurope.de/tel:%2B33%201%2040%2033%2079%2087 > [7] http://www.alfresco.com/ > [8] http://www.facebook.com/alfrescosoftware > [9] http://twitter.com/alfresco > [10] http://blogs.alfresco.com/ > [11] http://www.linkedin.com/company/alfresco > [12] http://www.youtube.com/alfresco101 > [13] http://university.alfresco.com/ACE.html > [14] http://www.youtube.com/alfresco101
+1, sounds good to me. I can probably do it over the weekend, with some overflow into next week. Can someone write a little blurb for the release and update the relevant bit of the site in staging? Keep you posted, Gab On 16 May 2013 12:09, Florian Müller <fmui@apache.org> wrote: > There haven't been any objections. I assume we have consensus. > > @Gab: Would you please run the release? > > > Thanks, > > Florian > > > +1 for a 0.9.0 release. >> >> - Gi >> >> >> On Tuesday, May 14, 2013 at 10:11 AM, Florent Guillaume wrote: >> >> +1 thanks for all the changes. >>> >>> Florent >>> >>> On Tue, May 14, 2013 at 4:21 PM, Florian Müller <fmui@apache.org(mailto: >>> fmui@apache.org)> wrote: >>> > Hi, >>> > >>> > What do you think about releasing OpenCMIS 0.9.0? >>> > The CMIS 1.1 implementation is complete for all bindings. The overall >>> > performance has been improved and there are no major issues. >>> > I think it's a good time to cut a release. >>> > >>> > - Florian >>> >>> >>> >>> -- >>> Florent Guillaume, Director of R&D, Nuxeo >>> Open Source, Java EE based, Enterprise Content Management (ECM) >>> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 >>> >>> >>> > -- Gabriele Columbro | Principal Architect, Consulting Services twitter @mindthegabz [image: Alfresco] <http://www.alfresco.com/> [image: Facebook]<http://www.facebook.com/alfrescosoftware> [image: Twitter] <http://twitter.com/alfresco> [image: Feed]<http://blogs.alfresco.com/> [image: LinkedIn] <http://www.linkedin.com/company/alfresco> [image: YouTube]<http://www.youtube.com/alfresco101> <http://university.alfresco.com/ACE.html> <http://www.youtube.com/alfresco101>
There haven't been any objections. I assume we have consensus. @Gab: Would you please run the release? Thanks, Florian > +1 for a 0.9.0 release. > > - Gi > > > On Tuesday, May 14, 2013 at 10:11 AM, Florent Guillaume wrote: > >> +1 thanks for all the changes. >> >> Florent >> >> On Tue, May 14, 2013 at 4:21 PM, Florian Müller <fmui@apache.org >> (mailto:fmui@apache.org)> wrote: >> > Hi, >> > >> > What do you think about releasing OpenCMIS 0.9.0? >> > The CMIS 1.1 implementation is complete for all bindings. The >> overall >> > performance has been improved and there are no major issues. >> > I think it's a good time to cut a release. >> > >> > - Florian >> >> >> >> -- >> Florent Guillaume, Director of R&D, Nuxeo >> Open Source, Java EE based, Enterprise Content Management (ECM) >> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 >> >>
[ https://issues.apache.org/jira/browse/CMIS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller updated CMIS-657:
--------------------------------
Fix Version/s: DotCMIS 0.6
> Memory leak in DotCMIS
> ----------------------
>
> Key: CMIS-657
> URL: https://issues.apache.org/jira/browse/CMIS-657
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.5
> Reporter: Björn
> Assignee: Florian Müller
> Fix For: DotCMIS 0.6
>
>
> I have just found a serious memory leak in dotcmis. The function "DeserializeElement"
in converter.cs is leaking. I have tried to load a type definition multiple times without
reusing the session object.(I have always created a new one.) The type definition contains
a large set of "choices". Doing so will flood the memory. The memory leak is located in the
XmlSerializer constructor. Please take a look at this article describing the issue: http://www-jo.se/f.pfleger/memoryleak
Microsofts suggestion is to reuse the XmlSerializer class or to use another constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Björn resolved CMIS-657.
------------------------
Resolution: Fixed
Bug is solved. Thank you very much Florian!
> Memory leak in DotCMIS
> ----------------------
>
> Key: CMIS-657
> URL: https://issues.apache.org/jira/browse/CMIS-657
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.5
> Reporter: Björn
> Assignee: Florian Müller
>
> I have just found a serious memory leak in dotcmis. The function "DeserializeElement"
in converter.cs is leaking. I have tried to load a type definition multiple times without
reusing the session object.(I have always created a new one.) The type definition contains
a large set of "choices". Doing so will flood the memory. The memory leak is located in the
XmlSerializer constructor. Please take a look at this article describing the issue: http://www-jo.se/f.pfleger/memoryleak
Microsofts suggestion is to reuse the XmlSerializer class or to use another constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Hi Björn, I have checked in a fix for this issue. It works here for me. Could you please verify if it solves your problem? If so, we can close the JIRA issue. Thanks, Florian > Hello, > > I have just found a serious memory leak in dotcmis. The function > "DeserializeElement" in converter.cs is leaking. I have tried to load > a type definition multiple times without reusing the session > object.(I > have always created a new one.) The type definition contains a large > set of "choices". Doing so will flood the memory. The memory leak is > located in the XmlSerializer constructor. Please take a look at this > article describing the issue: http://www-jo.se/f.pfleger/memoryleak > Microsofts suggestion is to reuse the XmlSerializer class or to use > another constructor. > > Thank You > Björn
[ https://issues.apache.org/jira/browse/CMIS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller reassigned CMIS-657:
-----------------------------------
Assignee: Florian Müller
> Memory leak in DotCMIS
> ----------------------
>
> Key: CMIS-657
> URL: https://issues.apache.org/jira/browse/CMIS-657
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.5
> Reporter: Björn
> Assignee: Florian Müller
>
> I have just found a serious memory leak in dotcmis. The function "DeserializeElement"
in converter.cs is leaking. I have tried to load a type definition multiple times without
reusing the session object.(I have always created a new one.) The type definition contains
a large set of "choices". Doing so will flood the memory. The memory leak is located in the
XmlSerializer constructor. Please take a look at this article describing the issue: http://www-jo.se/f.pfleger/memoryleak
Microsofts suggestion is to reuse the XmlSerializer class or to use another constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Björn created CMIS-657:
--------------------------
Summary: Memory leak in DotCMIS
Key: CMIS-657
URL: https://issues.apache.org/jira/browse/CMIS-657
Project: Chemistry
Issue Type: Bug
Components: dotcmis
Affects Versions: DotCMIS 0.5
Reporter: Björn
I have just found a serious memory leak in dotcmis. The function "DeserializeElement" in converter.cs
is leaking. I have tried to load a type definition multiple times without reusing the session
object.(I have always created a new one.) The type definition contains a large set of "choices".
Doing so will flood the memory. The memory leak is located in the XmlSerializer constructor.
Please take a look at this article describing the issue: http://www-jo.se/f.pfleger/memoryleak
Microsofts suggestion is to reuse the XmlSerializer class or to use another constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Hi Björn, Thanks for that hint. Please open an bug report in the Apache JIRA [1]. Thanks, Florian [1] https://issues.apache.org/jira/browse/CMIS > Hello, > > I have just found a serious memory leak in dotcmis. The function > "DeserializeElement" in converter.cs is leaking. I have tried to load > a type definition multiple times without reusing the session > object.(I > have always created a new one.) The type definition contains a large > set of "choices". Doing so will flood the memory. The memory leak is > located in the XmlSerializer constructor. Please take a look at this > article describing the issue: http://www-jo.se/f.pfleger/memoryleak > Microsofts suggestion is to reuse the XmlSerializer class or to use > another constructor. > > Thank You > Björn
Hello, I have just found a serious memory leak in dotcmis. The function "DeserializeElement" in converter.cs is leaking. I have tried to load a type definition multiple times without reusing the session object.(I have always created a new one.) The type definition contains a large set of "choices". Doing so will flood the memory. The memory leak is located in the XmlSerializer constructor. Please take a look at this article describing the issue: http://www-jo.se/f.pfleger/memoryleak Microsofts suggestion is to reuse the XmlSerializer class or to use another constructor. Thank You Björn
[ https://issues.apache.org/jira/browse/CMIS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller resolved CMIS-647.
---------------------------------
Resolution: Fixed
Fix Version/s: DotCMIS 0.6
> Exceptions when trying to access SharePoint 2013 folders
> --------------------------------------------------------
>
> Key: CMIS-647
> URL: https://issues.apache.org/jira/browse/CMIS-647
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.5
> Environment: Windows 7 Professional
> Reporter: Thomas Rogall
> Assignee: Florian Müller
> Fix For: DotCMIS 0.6
>
> Attachments: Fiddler_Raw_GetChildren.txt, screenshot-1.jpg, screenshot-2.jpg,
screenshot-3.jpg
>
>
> I am trying to retrieve objects within a SharePoint 2013 library, using "IFolder.GetChildren(…)"
> In plain libraries this is working OK. But when the SharePoint library contains folders,
the function always raises a NULL-Pointer-Exceptions.
> After removing all folders from the SharePoint library the function works correct again.
> The NULL pointer exception is caused in "binding-caches.cs", line 220, see stacktrace
below.
> Note 1: Using the CMIS Workbench (same connection parameters and same credentials) documents
AND folders are listed correctly (!)
> Note 2: I already tried to add some code which simply avoids NULL-arguments. This does
NOT help, just an empty result will be returned.
> Note 3: A similar behavior occurs when trying to access objects using "ISession.GetObjectByPath()"
--> rootFolder and documents are OK, subfolders will raise exceptions.
> Sample output from my test program:
> Path '/' --> Folder: Meine erste Bibliothek
> Path '/NOTEBOOK.JPG' --> Picture: NOTEBOOK.JPG
> Path '/AAA' --> EXCEPTION: Received Atom entry is not a CMIS entry!
> Path '/AAA/' --> EXCEPTION: Received Atom entry is not a CMIS entry!
> Path '/AAA/BBB' --> EXCEPTION: Received Atom entry is not a CMIS entry!
> Path '/AAA/BBB/JUDGESCH.GIF' --> Document: JUDGESCH.GIF
> Stacktrace:
> bei System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument argument)
> bei System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
> bei System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
> bei DotCMIS.Util.LRUCache`2.Remove(K key) in C:\EIS\CMIS\Chemistry\src\util.cs:Zeile
104.
> bei DotCMIS.Binding.LruCacheLevel.Remove(String key) in C:\EIS\CMIS\Chemistry\src\binding\binding-caches.cs:Zeile
551.
> bei DotCMIS.Binding.Cache.Remove(String[] keys) in C:\EIS\CMIS\Chemistry\src\binding\binding-caches.cs:Zeile
220.
> bei DotCMIS.Binding.AtomPub.LinkCache.RemoveLinks(String repositoryId, String id)
in C:\EIS\CMIS\Chemistry\src\binding\atompub\atompub-linkcache.cs:Zeile 126.
> bei DotCMIS.Binding.AtomPub.AbstractAtomPubService.RemoveLinks(String repositoryId,
String id) in C:\EIS\CMIS\Chemistry\src\binding\atompub\atompub.cs:Zeile 199.
> bei DotCMIS.Binding.AtomPub.NavigationService.GetChildren(String repositoryId, String
folderId, String filter, String orderBy, Nullable`1 includeAllowableActions, Nullable`1 includeRelationships,
String renditionFilter, Nullable`1 includePathSegment, Nullable`1 maxItems, Nullable`1 skipCount,
IExtensionsData extension) in C:\EIS\CMIS\Chemistry\src\binding\atompub\atompub.cs:Zeile 1080.
> bei DotCMIS.Client.Impl.Folder.<>c__DisplayClass4.<GetChildren>b__3(Int64
maxNumItems, Int64 skipCount) in C:\EIS\CMIS\Chemistry\src\client\client-objects.cs:Zeile
1252.
> bei DotCMIS.Client.Impl.PageFetcher`1.FetchNextPage(Int64 skipCount) in C:\EIS\CMIS\Chemistry\src\client\client-utils.cs:Zeile
563.
> bei DotCMIS.Client.Impl.AbstractEnumerator`1.GetCurrentPage() in C:\EIS\CMIS\Chemistry\src\client\client-utils.cs:Zeile
528.
> bei DotCMIS.Client.Impl.CollectionEnumerator`1.MoveNext() in C:\EIS\CMIS\Chemistry\src\client\client-utils.cs:Zeile
608.
> bei TestClient.MainForm.DumpRepository(ISession session) in C:\EIS\CMIS\Chemistry\TestClient\MainForm.cs:Zeile
139.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller resolved CMIS-649.
---------------------------------
Resolution: Fixed
Fix Version/s: DotCMIS 0.5
Assignee: Florian Müller
> NTLM over HTTP authentication
> -----------------------------
>
> Key: CMIS-649
> URL: https://issues.apache.org/jira/browse/CMIS-649
> Project: Chemistry
> Issue Type: Improvement
> Components: dotcmis
> Environment: SharePoint 2013 with NTLM over HTTP authentication
> Reporter: Nicolas Raoul
> Assignee: Florian Müller
> Fix For: DotCMIS 0.5
>
>
> Implement NTLM over HTTP authentication.
> Same for OpenCMIS-client: https://issues.apache.org/jira/browse/CMIS-648
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller resolved CMIS-632.
---------------------------------
Resolution: Fixed
Assignee: Florian Müller
> SetContentStream issue
> ----------------------
>
> Key: CMIS-632
> URL: https://issues.apache.org/jira/browse/CMIS-632
> Project: Chemistry
> Issue Type: Bug
> Components: dotcmis
> Affects Versions: DotCMIS 0.5
> Environment: Windows
> Reporter: Yannick MOLINET
> Assignee: Florian Müller
> Priority: Blocker
> Fix For: DotCMIS 0.6
>
>
> I have a strange issue when I try to update more files with SetContentStream.
> First file is correctly updated, but second is block and wait for SetContentStream End.
> This occur only on second update and occur when the new contentstream is read by Refresh().
If I call SetContentStream without refresh, I'm blocked when I try to update properties (for
example).
> In debug, I could see that the wait occur on AbstractAtomPubService.GetObjectInternal()
when
> HttpUtils.Response resp = Read(url); is called. This method call httputils.Invoke, the
wait occur on HttpWebResponse response = (HttpWebResponse)conn.GetResponse();
> Thanks for help,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
+1 for a 0.9.0 release. - Gi On Tuesday, May 14, 2013 at 10:11 AM, Florent Guillaume wrote: > +1 thanks for all the changes. > > Florent > > On Tue, May 14, 2013 at 4:21 PM, Florian Müller <fmui@apache.org (mailto:fmui@apache.org)> wrote: > > Hi, > > > > What do you think about releasing OpenCMIS 0.9.0? > > The CMIS 1.1 implementation is complete for all bindings. The overall > > performance has been improved and there are no major issues. > > I think it's a good time to cut a release. > > > > - Florian > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > >
+1 thanks for all the changes. Florent On Tue, May 14, 2013 at 4:21 PM, Florian Müller <fmui@apache.org> wrote: > Hi, > > What do you think about releasing OpenCMIS 0.9.0? > The CMIS 1.1 implementation is complete for all bindings. The overall > performance has been improved and there are no major issues. > I think it's a good time to cut a release. > > - Florian > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
[ https://issues.apache.org/jira/browse/CMIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657145#comment-13657145
]
Florian Müller commented on CMIS-621:
-------------------------------------
It's kind of there. If a servlet filter in front of OpenCMIS adds the servlet attribute "org.apache.chemistry.opencmis.baseurl"
and provides the base URL, OpenCMIS uses this URL to generate URLs in CMIS responses.
What OpenCMIS doesn't provide at the moment is such a filter. But the implementation is trivial
if you know how to construct a specific base URL.
What's also missing is documentation...
> Context and servlet path can not be overridden when using a reverse proxy
> -------------------------------------------------------------------------
>
> Key: CMIS-621
> URL: https://issues.apache.org/jira/browse/CMIS-621
> Project: Chemistry
> Issue Type: Improvement
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.8.0
> Reporter: Gavin Cornwell
> Assignee: Florian Müller
>
> CMIS-500 introduced a filter to allow the AtomPub binding to be used with a reverse proxy
but the context and servlet paths can not be configured.
> If the app server is using a path of /app/cmisatom the proxy also has to.
> Ideally it would be possible to rewrite the path as well as the host etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13657127#comment-13657127
]
Mike Hatfield commented on CMIS-621:
------------------------------------
Florian - where are we with this issue please? Can we get this into 0.9.0?
> Context and servlet path can not be overridden when using a reverse proxy
> -------------------------------------------------------------------------
>
> Key: CMIS-621
> URL: https://issues.apache.org/jira/browse/CMIS-621
> Project: Chemistry
> Issue Type: Improvement
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.8.0
> Reporter: Gavin Cornwell
> Assignee: Florian Müller
>
> CMIS-500 introduced a filter to allow the AtomPub binding to be used with a reverse proxy
but the context and servlet paths can not be configured.
> If the app server is using a path of /app/cmisatom the proxy also has to.
> Ideally it would be possible to rewrite the path as well as the host etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller resolved CMIS-655.
---------------------------------
Resolution: Fixed
Fix Version/s: OpenCMIS 0.9.0
> Chunked transfer encoding effectively disables browser caching
> --------------------------------------------------------------
>
> Key: CMIS-655
> URL: https://issues.apache.org/jira/browse/CMIS-655
> Project: Chemistry
> Issue Type: Improvement
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.9.0 beta 1
> Reporter: Carlo Sciolla
> Fix For: OpenCMIS 0.9.0
>
>
> OpenCMIS never sets the Content-length on HTTP responses, letting the app server use
the default strategy of sending them with a "Transfer-encoding: chunked" header.
> While it's valid HTTP 1.1, it's not fully supported by e.g. some browsers and cache middleware,
which handle such responses fine but fail to cache them.
> Please provide to either set the content-length at least in the getContentStream calls,
or allow users to hook into the HTTP serialization process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[ https://issues.apache.org/jira/browse/CMIS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Müller resolved CMIS-656.
---------------------------------
Resolution: Fixed
Fix Version/s: OpenCMIS 0.9.0
> Provide extension points for the protocol handling logic
> --------------------------------------------------------
>
> Key: CMIS-656
> URL: https://issues.apache.org/jira/browse/CMIS-656
> Project: Chemistry
> Issue Type: Improvement
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.9.0 beta 1
> Reporter: Carlo Sciolla
> Fix For: OpenCMIS 0.9.0
>
> Attachments: noreflection.patch
>
>
> Chemistry takes full control over the serialization process, including all details of
the underlying HTTP communication. Extension points or APIs in this process would allow implementors
to leverage greater flexibility to fine tune the serialization process, or to implement extensions
over the standard CMIS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
2013/5/14 Florian Müller <fmui@apache.org> > Can we close CMIS-656 then? Sure, go ahead! c. -- Carlo Sciolla --==(A)==-- Linux User #372086 My personal blog: http://www.skuro.tk Follow me on twitter: http://twitter.com/skuro <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro <http://github.com/skuro>My LinkedIn profile: http://nl.linkedin.com/in/carlosciolla --==(A)==-- Product Lead at Backbase - Next Generation Portal Software for Financials & Large Enterprises (http://www.backbase.com)
+1 to go for another release... Jens On 14.05.13 16:21, "Florian Müller" <fmui@apache.org> wrote: > Hi, > > What do you think about releasing OpenCMIS 0.9.0? > The CMIS 1.1 implementation is complete for all bindings. The overall > performance has been improved and there are no major issues. > I think it's a good time to cut a release. > > - Florian >
Can we close CMIS-656 then? - Florian > Hi Florian, > > I just reviewed the code, and I think it's quite a great leap forward > :-) > It includes everything we discussed above. > > Thanks for the quick roundtrip, > c.
Hi Florian, I just reviewed the code, and I think it's quite a great leap forward :-) It includes everything we discussed above. Thanks for the quick roundtrip, c.
Hi, What do you think about releasing OpenCMIS 0.9.0? The CMIS 1.1 implementation is complete for all bindings. The overall performance has been improved and there are no major issues. I think it's a good time to cut a release. - Florian
Hi Carlo, I have refactored the server code. Please have a look. - Florian > Hi Florian, > > the core of my change isn't in the Dispatcher itself. Discarding final > classes, private constructors and static methods is the main objective > of that change, as it basically enable class inheritance. Pluggability > of different behavior can indeed be achieved by exposing the Dispatcher, > but it would still be using the reflection over static methods combo as > before, which alone breaks four out of five features of OO > <http://en.wikipedia.org/wiki/Object-oriented_programming>[1]. > > On the runtime efficiency, I'd be happy to store some 100 more class > definition if that will spare some CPU cycles due to reflection. We're > talking of one-off tiny memory allocation VS tiny performance > degradation per every single call here. > > c. > > [1] please don't take me for an OO fanatic, I'm much more of a FP guy > these days. I just think that OO is better than procedural, especially > on an OO platforms such as Java > > > 2013/5/10 Florian Müller <fmui@apache.org <mailto:fmui@apache.org>> > > Got it. I thought you were heading in a different direction. > > How is that different from making the current Dispatch object > protected or adding a protected method that wraps the > Dispatch.addResource() method? > > Extensibility-wise they would be equal. Your version only adds a bit > more syntactic sugar. It would also need a bit more memory because > we would have to add about 100 additional classes (AtomPub + > Browser) and runtime objects. > > - Florian > > > Is it next week already? :-) > > Jokes apart, I had one hour to spare for this topic now that > it's still > hot, and produced the patch you can see attached to > CMIS-656<https://issues.__apache.org/jira/browse/CMIS-__656 > <https://issues.apache.org/jira/browse/CMIS-656>>. > > That's a translation of the current Chemistry dispatch logic to > abandon > reflection, static methods, private constructors, and final classes. > > The flow is quite the same as before, with the servlet > initialization logic > registering the default bindings by adding concrete instances of a > ServiceCall interface into a local registry. At request serving > time the > registered ServiceCall is retrieved and its service() method > invoked. The > invocation logic is now a mere INVOKEINTERFACE JVM instruction > instead of > the previous reflection trick (tiny performance improvement here). > > Please note that the ServiceCall interface was already a hidden > contract > that all service calls had to implement to be addressable by the > Method > created by the Dispatcher. > > As a last note, CmisAtomPubServlet also exposes a protected > registerDispatch(resource, method, ServiceCall) to allow > implementors to > override the default logic. > > That's it for now. Please note that as the Dispatcher is shared > across the > AtomPub and Browser bindings, and as only the AtomPub was properly > refactored, that patch will break your build. > > Looking forward to hear your comments, > c. > > > 2013/5/10 Carlo Sciolla<carlo.sciolla@gmail.__com > <mailto:carlo.sciolla@gmail.com>> > > Hi Florian, > > will do, I'll hopefully have a patch for you to review next > week. > > c. > > > 2013/5/10 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > Please go ahead and make a proposal. Submit a patch that > sketches your > ideas. It doesn't have to be complete and running. > It's easier to talk about something concrete rather than > discussing about > generic topics. > > - Florian > > > > Hi Florian, > > it's not my intent to start a flame war, and we can > continue offline if > you > want. To the interest of the list, I'll just write > here some of the > reasons > behind my previous comment, and wait until I have > some patch ready to > prove > my points before bothering you guys again with my > ramblings. > > I understand your remark on the spec compliance, and > that interop is at > stake when you allow the protocol details to be > modified. BUT... > > - There's much more to HTTP than what CMIS > specifies, and Chemistry is > currently in charge of handling the transport > protocol on top of which > CMIS > expresses itself. > > - No extensibility means that backporting of fixes > might be a no-go. For > example, if I now upgrade Chemistry to the latest > trunk my code doesn't > compile anymore. Subclassing would be the best way > to integrate your > changes in the version I use, but that's not > available to me. > > - The CMIS spec is (hopefully!) not fixed and will > evolve with time. OO > could help greatly e.g. to support different > versions of the protocol > with > a single serve instance, which is painful to > implement cleanly following > the current code approach. > > - Spec extensions are not evil per se. While they > might indeed break > interoperability, they're also a way to open the > protocol itself to > experiments and eventually drive a community based > evolution of it. > > - Interop is not always the top priority. CMIS and > Chemistry provide a > lot > of value OOTB, and I don't see why proprietary > extensions should be > denied > by principle. Why shouldn't I have the possibility > to write a custom > extension to improve e.g. content delivery capabilities > (getContentStreamByPath, anyone?), while still > retaining full protocol > compliance for B2B data exchange? > > If you made it to here, a big thank you for your > patience. > > Hope this helps, > c. > > > > > 2013/5/8 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > This code is not meant to be extensible. The > CMIS standard is fixed. > There > will be no additional services or operations. > Also, the semantics of the > parameters will not change or have to be > changed. Any extensions would > bypass the specification, which would be a pain > for clients and doesn't > help interoperability. > All methods that handle requests are stateless, > isolated pieces of code. > OO doesn't help here. And the alternative to > reflections would be a 120 > lines if-statement. I can't see the advantage of > that. > > Also, this part is considered internal code and > may change at any time. > OpenCMIS provides a lot of extensibility on the > client side and keeping > the > interfaces compatible does hurt sometimes. I > don't see a real use case > to > have that pain also on the server side. If there > is something missing or > wrong, we usually fix it pretty quick - as you > have seen. > > Having said that, if you have a great idea how > to refactor that code, > feel > free to provide a patch. > > > - Florian > > > Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb > Carlo Sciolla< > carlo.sciolla@gmail.com > <mailto:carlo.sciolla@gmail.com>>: > > Hi Florian, > > thanks for your quick commit, I will > experiment a bit with it and let > you > know what comes out of it. I do already have > some initial comments > anyway: > > - I see you only addressed the browser > bindings implementation. While I > can > see the reason behind it, I think it won't > hurt to also apply a similar > logic to the AtomPub binding > > - as I'm stuck with v0.6.0, I'm looking into > ways to backport or > integrate > your code in my app. The current logic for > method dispatch in AtomPub > goes > against extensibility (and some object > oriented design principles, IMO) > and > while for the time being I can work around > it, would you guys consider > refactoring the dispatch logic to make use > of non-final classes / no > reflection / public constructors? > > Thanks, > c. > > > 2013/5/8 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > I've added some new code. There are now > three interfaces that let you > control the server headers. > The ContentStream object that is > returned by getContentStream() must > implement the interface(s) to trigger > the behavior: > > ContentLengthContentStream - Sets the > Content-Length header and turns > chunking off. > > LastModifiedContentStream - Sets the > Last-Modified header and respects > the > If-Modified-Since header. > > CacheHeaderContentStream - Sets the > Cache-Control header, the Expires > header, and the ETag header and respects > the If-None-Match header. > > > Please let me know if that works for you. > > > - Florian > > > Hi there, sorry for the late reply. > > > 2013/5/7 Florian > Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > That is surprising. Chunked > encoding isn't really exotic. > > > Definitely, but browsers are > always there to remind us that world > class > > standards are nothing > different from regional social > conventions, > > are > they? > > > Could you please open an > Improvement issue and add a few details. > I'll > > look into it. > > Thanks, here it > is<https://issues.apache.org/*__***** > <https://issues.apache.org/******><https://issues.apache.__org/**** > <https://issues.apache.org/****>> > > jira/browse/CMIS-655<https://*__*issues.apache.org/**jira/** > <http://issues.apache.org/**jira/**> > browse/CMIS-655<https://__issues.apache.org/**jira/__browse/CMIS-655 > <https://issues.apache.org/**jira/browse/CMIS-655>>> > > <https://**issues.apache.org/*__*jira/browse/**CMIS-655 > <http://issues.apache.org/**jira/browse/**CMIS-655><http:/__/issues.apache.org/jira/__browse/**CMIS-655 > <http://issues.apache.org/jira/browse/**CMIS-655>> > <https:/**/issues.apache.org/__jira/**browse/CMIS-655 > <http://issues.apache.org/jira/**browse/CMIS-655><https:/__/issues.apache.org/jira/__browse/CMIS-655 > <https://issues.apache.org/jira/browse/CMIS-655>> > > > >. > > > > > > -- > Carlo Sciolla > > --==(A)==-- > Linux User #372086 > My personal blog: http://www.skuro.tk > Follow me on twitter: http://twitter.com/skuro > <http://twitter.com/skuro>Fork me on Github: > http://github.com/skuro > <http://github.com/skuro>My LinkedIn profile: > http://nl.linkedin.com/in/__carlosciolla > <http://nl.linkedin.com/in/carlosciolla> > --==(A)==-- > > Product Lead at Backbase - Next Generation Portal Software > for Financials > & Large Enterprises (http://www.backbase.com) > > > > > > > > > -- > Carlo Sciolla > > --==(A)==-- > Linux User #372086 > My personal blog: http://www.skuro.tk > Follow me on twitter: http://twitter.com/skuro > <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro > <http://github.com/skuro>My LinkedIn profile: > http://nl.linkedin.com/in/carlosciolla > --==(A)==-- > > Product Lead at Backbase - Next Generation Portal Software for > Financials & Large Enterprises (http://www.backbase.com)
Hi Carlo, I understand what you are saying. But there are no objects here. My first version of this servlet had all methods (that were implemented at that time) in the servlet class. The original idea of the Dispatcher was only to move the code out of the servlet class. But let me play with a few things here. I'll get back to you. - Florian > Hi Florian, > > the core of my change isn't in the Dispatcher itself. Discarding final > classes, private constructors and static methods is the main objective > of that change, as it basically enable class inheritance. Pluggability > of different behavior can indeed be achieved by exposing the Dispatcher, > but it would still be using the reflection over static methods combo as > before, which alone breaks four out of five features of OO > <http://en.wikipedia.org/wiki/Object-oriented_programming>[1]. > > On the runtime efficiency, I'd be happy to store some 100 more class > definition if that will spare some CPU cycles due to reflection. We're > talking of one-off tiny memory allocation VS tiny performance > degradation per every single call here. > > c. > > [1] please don't take me for an OO fanatic, I'm much more of a FP guy > these days. I just think that OO is better than procedural, especially > on an OO platforms such as Java > > > 2013/5/10 Florian Müller <fmui@apache.org <mailto:fmui@apache.org>> > > Got it. I thought you were heading in a different direction. > > How is that different from making the current Dispatch object > protected or adding a protected method that wraps the > Dispatch.addResource() method? > > Extensibility-wise they would be equal. Your version only adds a bit > more syntactic sugar. It would also need a bit more memory because > we would have to add about 100 additional classes (AtomPub + > Browser) and runtime objects. > > - Florian > > > Is it next week already? :-) > > Jokes apart, I had one hour to spare for this topic now that > it's still > hot, and produced the patch you can see attached to > CMIS-656<https://issues.__apache.org/jira/browse/CMIS-__656 > <https://issues.apache.org/jira/browse/CMIS-656>>. > > That's a translation of the current Chemistry dispatch logic to > abandon > reflection, static methods, private constructors, and final classes. > > The flow is quite the same as before, with the servlet > initialization logic > registering the default bindings by adding concrete instances of a > ServiceCall interface into a local registry. At request serving > time the > registered ServiceCall is retrieved and its service() method > invoked. The > invocation logic is now a mere INVOKEINTERFACE JVM instruction > instead of > the previous reflection trick (tiny performance improvement here). > > Please note that the ServiceCall interface was already a hidden > contract > that all service calls had to implement to be addressable by the > Method > created by the Dispatcher. > > As a last note, CmisAtomPubServlet also exposes a protected > registerDispatch(resource, method, ServiceCall) to allow > implementors to > override the default logic. > > That's it for now. Please note that as the Dispatcher is shared > across the > AtomPub and Browser bindings, and as only the AtomPub was properly > refactored, that patch will break your build. > > Looking forward to hear your comments, > c. > > > 2013/5/10 Carlo Sciolla<carlo.sciolla@gmail.__com > <mailto:carlo.sciolla@gmail.com>> > > Hi Florian, > > will do, I'll hopefully have a patch for you to review next > week. > > c. > > > 2013/5/10 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > Please go ahead and make a proposal. Submit a patch that > sketches your > ideas. It doesn't have to be complete and running. > It's easier to talk about something concrete rather than > discussing about > generic topics. > > - Florian > > > > Hi Florian, > > it's not my intent to start a flame war, and we can > continue offline if > you > want. To the interest of the list, I'll just write > here some of the > reasons > behind my previous comment, and wait until I have > some patch ready to > prove > my points before bothering you guys again with my > ramblings. > > I understand your remark on the spec compliance, and > that interop is at > stake when you allow the protocol details to be > modified. BUT... > > - There's much more to HTTP than what CMIS > specifies, and Chemistry is > currently in charge of handling the transport > protocol on top of which > CMIS > expresses itself. > > - No extensibility means that backporting of fixes > might be a no-go. For > example, if I now upgrade Chemistry to the latest > trunk my code doesn't > compile anymore. Subclassing would be the best way > to integrate your > changes in the version I use, but that's not > available to me. > > - The CMIS spec is (hopefully!) not fixed and will > evolve with time. OO > could help greatly e.g. to support different > versions of the protocol > with > a single serve instance, which is painful to > implement cleanly following > the current code approach. > > - Spec extensions are not evil per se. While they > might indeed break > interoperability, they're also a way to open the > protocol itself to > experiments and eventually drive a community based > evolution of it. > > - Interop is not always the top priority. CMIS and > Chemistry provide a > lot > of value OOTB, and I don't see why proprietary > extensions should be > denied > by principle. Why shouldn't I have the possibility > to write a custom > extension to improve e.g. content delivery capabilities > (getContentStreamByPath, anyone?), while still > retaining full protocol > compliance for B2B data exchange? > > If you made it to here, a big thank you for your > patience. > > Hope this helps, > c. > > > > > 2013/5/8 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > This code is not meant to be extensible. The > CMIS standard is fixed. > There > will be no additional services or operations. > Also, the semantics of the > parameters will not change or have to be > changed. Any extensions would > bypass the specification, which would be a pain > for clients and doesn't > help interoperability. > All methods that handle requests are stateless, > isolated pieces of code. > OO doesn't help here. And the alternative to > reflections would be a 120 > lines if-statement. I can't see the advantage of > that. > > Also, this part is considered internal code and > may change at any time. > OpenCMIS provides a lot of extensibility on the > client side and keeping > the > interfaces compatible does hurt sometimes. I > don't see a real use case > to > have that pain also on the server side. If there > is something missing or > wrong, we usually fix it pretty quick - as you > have seen. > > Having said that, if you have a great idea how > to refactor that code, > feel > free to provide a patch. > > > - Florian > > > Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb > Carlo Sciolla< > carlo.sciolla@gmail.com > <mailto:carlo.sciolla@gmail.com>>: > > Hi Florian, > > thanks for your quick commit, I will > experiment a bit with it and let > you > know what comes out of it. I do already have > some initial comments > anyway: > > - I see you only addressed the browser > bindings implementation. While I > can > see the reason behind it, I think it won't > hurt to also apply a similar > logic to the AtomPub binding > > - as I'm stuck with v0.6.0, I'm looking into > ways to backport or > integrate > your code in my app. The current logic for > method dispatch in AtomPub > goes > against extensibility (and some object > oriented design principles, IMO) > and > while for the time being I can work around > it, would you guys consider > refactoring the dispatch logic to make use > of non-final classes / no > reflection / public constructors? > > Thanks, > c. > > > 2013/5/8 Florian Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > Hi Carlo, > > I've added some new code. There are now > three interfaces that let you > control the server headers. > The ContentStream object that is > returned by getContentStream() must > implement the interface(s) to trigger > the behavior: > > ContentLengthContentStream - Sets the > Content-Length header and turns > chunking off. > > LastModifiedContentStream - Sets the > Last-Modified header and respects > the > If-Modified-Since header. > > CacheHeaderContentStream - Sets the > Cache-Control header, the Expires > header, and the ETag header and respects > the If-None-Match header. > > > Please let me know if that works for you. > > > - Florian > > > Hi there, sorry for the late reply. > > > 2013/5/7 Florian > Müller<fmui@apache.org > <mailto:fmui@apache.org>> > > That is surprising. Chunked > encoding isn't really exotic. > > > Definitely, but browsers are > always there to remind us that world > class > > standards are nothing > different from regional social > conventions, > > are > they? > > > Could you please open an > Improvement issue and add a few details. > I'll > > look into it. > > Thanks, here it > is<https://issues.apache.org/*__***** > <https://issues.apache.org/******><https://issues.apache.__org/**** > <https://issues.apache.org/****>> > > jira/browse/CMIS-655<https://*__*issues.apache.org/**jira/** > <http://issues.apache.org/**jira/**> > browse/CMIS-655<https://__issues.apache.org/**jira/__browse/CMIS-655 > <https://issues.apache.org/**jira/browse/CMIS-655>>> > > <https://**issues.apache.org/*__*jira/browse/**CMIS-655 > <http://issues.apache.org/**jira/browse/**CMIS-655><http:/__/issues.apache.org/jira/__browse/**CMIS-655 > <http://issues.apache.org/jira/browse/**CMIS-655>> > <https:/**/issues.apache.org/__jira/**browse/CMIS-655 > <http://issues.apache.org/jira/**browse/CMIS-655><https:/__/issues.apache.org/jira/__browse/CMIS-655 > <https://issues.apache.org/jira/browse/CMIS-655>> > > > >. > > > > > > -- > Carlo Sciolla > > --==(A)==-- > Linux User #372086 > My personal blog: http://www.skuro.tk > Follow me on twitter: http://twitter.com/skuro > <http://twitter.com/skuro>Fork me on Github: > http://github.com/skuro > <http://github.com/skuro>My LinkedIn profile: > http://nl.linkedin.com/in/__carlosciolla > <http://nl.linkedin.com/in/carlosciolla> > --==(A)==-- > > Product Lead at Backbase - Next Generation Portal Software > for Financials > & Large Enterprises (http://www.backbase.com) > > > > > > > > > -- > Carlo Sciolla > > --==(A)==-- > Linux User #372086 > My personal blog: http://www.skuro.tk > Follow me on twitter: http://twitter.com/skuro > <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro > <http://github.com/skuro>My LinkedIn profile: > http://nl.linkedin.com/in/carlosciolla > --==(A)==-- > > Product Lead at Backbase - Next Generation Portal Software for > Financials & Large Enterprises (http://www.backbase.com)
Hi Florian, the core of my change isn't in the Dispatcher itself. Discarding final classes, private constructors and static methods is the main objective of that change, as it basically enable class inheritance. Pluggability of different behavior can indeed be achieved by exposing the Dispatcher, but it would still be using the reflection over static methods combo as before, which alone breaks four out of five features of OO<http://en.wikipedia.org/wiki/Object-oriented_programming> [1]. On the runtime efficiency, I'd be happy to store some 100 more class definition if that will spare some CPU cycles due to reflection. We're talking of one-off tiny memory allocation VS tiny performance degradation per every single call here. c. [1] please don't take me for an OO fanatic, I'm much more of a FP guy these days. I just think that OO is better than procedural, especially on an OO platforms such as Java 2013/5/10 Florian Müller <fmui@apache.org> > Got it. I thought you were heading in a different direction. > > How is that different from making the current Dispatch object protected or > adding a protected method that wraps the Dispatch.addResource() method? > > Extensibility-wise they would be equal. Your version only adds a bit more > syntactic sugar. It would also need a bit more memory because we would have > to add about 100 additional classes (AtomPub + Browser) and runtime objects. > > - Florian > > > Is it next week already? :-) >> >> Jokes apart, I had one hour to spare for this topic now that it's still >> hot, and produced the patch you can see attached to >> CMIS-656<https://issues.**apache.org/jira/browse/CMIS-**656<https://issues.apache.org/jira/browse/CMIS-656> >> >. >> >> That's a translation of the current Chemistry dispatch logic to abandon >> reflection, static methods, private constructors, and final classes. >> >> The flow is quite the same as before, with the servlet initialization >> logic >> registering the default bindings by adding concrete instances of a >> ServiceCall interface into a local registry. At request serving time the >> registered ServiceCall is retrieved and its service() method invoked. The >> invocation logic is now a mere INVOKEINTERFACE JVM instruction instead of >> the previous reflection trick (tiny performance improvement here). >> >> Please note that the ServiceCall interface was already a hidden contract >> that all service calls had to implement to be addressable by the Method >> created by the Dispatcher. >> >> As a last note, CmisAtomPubServlet also exposes a protected >> registerDispatch(resource, method, ServiceCall) to allow implementors to >> override the default logic. >> >> That's it for now. Please note that as the Dispatcher is shared across the >> AtomPub and Browser bindings, and as only the AtomPub was properly >> refactored, that patch will break your build. >> >> Looking forward to hear your comments, >> c. >> >> >> 2013/5/10 Carlo Sciolla<carlo.sciolla@gmail.**com<carlo.sciolla@gmail.com> >> > >> >> Hi Florian, >>> >>> will do, I'll hopefully have a patch for you to review next week. >>> >>> c. >>> >>> >>> 2013/5/10 Florian Müller<fmui@apache.org> >>> >>> Hi Carlo, >>>> >>>> Please go ahead and make a proposal. Submit a patch that sketches your >>>> ideas. It doesn't have to be complete and running. >>>> It's easier to talk about something concrete rather than discussing >>>> about >>>> generic topics. >>>> >>>> - Florian >>>> >>>> >>>> >>>> Hi Florian, >>>> >>>>> it's not my intent to start a flame war, and we can continue offline if >>>>> you >>>>> want. To the interest of the list, I'll just write here some of the >>>>> reasons >>>>> behind my previous comment, and wait until I have some patch ready to >>>>> prove >>>>> my points before bothering you guys again with my ramblings. >>>>> >>>>> I understand your remark on the spec compliance, and that interop is at >>>>> stake when you allow the protocol details to be modified. BUT... >>>>> >>>>> - There's much more to HTTP than what CMIS specifies, and Chemistry is >>>>> currently in charge of handling the transport protocol on top of which >>>>> CMIS >>>>> expresses itself. >>>>> >>>>> - No extensibility means that backporting of fixes might be a no-go. >>>>> For >>>>> example, if I now upgrade Chemistry to the latest trunk my code doesn't >>>>> compile anymore. Subclassing would be the best way to integrate your >>>>> changes in the version I use, but that's not available to me. >>>>> >>>>> - The CMIS spec is (hopefully!) not fixed and will evolve with time. OO >>>>> could help greatly e.g. to support different versions of the protocol >>>>> with >>>>> a single serve instance, which is painful to implement cleanly >>>>> following >>>>> the current code approach. >>>>> >>>>> - Spec extensions are not evil per se. While they might indeed break >>>>> interoperability, they're also a way to open the protocol itself to >>>>> experiments and eventually drive a community based evolution of it. >>>>> >>>>> - Interop is not always the top priority. CMIS and Chemistry provide a >>>>> lot >>>>> of value OOTB, and I don't see why proprietary extensions should be >>>>> denied >>>>> by principle. Why shouldn't I have the possibility to write a custom >>>>> extension to improve e.g. content delivery capabilities >>>>> (getContentStreamByPath, anyone?), while still retaining full protocol >>>>> compliance for B2B data exchange? >>>>> >>>>> If you made it to here, a big thank you for your patience. >>>>> >>>>> Hope this helps, >>>>> c. >>>>> >>>>> >>>>> >>>>> >>>>> 2013/5/8 Florian Müller<fmui@apache.org> >>>>> >>>>> Hi Carlo, >>>>> >>>>>> This code is not meant to be extensible. The CMIS standard is fixed. >>>>>> There >>>>>> will be no additional services or operations. Also, the semantics of >>>>>> the >>>>>> parameters will not change or have to be changed. Any extensions would >>>>>> bypass the specification, which would be a pain for clients and >>>>>> doesn't >>>>>> help interoperability. >>>>>> All methods that handle requests are stateless, isolated pieces of >>>>>> code. >>>>>> OO doesn't help here. And the alternative to reflections would be a >>>>>> 120 >>>>>> lines if-statement. I can't see the advantage of that. >>>>>> >>>>>> Also, this part is considered internal code and may change at any >>>>>> time. >>>>>> OpenCMIS provides a lot of extensibility on the client side and >>>>>> keeping >>>>>> the >>>>>> interfaces compatible does hurt sometimes. I don't see a real use case >>>>>> to >>>>>> have that pain also on the server side. If there is something missing >>>>>> or >>>>>> wrong, we usually fix it pretty quick - as you have seen. >>>>>> >>>>>> Having said that, if you have a great idea how to refactor that code, >>>>>> feel >>>>>> free to provide a patch. >>>>>> >>>>>> >>>>>> - Florian >>>>>> >>>>>> >>>>>> Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb Carlo Sciolla< >>>>>> carlo.sciolla@gmail.com>: >>>>>> >>>>>> Hi Florian, >>>>>> >>>>>>> thanks for your quick commit, I will experiment a bit with it and let >>>>>>> you >>>>>>> know what comes out of it. I do already have some initial comments >>>>>>> anyway: >>>>>>> >>>>>>> - I see you only addressed the browser bindings implementation. >>>>>>> While I >>>>>>> can >>>>>>> see the reason behind it, I think it won't hurt to also apply a >>>>>>> similar >>>>>>> logic to the AtomPub binding >>>>>>> >>>>>>> - as I'm stuck with v0.6.0, I'm looking into ways to backport or >>>>>>> integrate >>>>>>> your code in my app. The current logic for method dispatch in AtomPub >>>>>>> goes >>>>>>> against extensibility (and some object oriented design principles, >>>>>>> IMO) >>>>>>> and >>>>>>> while for the time being I can work around it, would you guys >>>>>>> consider >>>>>>> refactoring the dispatch logic to make use of non-final classes / no >>>>>>> reflection / public constructors? >>>>>>> >>>>>>> Thanks, >>>>>>> c. >>>>>>> >>>>>>> >>>>>>> 2013/5/8 Florian Müller<fmui@apache.org> >>>>>>> >>>>>>> Hi Carlo, >>>>>>> >>>>>>> I've added some new code. There are now three interfaces that let >>>>>>>> you >>>>>>>> control the server headers. >>>>>>>> The ContentStream object that is returned by getContentStream() must >>>>>>>> implement the interface(s) to trigger the behavior: >>>>>>>> >>>>>>>> ContentLengthContentStream - Sets the Content-Length header and >>>>>>>> turns >>>>>>>> chunking off. >>>>>>>> >>>>>>>> LastModifiedContentStream - Sets the Last-Modified header and >>>>>>>> respects >>>>>>>> the >>>>>>>> If-Modified-Since header. >>>>>>>> >>>>>>>> CacheHeaderContentStream - Sets the Cache-Control header, the >>>>>>>> Expires >>>>>>>> header, and the ETag header and respects the If-None-Match header. >>>>>>>> >>>>>>>> >>>>>>>> Please let me know if that works for you. >>>>>>>> >>>>>>>> >>>>>>>> - Florian >>>>>>>> >>>>>>>> >>>>>>>> Hi there, sorry for the late reply. >>>>>>>> >>>>>>>> >>>>>>>> 2013/5/7 Florian Müller<fmui@apache.org> >>>>>>>>> >>>>>>>>> That is surprising. Chunked encoding isn't really exotic. >>>>>>>>> >>>>>>>>> >>>>>>>>> Definitely, but browsers are always there to remind us that >>>>>>>>>> world >>>>>>>>>> class >>>>>>>>>> >>>>>>>>>> standards are nothing different from regional social >>>>>>>>>> conventions, >>>>>>>>>> >>>>>>>>> are >>>>>>>>> they? >>>>>>>>> >>>>>>>>> >>>>>>>>> Could you please open an Improvement issue and add a few details. >>>>>>>>> I'll >>>>>>>>> >>>>>>>>> look into it. >>>>>>>>> >>>>>>>>>> Thanks, here it is<https://issues.apache.org/********<https://issues.apache.org/******> >>>>>>>>>> <https://issues.apache.**org/****<https://issues.apache.org/****> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> jira/browse/CMIS-655<https://****issues.apache.org/**jira/** >>>>>>>>>> browse/CMIS-655<https://**issues.apache.org/**jira/** >>>>>>>>>> browse/CMIS-655<https://issues.apache.org/**jira/browse/CMIS-655> >>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> <https://**issues.apache.org/****jira/browse/**CMIS-655<http://issues.apache.org/**jira/browse/**CMIS-655> >>>>>>>>>> <http:/**/issues.apache.org/jira/**browse/**CMIS-655<http://issues.apache.org/jira/browse/**CMIS-655> >>>>>>>>>> > >>>>>>>>>> <https:/**/issues.apache.org/**jira/**browse/CMIS-655<http://issues.apache.org/jira/**browse/CMIS-655> >>>>>>>>>> <https:/**/issues.apache.org/jira/**browse/CMIS-655<https://issues.apache.org/jira/browse/CMIS-655> >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>> -- >>> Carlo Sciolla >>> >>> --==(A)==-- >>> Linux User #372086 >>> My personal blog: http://www.skuro.tk >>> Follow me on twitter: http://twitter.com/skuro >>> <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro >>> <http://github.com/skuro>My LinkedIn profile: >>> http://nl.linkedin.com/in/**carlosciolla<http://nl.linkedin.com/in/carlosciolla> >>> --==(A)==-- >>> >>> Product Lead at Backbase - Next Generation Portal Software for Financials >>> & Large Enterprises (http://www.backbase.com) >>> >>> >> >> >> > -- Carlo Sciolla --==(A)==-- Linux User #372086 My personal blog: http://www.skuro.tk Follow me on twitter: http://twitter.com/skuro <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro <http://github.com/skuro>My LinkedIn profile: http://nl.linkedin.com/in/carlosciolla --==(A)==-- Product Lead at Backbase - Next Generation Portal Software for Financials & Large Enterprises (http://www.backbase.com)
Got it. I thought you were heading in a different direction. How is that different from making the current Dispatch object protected or adding a protected method that wraps the Dispatch.addResource() method? Extensibility-wise they would be equal. Your version only adds a bit more syntactic sugar. It would also need a bit more memory because we would have to add about 100 additional classes (AtomPub + Browser) and runtime objects. - Florian > Is it next week already? :-) > > Jokes apart, I had one hour to spare for this topic now that it's still > hot, and produced the patch you can see attached to > CMIS-656<https://issues.apache.org/jira/browse/CMIS-656>. > That's a translation of the current Chemistry dispatch logic to abandon > reflection, static methods, private constructors, and final classes. > > The flow is quite the same as before, with the servlet initialization logic > registering the default bindings by adding concrete instances of a > ServiceCall interface into a local registry. At request serving time the > registered ServiceCall is retrieved and its service() method invoked. The > invocation logic is now a mere INVOKEINTERFACE JVM instruction instead of > the previous reflection trick (tiny performance improvement here). > > Please note that the ServiceCall interface was already a hidden contract > that all service calls had to implement to be addressable by the Method > created by the Dispatcher. > > As a last note, CmisAtomPubServlet also exposes a protected > registerDispatch(resource, method, ServiceCall) to allow implementors to > override the default logic. > > That's it for now. Please note that as the Dispatcher is shared across the > AtomPub and Browser bindings, and as only the AtomPub was properly > refactored, that patch will break your build. > > Looking forward to hear your comments, > c. > > > 2013/5/10 Carlo Sciolla<carlo.sciolla@gmail.com> > >> Hi Florian, >> >> will do, I'll hopefully have a patch for you to review next week. >> >> c. >> >> >> 2013/5/10 Florian Müller<fmui@apache.org> >> >>> Hi Carlo, >>> >>> Please go ahead and make a proposal. Submit a patch that sketches your >>> ideas. It doesn't have to be complete and running. >>> It's easier to talk about something concrete rather than discussing about >>> generic topics. >>> >>> - Florian >>> >>> >>> >>> Hi Florian, >>>> it's not my intent to start a flame war, and we can continue offline if >>>> you >>>> want. To the interest of the list, I'll just write here some of the >>>> reasons >>>> behind my previous comment, and wait until I have some patch ready to >>>> prove >>>> my points before bothering you guys again with my ramblings. >>>> >>>> I understand your remark on the spec compliance, and that interop is at >>>> stake when you allow the protocol details to be modified. BUT... >>>> >>>> - There's much more to HTTP than what CMIS specifies, and Chemistry is >>>> currently in charge of handling the transport protocol on top of which >>>> CMIS >>>> expresses itself. >>>> >>>> - No extensibility means that backporting of fixes might be a no-go. For >>>> example, if I now upgrade Chemistry to the latest trunk my code doesn't >>>> compile anymore. Subclassing would be the best way to integrate your >>>> changes in the version I use, but that's not available to me. >>>> >>>> - The CMIS spec is (hopefully!) not fixed and will evolve with time. OO >>>> could help greatly e.g. to support different versions of the protocol >>>> with >>>> a single serve instance, which is painful to implement cleanly following >>>> the current code approach. >>>> >>>> - Spec extensions are not evil per se. While they might indeed break >>>> interoperability, they're also a way to open the protocol itself to >>>> experiments and eventually drive a community based evolution of it. >>>> >>>> - Interop is not always the top priority. CMIS and Chemistry provide a >>>> lot >>>> of value OOTB, and I don't see why proprietary extensions should be >>>> denied >>>> by principle. Why shouldn't I have the possibility to write a custom >>>> extension to improve e.g. content delivery capabilities >>>> (getContentStreamByPath, anyone?), while still retaining full protocol >>>> compliance for B2B data exchange? >>>> >>>> If you made it to here, a big thank you for your patience. >>>> >>>> Hope this helps, >>>> c. >>>> >>>> >>>> >>>> >>>> 2013/5/8 Florian Müller<fmui@apache.org> >>>> >>>> Hi Carlo, >>>>> This code is not meant to be extensible. The CMIS standard is fixed. >>>>> There >>>>> will be no additional services or operations. Also, the semantics of the >>>>> parameters will not change or have to be changed. Any extensions would >>>>> bypass the specification, which would be a pain for clients and doesn't >>>>> help interoperability. >>>>> All methods that handle requests are stateless, isolated pieces of code. >>>>> OO doesn't help here. And the alternative to reflections would be a 120 >>>>> lines if-statement. I can't see the advantage of that. >>>>> >>>>> Also, this part is considered internal code and may change at any time. >>>>> OpenCMIS provides a lot of extensibility on the client side and keeping >>>>> the >>>>> interfaces compatible does hurt sometimes. I don't see a real use case >>>>> to >>>>> have that pain also on the server side. If there is something missing or >>>>> wrong, we usually fix it pretty quick - as you have seen. >>>>> >>>>> Having said that, if you have a great idea how to refactor that code, >>>>> feel >>>>> free to provide a patch. >>>>> >>>>> >>>>> - Florian >>>>> >>>>> >>>>> Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb Carlo Sciolla< >>>>> carlo.sciolla@gmail.com>: >>>>> >>>>> Hi Florian, >>>>>> thanks for your quick commit, I will experiment a bit with it and let >>>>>> you >>>>>> know what comes out of it. I do already have some initial comments >>>>>> anyway: >>>>>> >>>>>> - I see you only addressed the browser bindings implementation. While I >>>>>> can >>>>>> see the reason behind it, I think it won't hurt to also apply a similar >>>>>> logic to the AtomPub binding >>>>>> >>>>>> - as I'm stuck with v0.6.0, I'm looking into ways to backport or >>>>>> integrate >>>>>> your code in my app. The current logic for method dispatch in AtomPub >>>>>> goes >>>>>> against extensibility (and some object oriented design principles, IMO) >>>>>> and >>>>>> while for the time being I can work around it, would you guys consider >>>>>> refactoring the dispatch logic to make use of non-final classes / no >>>>>> reflection / public constructors? >>>>>> >>>>>> Thanks, >>>>>> c. >>>>>> >>>>>> >>>>>> 2013/5/8 Florian Müller<fmui@apache.org> >>>>>> >>>>>> Hi Carlo, >>>>>> >>>>>>> I've added some new code. There are now three interfaces that let you >>>>>>> control the server headers. >>>>>>> The ContentStream object that is returned by getContentStream() must >>>>>>> implement the interface(s) to trigger the behavior: >>>>>>> >>>>>>> ContentLengthContentStream - Sets the Content-Length header and turns >>>>>>> chunking off. >>>>>>> >>>>>>> LastModifiedContentStream - Sets the Last-Modified header and respects >>>>>>> the >>>>>>> If-Modified-Since header. >>>>>>> >>>>>>> CacheHeaderContentStream - Sets the Cache-Control header, the Expires >>>>>>> header, and the ETag header and respects the If-None-Match header. >>>>>>> >>>>>>> >>>>>>> Please let me know if that works for you. >>>>>>> >>>>>>> >>>>>>> - Florian >>>>>>> >>>>>>> >>>>>>> Hi there, sorry for the late reply. >>>>>>> >>>>>>> >>>>>>>> 2013/5/7 Florian Müller<fmui@apache.org> >>>>>>>> >>>>>>>> That is surprising. Chunked encoding isn't really exotic. >>>>>>>> >>>>>>>> >>>>>>>>> Definitely, but browsers are always there to remind us that world >>>>>>>>> class >>>>>>>>> >>>>>>>>> standards are nothing different from regional social conventions, >>>>>>>> are >>>>>>>> they? >>>>>>>> >>>>>>>> >>>>>>>> Could you please open an Improvement issue and add a few details. >>>>>>>> I'll >>>>>>>> >>>>>>>> look into it. >>>>>>>>> Thanks, here it is<https://issues.apache.org/******<https://issues.apache.org/****> >>>>>>>>> >>>>>>>>> jira/browse/CMIS-655<https://**issues.apache.org/**jira/** >>>>>>>>> browse/CMIS-655<https://issues.apache.org/**jira/browse/CMIS-655>> >>>>>>>>> >>>>>>>>> <https://**issues.apache.org/**jira/browse/**CMIS-655<http://issues.apache.org/jira/browse/**CMIS-655> >>>>>>>>> <https:/**/issues.apache.org/jira/**browse/CMIS-655<https://issues.apache.org/jira/browse/CMIS-655> >>>>>>>>>> >>>>>>>>> >. >>>>>>>> >>>>>>>> >>>>>>> >> >> -- >> Carlo Sciolla >> >> --==(A)==-- >> Linux User #372086 >> My personal blog: http://www.skuro.tk >> Follow me on twitter: http://twitter.com/skuro >> <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro >> <http://github.com/skuro>My LinkedIn profile: >> http://nl.linkedin.com/in/carlosciolla >> --==(A)==-- >> >> Product Lead at Backbase - Next Generation Portal Software for Financials >> & Large Enterprises (http://www.backbase.com) >> > > >
Is it next week already? :-) Jokes apart, I had one hour to spare for this topic now that it's still hot, and produced the patch you can see attached to CMIS-656<https://issues.apache.org/jira/browse/CMIS-656>. That's a translation of the current Chemistry dispatch logic to abandon reflection, static methods, private constructors, and final classes. The flow is quite the same as before, with the servlet initialization logic registering the default bindings by adding concrete instances of a ServiceCall interface into a local registry. At request serving time the registered ServiceCall is retrieved and its service() method invoked. The invocation logic is now a mere INVOKEINTERFACE JVM instruction instead of the previous reflection trick (tiny performance improvement here). Please note that the ServiceCall interface was already a hidden contract that all service calls had to implement to be addressable by the Method created by the Dispatcher. As a last note, CmisAtomPubServlet also exposes a protected registerDispatch(resource, method, ServiceCall) to allow implementors to override the default logic. That's it for now. Please note that as the Dispatcher is shared across the AtomPub and Browser bindings, and as only the AtomPub was properly refactored, that patch will break your build. Looking forward to hear your comments, c. 2013/5/10 Carlo Sciolla <carlo.sciolla@gmail.com> > Hi Florian, > > will do, I'll hopefully have a patch for you to review next week. > > c. > > > 2013/5/10 Florian Müller <fmui@apache.org> > >> Hi Carlo, >> >> Please go ahead and make a proposal. Submit a patch that sketches your >> ideas. It doesn't have to be complete and running. >> It's easier to talk about something concrete rather than discussing about >> generic topics. >> >> - Florian >> >> >> >> Hi Florian, >>> >>> it's not my intent to start a flame war, and we can continue offline if >>> you >>> want. To the interest of the list, I'll just write here some of the >>> reasons >>> behind my previous comment, and wait until I have some patch ready to >>> prove >>> my points before bothering you guys again with my ramblings. >>> >>> I understand your remark on the spec compliance, and that interop is at >>> stake when you allow the protocol details to be modified. BUT... >>> >>> - There's much more to HTTP than what CMIS specifies, and Chemistry is >>> currently in charge of handling the transport protocol on top of which >>> CMIS >>> expresses itself. >>> >>> - No extensibility means that backporting of fixes might be a no-go. For >>> example, if I now upgrade Chemistry to the latest trunk my code doesn't >>> compile anymore. Subclassing would be the best way to integrate your >>> changes in the version I use, but that's not available to me. >>> >>> - The CMIS spec is (hopefully!) not fixed and will evolve with time. OO >>> could help greatly e.g. to support different versions of the protocol >>> with >>> a single serve instance, which is painful to implement cleanly following >>> the current code approach. >>> >>> - Spec extensions are not evil per se. While they might indeed break >>> interoperability, they're also a way to open the protocol itself to >>> experiments and eventually drive a community based evolution of it. >>> >>> - Interop is not always the top priority. CMIS and Chemistry provide a >>> lot >>> of value OOTB, and I don't see why proprietary extensions should be >>> denied >>> by principle. Why shouldn't I have the possibility to write a custom >>> extension to improve e.g. content delivery capabilities >>> (getContentStreamByPath, anyone?), while still retaining full protocol >>> compliance for B2B data exchange? >>> >>> If you made it to here, a big thank you for your patience. >>> >>> Hope this helps, >>> c. >>> >>> >>> >>> >>> 2013/5/8 Florian Müller <fmui@apache.org> >>> >>> Hi Carlo, >>>> >>>> This code is not meant to be extensible. The CMIS standard is fixed. >>>> There >>>> will be no additional services or operations. Also, the semantics of the >>>> parameters will not change or have to be changed. Any extensions would >>>> bypass the specification, which would be a pain for clients and doesn't >>>> help interoperability. >>>> All methods that handle requests are stateless, isolated pieces of code. >>>> OO doesn't help here. And the alternative to reflections would be a 120 >>>> lines if-statement. I can't see the advantage of that. >>>> >>>> Also, this part is considered internal code and may change at any time. >>>> OpenCMIS provides a lot of extensibility on the client side and keeping >>>> the >>>> interfaces compatible does hurt sometimes. I don't see a real use case >>>> to >>>> have that pain also on the server side. If there is something missing or >>>> wrong, we usually fix it pretty quick - as you have seen. >>>> >>>> Having said that, if you have a great idea how to refactor that code, >>>> feel >>>> free to provide a patch. >>>> >>>> >>>> - Florian >>>> >>>> >>>> Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb Carlo Sciolla < >>>> carlo.sciolla@gmail.com>: >>>> >>>> Hi Florian, >>>>> >>>>> thanks for your quick commit, I will experiment a bit with it and let >>>>> you >>>>> know what comes out of it. I do already have some initial comments >>>>> anyway: >>>>> >>>>> - I see you only addressed the browser bindings implementation. While I >>>>> can >>>>> see the reason behind it, I think it won't hurt to also apply a similar >>>>> logic to the AtomPub binding >>>>> >>>>> - as I'm stuck with v0.6.0, I'm looking into ways to backport or >>>>> integrate >>>>> your code in my app. The current logic for method dispatch in AtomPub >>>>> goes >>>>> against extensibility (and some object oriented design principles, IMO) >>>>> and >>>>> while for the time being I can work around it, would you guys consider >>>>> refactoring the dispatch logic to make use of non-final classes / no >>>>> reflection / public constructors? >>>>> >>>>> Thanks, >>>>> c. >>>>> >>>>> >>>>> 2013/5/8 Florian Müller <fmui@apache.org> >>>>> >>>>> Hi Carlo, >>>>> >>>>>> >>>>>> I've added some new code. There are now three interfaces that let you >>>>>> control the server headers. >>>>>> The ContentStream object that is returned by getContentStream() must >>>>>> implement the interface(s) to trigger the behavior: >>>>>> >>>>>> ContentLengthContentStream - Sets the Content-Length header and turns >>>>>> chunking off. >>>>>> >>>>>> LastModifiedContentStream - Sets the Last-Modified header and respects >>>>>> the >>>>>> If-Modified-Since header. >>>>>> >>>>>> CacheHeaderContentStream - Sets the Cache-Control header, the Expires >>>>>> header, and the ETag header and respects the If-None-Match header. >>>>>> >>>>>> >>>>>> Please let me know if that works for you. >>>>>> >>>>>> >>>>>> - Florian >>>>>> >>>>>> >>>>>> Hi there, sorry for the late reply. >>>>>> >>>>>> >>>>>>> 2013/5/7 Florian Müller <fmui@apache.org> >>>>>>> >>>>>>> That is surprising. Chunked encoding isn't really exotic. >>>>>>> >>>>>>> >>>>>>>> Definitely, but browsers are always there to remind us that world >>>>>>>> class >>>>>>>> >>>>>>>> standards are nothing different from regional social conventions, >>>>>>> are >>>>>>> they? >>>>>>> >>>>>>> >>>>>>> Could you please open an Improvement issue and add a few details. >>>>>>> I'll >>>>>>> >>>>>>> look into it. >>>>>>>> >>>>>>>> Thanks, here it is <https://issues.apache.org/******<https://issues.apache.org/****> >>>>>>>> >>>>>>>> jira/browse/CMIS-655<https://**issues.apache.org/**jira/** >>>>>>>> browse/CMIS-655 <https://issues.apache.org/**jira/browse/CMIS-655>> >>>>>>>> >>>>>>>> <https://**issues.apache.org/**jira/browse/**CMIS-655<http://issues.apache.org/jira/browse/**CMIS-655> >>>>>>>> <https:/**/issues.apache.org/jira/**browse/CMIS-655<https://issues.apache.org/jira/browse/CMIS-655> >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>> >. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >> > > > -- > Carlo Sciolla > > --==(A)==-- > Linux User #372086 > My personal blog: http://www.skuro.tk > Follow me on twitter: http://twitter.com/skuro > <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro > <http://github.com/skuro>My LinkedIn profile: > http://nl.linkedin.com/in/carlosciolla > --==(A)==-- > > Product Lead at Backbase - Next Generation Portal Software for Financials > & Large Enterprises (http://www.backbase.com) > -- Carlo Sciolla --==(A)==-- Linux User #372086 My personal blog: http://www.skuro.tk Follow me on twitter: http://twitter.com/skuro <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro <http://github.com/skuro>My LinkedIn profile: http://nl.linkedin.com/in/carlosciolla --==(A)==-- Product Lead at Backbase - Next Generation Portal Software for Financials & Large Enterprises (http://www.backbase.com)
[ https://issues.apache.org/jira/browse/CMIS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlo Sciolla updated CMIS-656:
-------------------------------
Attachment: noreflection.patch
The provided patch only affects the AtomPub binding (and partially the Browser binding, which
is left broken for the time being) in the following ways:
- a new ServiceCall single method interface is created, with a method call having the same
interface as all Service methods used to have
- single classes per service area (e.g. ObjectService) are translated into packages (e.g.
org.apache.chemistry.opencmis.server.impl.atompub.object)
- classes inside the service packages implement the ServiceCall interface, thus implementing
a single service call each
- the dispatch logic at servlet level is similar to what it used to be, with the Dispatcher
now not using reflection anymore to point to the service logic but rather concrete instances
of ServiceCall
- CmisAtomPubServlet has a protected registerDispatch method to allow subclasses to override
the default bindings
> Provide extension points for the protocol handling logic
> --------------------------------------------------------
>
> Key: CMIS-656
> URL: https://issues.apache.org/jira/browse/CMIS-656
> Project: Chemistry
> Issue Type: Improvement
> Components: opencmis-server
> Affects Versions: OpenCMIS 0.9.0 beta 1
> Reporter: Carlo Sciolla
> Attachments: noreflection.patch
>
>
> Chemistry takes full control over the serialization process, including all details of
the underlying HTTP communication. Extension points or APIs in this process would allow implementors
to leverage greater flexibility to fine tune the serialization process, or to implement extensions
over the standard CMIS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Carlo Sciolla created CMIS-656:
----------------------------------
Summary: Provide extension points for the protocol handling logic
Key: CMIS-656
URL: https://issues.apache.org/jira/browse/CMIS-656
Project: Chemistry
Issue Type: Improvement
Components: opencmis-server
Affects Versions: OpenCMIS 0.9.0 beta 1
Reporter: Carlo Sciolla
Chemistry takes full control over the serialization process, including all details of the
underlying HTTP communication. Extension points or APIs in this process would allow implementors
to leverage greater flexibility to fine tune the serialization process, or to implement extensions
over the standard CMIS.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira