Feedback from implementing an AtomPub(-like!) server on top of JCR

[James Abley]

Hi,

I've got my first version up and running. It does POST of media assets
to a collection, GET of entries and PUT of the same entries.

Just some observations which most likely are due to my lack of
experience with the code base. I extended
AbstractEntityCollectionAdapter, so all of my comments relate to this
class.

1. I overrode getHref(RequestContext) like so:

    /
     * {@inheritDoc}
     */
    @Override
    public String getHref(RequestContext request) {

        /*
         * FIXME We override the default implementation to ensure that
variables bound for parameter substitution are
         * available for URI Templates / Routes.
         */
        Map<String, String> params = new HashMap<String, String>();

        Target target = request.getTarget();

        for (String param : target.getParameterNames()) {
            params.put(param, target.getParameter(param));
        }

        return request.urlFor("feed", params);
    }

Otherwise I was getting back links like

/contextpath/base//

rather than

/contextpath/base/workspace/collection-name

I'm not sure what I'm missing here. I should be able to submit a test
case and maybe patch if it is a genuine problem, although I used JMock
rather than EasyMock.

2. When I GET an Media Link Entry, I'm getting a <source/> element in
the output document.

I had to override the following methods to get this to work happily.

    /**
     * {@inheritDoc}
     */
    @Override
    public String getAuthor(RequestContext request) throws
ResponseContextException {

        /* FIXME this is called when a <source/> is set during a GET request. */
        return "author-goes-here";
    }

    /**
     * {@inheritDoc}
     */
    @Override
    public String getId(RequestContext request) {

        /* FIXME this is called when a <source/> is set during a GET request. */
        return "id-goes-here";
    }

    /**
     * {@inheritDoc}
     */
    public String getTitle(RequestContext request) {

        /* FIXME this is called when a <source/> is set during a GET request. */
        return "title-goes-here";
    }


For my use case, I'm not that bothered about a <source/> and I'm not
completely sure why it only happens on a GET to that resource, but the
POST of the media entity to the collection does not contain the
<source/> in the response body.

3.     public void putEntry(T entry, String title, Date updated,
List<Person> authors, String summary,
            Content content, RequestContext request) throws
ResponseContextException {

This method does not get passed the FOMEntry, so I wasn't sure how to
get hold of the extension XML in the request body. In the end, I went
for the following:

    /**
     * {@inheritDoc}
     */
    @Override
    protected Entry getEntryFromRequest(RequestContext request) throws
ResponseContextException {
        /* FIXME the Entry isn't passed into putEntry, so stick it in
the request context for now. */

        Entry result = super.getEntryFromRequest(request);

        request.setAttribute(Entry.class.getName(), result);

        return result;
    }

I think that reading and writing extension elements could do with
documenting on the wiki. I found stuff from the example code and
google, but it seems sensible to put it on the wiki. I don't have
write access (I think) but I'm happy to draft my newbie experiences in
the hope that it will be coherent / correct enough to help others.

Summing up, a really nice library to use. Thanks guys.

Cheers,

James

[David Primmer-3]

On Wed, Jul 30, 2008 at 2:03 PM, James Abley <james.abley@...> wrote:

> Hi,
>
> I've got my first version up and running. It does POST of media assets
> to a collection, GET of entries and PUT of the same entries.
>
> Just some observations which most likely are due to my lack of
> experience with the code base. I extended
> AbstractEntityCollectionAdapter, so all of my comments relate to this
> class.
>
> 1. I overrode getHref(RequestContext) like so:
>
>    /
>     * {@inheritDoc}
>     */
>    @Override
>    public String getHref(RequestContext request) {
>
>        /*
>         * FIXME We override the default implementation to ensure that
> variables bound for parameter substitution are
>         * available for URI Templates / Routes.
>         */
>        Map<String, String> params = new HashMap<String, String>();
>
>        Target target = request.getTarget();
>
>        for (String param : target.getParameterNames()) {
>            params.put(param, target.getParameter(param));
>        }
>
>        return request.urlFor("feed", params);
>    }
>
> Otherwise I was getting back links like
>
> /contextpath/base//
>
> rather than
>
> /contextpath/base/workspace/collection-name
>
> I'm not sure what I'm missing here. I should be able to submit a test
> case and maybe patch if it is a genuine problem, although I used JMock
> rather than EasyMock.

can't comment on the rest but this is the intended behavior. this was
recently changed. what you did, used to be done by default and it was
hard to undo it when you didn't want the request env pulled in.

davep

[James Abley]

2008/7/30 David Primmer <david.primmer@...>:

> On Wed, Jul 30, 2008 at 2:03 PM, James Abley <james.abley@...> wrote:
>> Hi,
>>
>> I've got my first version up and running. It does POST of media assets
>> to a collection, GET of entries and PUT of the same entries.
>>
>> Just some observations which most likely are due to my lack of
>> experience with the code base. I extended
>> AbstractEntityCollectionAdapter, so all of my comments relate to this
>> class.
>>
>> 1. I overrode getHref(RequestContext) like so:
>>
>>    /
>>     * {@inheritDoc}
>>     */
>>    @Override
>>    public String getHref(RequestContext request) {
>>
>>        /*
>>         * FIXME We override the default implementation to ensure that
>> variables bound for parameter substitution are
>>         * available for URI Templates / Routes.
>>         */
>>        Map<String, String> params = new HashMap<String, String>();
>>
>>        Target target = request.getTarget();
>>
>>        for (String param : target.getParameterNames()) {
>>            params.put(param, target.getParameter(param));
>>        }
>>
>>        return request.urlFor("feed", params);
>>    }
>>
>> Otherwise I was getting back links like
>>
>> /contextpath/base//
>>
>> rather than
>>
>> /contextpath/base/workspace/collection-name
>>
>> I'm not sure what I'm missing here. I should be able to submit a test
>> case and maybe patch if it is a genuine problem, although I used JMock
>> rather than EasyMock.
>
> can't comment on the rest but this is the intended behavior. this was
> recently changed. what you did, used to be done by default and it was
> hard to undo it when you didn't want the request env pulled in.
>
> davep
>

Thanks Dave,

I've tried to track down why the behaviour changed as you say.

$ svn praise server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
...
616540    dandiep   public String getHref(RequestContext request) {
617214    dandiep     return request.urlFor("feed", hrefParams);
616540    dandiep   }
...

$ svn log -r 617214
server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
------------------------------------------------------------------------
r617214 | dandiep | 2008-01-31 20:22:54 +0000 (Thu, 31 Jan 2008) | 1 line

Having issues today.. didn't mean to commit this.
------------------------------------------------------------------------

Going back one more change points me at
https://issues.apache.org/jira/browse/ABDERA-95.

I've had a look at the commits around that area but am none the wiser
as to why the code is the way it is. Any pointers?

Cheers,

James

[David Primmer-3]

follow this thread for history
urlFor in RouteManager does not let you null out vars
http://www.mail-archive.com/abdera-dev@.../msg02666.html
https://issues.apache.org/jira/browse/ABDERA-162

davep


On Thu, Jul 31, 2008 at 4:40 AM, James Abley <james.abley@...> wrote:

> 2008/7/30 David Primmer <david.primmer@...>:
>> On Wed, Jul 30, 2008 at 2:03 PM, James Abley <james.abley@...> wrote:
>>> Hi,
>>>
>>> I've got my first version up and running. It does POST of media assets
>>> to a collection, GET of entries and PUT of the same entries.
>>>
>>> Just some observations which most likely are due to my lack of
>>> experience with the code base. I extended
>>> AbstractEntityCollectionAdapter, so all of my comments relate to this
>>> class.
>>>
>>> 1. I overrode getHref(RequestContext) like so:
>>>
>>>    /
>>>     * {@inheritDoc}
>>>     */
>>>    @Override
>>>    public String getHref(RequestContext request) {
>>>
>>>        /*
>>>         * FIXME We override the default implementation to ensure that
>>> variables bound for parameter substitution are
>>>         * available for URI Templates / Routes.
>>>         */
>>>        Map<String, String> params = new HashMap<String, String>();
>>>
>>>        Target target = request.getTarget();
>>>
>>>        for (String param : target.getParameterNames()) {
>>>            params.put(param, target.getParameter(param));
>>>        }
>>>
>>>        return request.urlFor("feed", params);
>>>    }
>>>
>>> Otherwise I was getting back links like
>>>
>>> /contextpath/base//
>>>
>>> rather than
>>>
>>> /contextpath/base/workspace/collection-name
>>>
>>> I'm not sure what I'm missing here. I should be able to submit a test
>>> case and maybe patch if it is a genuine problem, although I used JMock
>>> rather than EasyMock.
>>
>> can't comment on the rest but this is the intended behavior. this was
>> recently changed. what you did, used to be done by default and it was
>> hard to undo it when you didn't want the request env pulled in.
>>
>> davep
>>
>
> Thanks Dave,
>
> I've tried to track down why the behaviour changed as you say.
>
> $ svn praise server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> ...
> 616540    dandiep   public String getHref(RequestContext request) {
> 617214    dandiep     return request.urlFor("feed", hrefParams);
> 616540    dandiep   }
> ...
>
> $ svn log -r 617214
> server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> ------------------------------------------------------------------------
> r617214 | dandiep | 2008-01-31 20:22:54 +0000 (Thu, 31 Jan 2008) | 1 line
>
> Having issues today.. didn't mean to commit this.
> ------------------------------------------------------------------------
>
> Going back one more change points me at
> https://issues.apache.org/jira/browse/ABDERA-95.
>
> I've had a look at the commits around that area but am none the wiser
> as to why the code is the way it is. Any pointers?
>
> Cheers,
>
> James
>

[Erasmo Valdez]

Hello, everyone and specially to Dave.

I just begun to use this library and im hunting for a way to implement a
server with JCR storage, could you help me?

Where do you get the info, or how do you implemented it, i heard there's
some kind of jcrcollectionadapter or something. Could you point me to the
right direction thanks.

On Thu, Jul 31, 2008 at 2:19 PM, David Primmer <david.primmer@...>wrote:

> follow this thread for history
> urlFor in RouteManager does not let you null out vars
> http://www.mail-archive.com/abdera-dev@.../msg02666.html
> https://issues.apache.org/jira/browse/ABDERA-162
>
> davep
>
>
> On Thu, Jul 31, 2008 at 4:40 AM, James Abley <james.abley@...>
> wrote:
> > 2008/7/30 David Primmer <david.primmer@...>:
> >> On Wed, Jul 30, 2008 at 2:03 PM, James Abley <james.abley@...>
> wrote:
> >>> Hi,
> >>>
> >>> I've got my first version up and running. It does POST of media assets
> >>> to a collection, GET of entries and PUT of the same entries.
> >>>
> >>> Just some observations which most likely are due to my lack of
> >>> experience with the code base. I extended
> >>> AbstractEntityCollectionAdapter, so all of my comments relate to this
> >>> class.
> >>>
> >>> 1. I overrode getHref(RequestContext) like so:
> >>>
> >>>    /
> >>>     * {@inheritDoc}
> >>>     */
> >>>    @Override
> >>>    public String getHref(RequestContext request) {
> >>>
> >>>        /*
> >>>         * FIXME We override the default implementation to ensure that
> >>> variables bound for parameter substitution are
> >>>         * available for URI Templates / Routes.
> >>>         */
> >>>        Map<String, String> params = new HashMap<String, String>();
> >>>
> >>>        Target target = request.getTarget();
> >>>
> >>>        for (String param : target.getParameterNames()) {
> >>>            params.put(param, target.getParameter(param));
> >>>        }
> >>>
> >>>        return request.urlFor("feed", params);
> >>>    }
> >>>
> >>> Otherwise I was getting back links like
> >>>
> >>> /contextpath/base//
> >>>
> >>> rather than
> >>>
> >>> /contextpath/base/workspace/collection-name
> >>>
> >>> I'm not sure what I'm missing here. I should be able to submit a test
> >>> case and maybe patch if it is a genuine problem, although I used JMock
> >>> rather than EasyMock.
> >>
> >> can't comment on the rest but this is the intended behavior. this was
> >> recently changed. what you did, used to be done by default and it was
> >> hard to undo it when you didn't want the request env pulled in.
> >>
> >> davep
> >>
> >
> > Thanks Dave,
> >
> > I've tried to track down why the behaviour changed as you say.
> >
> > $ svn praise
> server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> > ...
> > 616540    dandiep   public String getHref(RequestContext request) {
> > 617214    dandiep     return request.urlFor("feed", hrefParams);
> > 616540    dandiep   }
> > ...
> >
> > $ svn log -r 617214
> >
> server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> > ------------------------------------------------------------------------
> > r617214 | dandiep | 2008-01-31 20:22:54 +0000 (Thu, 31 Jan 2008) | 1 line
> >
> > Having issues today.. didn't mean to commit this.
> > ------------------------------------------------------------------------
> >
> > Going back one more change points me at
> > https://issues.apache.org/jira/browse/ABDERA-95.
> >
> > I've had a look at the commits around that area but am none the wiser
> > as to why the code is the way it is. Any pointers?
> >
> > Cheers,
> >
> > James
> >
>

[David Calavera]

Hi Erasmo

You can find the JcrAdapter into the adapters package

http://svn.apache.org/repos/asf/incubator/abdera/java/trunk/adapters/

it stores the collections into a jcr container. Take a look to the test in
order to know how to implement it.

http://svn.apache.org/repos/asf/incubator/abdera/java/trunk/adapters/jcr/src/test/java/org/apache/abdera/jcr/JcrCollectionAdapterTest.java

Regards

On Thu, Jul 31, 2008 at 11:32 PM, Erasmo Valdez <einundswanzig@...>wrote:

> Hello, everyone and specially to Dave.
>
> I just begun to use this library and im hunting for a way to implement a
> server with JCR storage, could you help me?
>
> Where do you get the info, or how do you implemented it, i heard there's
> some kind of jcrcollectionadapter or something. Could you point me to the
> right direction thanks.
>
> On Thu, Jul 31, 2008 at 2:19 PM, David Primmer <david.primmer@...
> >wrote:
>
> > follow this thread for history
> > urlFor in RouteManager does not let you null out vars
> >
> http://www.mail-archive.com/abdera-dev@.../msg02666.html
> > https://issues.apache.org/jira/browse/ABDERA-162
> >
> > davep
> >
> >
> > On Thu, Jul 31, 2008 at 4:40 AM, James Abley <james.abley@...>
> > wrote:
> > > 2008/7/30 David Primmer <david.primmer@...>:
> > >> On Wed, Jul 30, 2008 at 2:03 PM, James Abley <james.abley@...>
> > wrote:
> > >>> Hi,
> > >>>
> > >>> I've got my first version up and running. It does POST of media
> assets
> > >>> to a collection, GET of entries and PUT of the same entries.
> > >>>
> > >>> Just some observations which most likely are due to my lack of
> > >>> experience with the code base. I extended
> > >>> AbstractEntityCollectionAdapter, so all of my comments relate to this
> > >>> class.
> > >>>
> > >>> 1. I overrode getHref(RequestContext) like so:
> > >>>
> > >>>    /
> > >>>     * {@inheritDoc}
> > >>>     */
> > >>>    @Override
> > >>>    public String getHref(RequestContext request) {
> > >>>
> > >>>        /*
> > >>>         * FIXME We override the default implementation to ensure that
> > >>> variables bound for parameter substitution are
> > >>>         * available for URI Templates / Routes.
> > >>>         */
> > >>>        Map<String, String> params = new HashMap<String, String>();
> > >>>
> > >>>        Target target = request.getTarget();
> > >>>
> > >>>        for (String param : target.getParameterNames()) {
> > >>>            params.put(param, target.getParameter(param));
> > >>>        }
> > >>>
> > >>>        return request.urlFor("feed", params);
> > >>>    }
> > >>>
> > >>> Otherwise I was getting back links like
> > >>>
> > >>> /contextpath/base//
> > >>>
> > >>> rather than
> > >>>
> > >>> /contextpath/base/workspace/collection-name
> > >>>
> > >>> I'm not sure what I'm missing here. I should be able to submit a test
> > >>> case and maybe patch if it is a genuine problem, although I used
> JMock
> > >>> rather than EasyMock.
> > >>
> > >> can't comment on the rest but this is the intended behavior. this was
> > >> recently changed. what you did, used to be done by default and it was
> > >> hard to undo it when you didn't want the request env pulled in.
> > >>
> > >> davep
> > >>
> > >
> > > Thanks Dave,
> > >
> > > I've tried to track down why the behaviour changed as you say.
> > >
> > > $ svn praise
> >
> server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> > > ...
> > > 616540    dandiep   public String getHref(RequestContext request) {
> > > 617214    dandiep     return request.urlFor("feed", hrefParams);
> > > 616540    dandiep   }
> > > ...
> > >
> > > $ svn log -r 617214
> > >
> >
> server/src/main/java/org/apache/abdera/protocol/server/impl/AbstractCollectionAdapter.java
> > >
> ------------------------------------------------------------------------
> > > r617214 | dandiep | 2008-01-31 20:22:54 +0000 (Thu, 31 Jan 2008) | 1
> line
> > >
> > > Having issues today.. didn't mean to commit this.
> > >
> ------------------------------------------------------------------------
> > >
> > > Going back one more change points me at
> > > https://issues.apache.org/jira/browse/ABDERA-95.
> > >
> > > I've had a look at the commits around that area but am none the wiser
> > > as to why the code is the way it is. Any pointers?
> > >
> > > Cheers,
> > >
> > > James
> > >
> >
>

--
David Calavera
http://www.thinkincode.net

[James Abley]

2008/7/31 David Primmer <david.primmer@...>:
> follow this thread for history
> urlFor in RouteManager does not let you null out vars
> http://www.mail-archive.com/abdera-dev@.../msg02666.html
> https://issues.apache.org/jira/browse/ABDERA-162
>
> davep
>

Thanks Dave.

I'm actually using TemplateTargetManager rather than RouteManager. I
guess I don't understand named routes well enough to know why this
isn't working and what I'm doing wrong.

Cheers,

James

[David Primmer-3]

What I've been trying to say all along is that you have the expected
behavior and you will get

/contextpath/base//

rather than

/contextpath/base/workspace/collection-name

If you don't supply urlFor with values for the route variables. You
took care of this when you overrode getHref so there's no issue that I
can see.

If there's a bug, it's probably in the abstract base and it's more an
issue with code obfuscation. I don't particularly like the way getHref
was done. Too much indirection.

davep

On Fri, Aug 1, 2008 at 1:53 AM, James Abley <james.abley@...> wrote:

> 2008/7/31 David Primmer <david.primmer@...>:
>> follow this thread for history
>> urlFor in RouteManager does not let you null out vars
>> http://www.mail-archive.com/abdera-dev@.../msg02666.html
>> https://issues.apache.org/jira/browse/ABDERA-162
>>
>> davep
>>
>
> Thanks Dave.
>
> I'm actually using TemplateTargetManager rather than RouteManager. I
> guess I don't understand named routes well enough to know why this
> isn't working and what I'm doing wrong.
>
> Cheers,
>
> James
>