You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Minto van der sluis <mi...@xup.nl> on 2012/08/31 13:32:01 UTC
Best way to interact with the JSON viewer
Hi folks,
I wonder what is the best way to interact with the rest interface for my
ISIS application. Most information I could find mention interaction from
display technology like javascipt. In my case I need to interact server
side.
Ofcourse there are numerous client side REST libraries to choose from.
However I am probably not the first one trying to do this for an ISIS
project. So I wondered how others are doing this and what's the best way
to move forward.
Regards,
Minto van der Sluis
Re: Best way to interact with the JSON viewer
Posted by Jeroen van der Wal <je...@stromboli.it>.
Hi Minto,
we interface with the Restful API of our Isis application from another Java
program using java.net.HttpURLConnection and org.json.simple.JSONObject
classes. It's quite simple but only used to push data from legacy systems
into the Isis application.
Hope this helps.
Cheers,
Jeroen
On Fri, Aug 31, 2012 at 1:32 PM, Minto van der sluis <mi...@xup.nl> wrote:
> Hi folks,
>
> I wonder what is the best way to interact with the rest interface for my
> ISIS application. Most information I could find mention interaction from
> display technology like javascipt. In my case I need to interact server
> side.
>
> Ofcourse there are numerous client side REST libraries to choose from.
> However I am probably not the first one trying to do this for an ISIS
> project. So I wondered how others are doing this and what's the best way
> to move forward.
>
> Regards,
>
> Minto van der Sluis
>
>
Re: Oh oh, NullPointerException after switching to isis trunk
Posted by mi...@xup.nl.
Hi Dan,
Also have a look at ISIS-265 that I just created. It also contains a patch.
Regards,
Minto
Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> Thanks for taking the time to document this; I'll look at it hopefully
> later today.
>
>
> On 5 September 2012 09:54, <mi...@xup.nl> wrote:
>
>> Hi folks,
>>
>> The examples in trunk show this exact same behavior.
>>
>> It seems the examples have been neglected a little bit, since I first had
>> to upgrade them from 0.3.0 --> 0.3.1. The attached patch shows the changes
>> I made.
>>
>> Scenario to get to the NPE:
>> 1) apply patch
>> 2) mvn clean install - compiles claims example till html-viewer (json
>> viewer fails)
>> 3) cd html-viewer
>> 4) mvn jetty:run
>> 5) open browser in
>> http://localhost:8080/claims-**viewer-html<http://localhost:8080/claims-viewer-html>
>> 6) login
>> 7) click Employees
>> 8) click New Employee
>> 9) Enter a name
>> 10) click save ----> NPE
>>
>> Regards,
>>
>> Minto
>>
>>
>> Quoting minto@xup.nl:
>>
>> Hi Folks,
>>>
>>> After switching from 0.2.0 to isis trunk (0.3.1 snapshot) I run into an
>>> NPE (See stacktrace below). I probably did something wrong or forgot
>>> something, but I have no clue what. HELP! :-(
>>>
>>> Everything seems to work until I hit the "Ok" button when trying to
>>> create a new object.
>>>
>>> BTW. I switched back to in-memory persistor (from sql). What is required
>>> to get the JDO persistor running or to get the sql persistor back?
>>>
>>> Regards,
>>>
>>> Minto
>>>
>>> java.lang.NullPointerException
>>> at org.apache.isis.core.**metamodel.adapter.version.**
>>> ConcurrencyException.**buildMessage(**ConcurrencyException.java:36)
>>> at org.apache.isis.core.**metamodel.adapter.version.**
>>> ConcurrencyException.(**ConcurrencyException.java:50)
>>> at org.apache.isis.runtimes.dflt.**runtime.persistence.adapter.**
>>> PojoAdapter.checkLock(**PojoAdapter.java:337)
>>> at org.apache.isis.viewer.html.**context.**
>>> PersistentRootAdapterMapping.**checkVersion(**
>>> PersistentRootAdapterMapping.**java:56)
>>> at org.apache.isis.viewer.html.**context.Context.**
>>> getMappedObject(Context.java:**284)
>>> at org.apache.isis.viewer.html.**action.view.**
>>> ObjectViewAbstract.execute(**ObjectViewAbstract.java:39)
>>> at org.apache.isis.viewer.html.**servlet.internal.**
>>> WebController.runAction(**WebController.java:383)
>>> at org.apache.isis.viewer.html.**servlet.internal.**
>>> WebController.generatePage(**WebController.java:286)
>>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>>> processRequest(**ControllerServlet.java:129)
>>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>>> processRequest(**ControllerServlet.java:104)
>>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>>> doPost(ControllerServlet.java:**82)
>>> at javax.servlet.http.**HttpServlet.service(**
>>> HttpServlet.java:641)
>>> at javax.servlet.http.**HttpServlet.service(**
>>> HttpServlet.java:722)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(**ApplicationFilterChain.java:**305)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>>> *ApplicationFilterChain.java:**210)
>>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter$**
>>> SessionState.handle(**IsisSessionFilter.java:383)
>>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter.**
>>> doFilter(IsisSessionFilter.**java:404)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(**ApplicationFilterChain.java:**243)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>>> *ApplicationFilterChain.java:**210)
>>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter$**
>>> SessionState$1.handle(**IsisSessionFilter.java:315)
>>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter.**
>>> doFilter(IsisSessionFilter.**java:404)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**
>>> internalDoFilter(**ApplicationFilterChain.java:**243)
>>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>>> *ApplicationFilterChain.java:**210)
>>> at org.apache.catalina.core.**StandardWrapperValve.invoke(**
>>> StandardWrapperValve.java:225)
>>> at org.apache.catalina.core.**StandardContextValve.invoke(**
>>> StandardContextValve.java:123)
>>> at org.apache.catalina.**authenticator.**
>>> AuthenticatorBase.invoke(**AuthenticatorBase.java:472)
>>> at org.apache.catalina.core.**StandardHostValve.invoke(**
>>> StandardHostValve.java:168)
>>> at org.apache.catalina.valves.**ErrorReportValve.invoke(**
>>> ErrorReportValve.java:98)
>>> at org.apache.catalina.valves.**AccessLogValve.invoke(**
>>> AccessLogValve.java:927)
>>> at org.apache.catalina.core.**StandardEngineValve.invoke(**
>>> StandardEngineValve.java:118)
>>> at org.apache.catalina.connector.**CoyoteAdapter.service(**
>>> CoyoteAdapter.java:407)
>>> at org.apache.coyote.http11.**AbstractHttp11Processor.**process(*
>>> *AbstractHttp11Processor.java:**1001)
>>> at org.apache.coyote.**AbstractProtocol$**
>>> AbstractConnectionHandler.**process(AbstractProtocol.java:**585)
>>> at org.apache.tomcat.util.net.**JIoEndpoint$SocketProcessor.**
>>> run(JIoEndpoint.java:312)
>>> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>>> ThreadPoolExecutor.java:1110)
>>> at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>>> ThreadPoolExecutor.java:603)
>>> at java.lang.Thread.run(Thread.**java:722)
>>>
>>>
>>
>
Re: Oh oh, NullPointerException after switching to isis trunk
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Thanks for taking the time to document this; I'll look at it hopefully
later today.
On 5 September 2012 09:54, <mi...@xup.nl> wrote:
> Hi folks,
>
> The examples in trunk show this exact same behavior.
>
> It seems the examples have been neglected a little bit, since I first had
> to upgrade them from 0.3.0 --> 0.3.1. The attached patch shows the changes
> I made.
>
> Scenario to get to the NPE:
> 1) apply patch
> 2) mvn clean install - compiles claims example till html-viewer (json
> viewer fails)
> 3) cd html-viewer
> 4) mvn jetty:run
> 5) open browser in http://localhost:8080/claims-**viewer-html<http://localhost:8080/claims-viewer-html>
> 6) login
> 7) click Employees
> 8) click New Employee
> 9) Enter a name
> 10) click save ----> NPE
>
> Regards,
>
> Minto
>
>
> Quoting minto@xup.nl:
>
> Hi Folks,
>>
>> After switching from 0.2.0 to isis trunk (0.3.1 snapshot) I run into an
>> NPE (See stacktrace below). I probably did something wrong or forgot
>> something, but I have no clue what. HELP! :-(
>>
>> Everything seems to work until I hit the "Ok" button when trying to
>> create a new object.
>>
>> BTW. I switched back to in-memory persistor (from sql). What is required
>> to get the JDO persistor running or to get the sql persistor back?
>>
>> Regards,
>>
>> Minto
>>
>> java.lang.NullPointerException
>> at org.apache.isis.core.**metamodel.adapter.version.**
>> ConcurrencyException.**buildMessage(**ConcurrencyException.java:36)
>> at org.apache.isis.core.**metamodel.adapter.version.**
>> ConcurrencyException.(**ConcurrencyException.java:50)
>> at org.apache.isis.runtimes.dflt.**runtime.persistence.adapter.**
>> PojoAdapter.checkLock(**PojoAdapter.java:337)
>> at org.apache.isis.viewer.html.**context.**
>> PersistentRootAdapterMapping.**checkVersion(**
>> PersistentRootAdapterMapping.**java:56)
>> at org.apache.isis.viewer.html.**context.Context.**
>> getMappedObject(Context.java:**284)
>> at org.apache.isis.viewer.html.**action.view.**
>> ObjectViewAbstract.execute(**ObjectViewAbstract.java:39)
>> at org.apache.isis.viewer.html.**servlet.internal.**
>> WebController.runAction(**WebController.java:383)
>> at org.apache.isis.viewer.html.**servlet.internal.**
>> WebController.generatePage(**WebController.java:286)
>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>> processRequest(**ControllerServlet.java:129)
>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>> processRequest(**ControllerServlet.java:104)
>> at org.apache.isis.viewer.html.**servlet.ControllerServlet.**
>> doPost(ControllerServlet.java:**82)
>> at javax.servlet.http.**HttpServlet.service(**
>> HttpServlet.java:641)
>> at javax.servlet.http.**HttpServlet.service(**
>> HttpServlet.java:722)
>> at org.apache.catalina.core.**ApplicationFilterChain.**
>> internalDoFilter(**ApplicationFilterChain.java:**305)
>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>> *ApplicationFilterChain.java:**210)
>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter$**
>> SessionState.handle(**IsisSessionFilter.java:383)
>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter.**
>> doFilter(IsisSessionFilter.**java:404)
>> at org.apache.catalina.core.**ApplicationFilterChain.**
>> internalDoFilter(**ApplicationFilterChain.java:**243)
>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>> *ApplicationFilterChain.java:**210)
>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter$**
>> SessionState$1.handle(**IsisSessionFilter.java:315)
>> at org.apache.isis.runtimes.dflt.**webapp.IsisSessionFilter.**
>> doFilter(IsisSessionFilter.**java:404)
>> at org.apache.catalina.core.**ApplicationFilterChain.**
>> internalDoFilter(**ApplicationFilterChain.java:**243)
>> at org.apache.catalina.core.**ApplicationFilterChain.**doFilter(*
>> *ApplicationFilterChain.java:**210)
>> at org.apache.catalina.core.**StandardWrapperValve.invoke(**
>> StandardWrapperValve.java:225)
>> at org.apache.catalina.core.**StandardContextValve.invoke(**
>> StandardContextValve.java:123)
>> at org.apache.catalina.**authenticator.**
>> AuthenticatorBase.invoke(**AuthenticatorBase.java:472)
>> at org.apache.catalina.core.**StandardHostValve.invoke(**
>> StandardHostValve.java:168)
>> at org.apache.catalina.valves.**ErrorReportValve.invoke(**
>> ErrorReportValve.java:98)
>> at org.apache.catalina.valves.**AccessLogValve.invoke(**
>> AccessLogValve.java:927)
>> at org.apache.catalina.core.**StandardEngineValve.invoke(**
>> StandardEngineValve.java:118)
>> at org.apache.catalina.connector.**CoyoteAdapter.service(**
>> CoyoteAdapter.java:407)
>> at org.apache.coyote.http11.**AbstractHttp11Processor.**process(*
>> *AbstractHttp11Processor.java:**1001)
>> at org.apache.coyote.**AbstractProtocol$**
>> AbstractConnectionHandler.**process(AbstractProtocol.java:**585)
>> at org.apache.tomcat.util.net.**JIoEndpoint$SocketProcessor.**
>> run(JIoEndpoint.java:312)
>> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>> ThreadPoolExecutor.java:1110)
>> at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>> ThreadPoolExecutor.java:603)
>> at java.lang.Thread.run(Thread.**java:722)
>>
>>
>
Re: Oh oh, NullPointerException after switching to isis trunk
Posted by mi...@xup.nl.
Hi folks,
The examples in trunk show this exact same behavior.
It seems the examples have been neglected a little bit, since I first
had to upgrade them from 0.3.0 --> 0.3.1. The attached patch shows the
changes I made.
Scenario to get to the NPE:
1) apply patch
2) mvn clean install - compiles claims example till html-viewer (json
viewer fails)
3) cd html-viewer
4) mvn jetty:run
5) open browser in http://localhost:8080/claims-viewer-html
6) login
7) click Employees
8) click New Employee
9) Enter a name
10) click save ----> NPE
Regards,
Minto
Quoting minto@xup.nl:
> Hi Folks,
>
> After switching from 0.2.0 to isis trunk (0.3.1 snapshot) I run into
> an NPE (See stacktrace below). I probably did something wrong or
> forgot something, but I have no clue what. HELP! :-(
>
> Everything seems to work until I hit the "Ok" button when trying to
> create a new object.
>
> BTW. I switched back to in-memory persistor (from sql). What is
> required to get the JDO persistor running or to get the sql
> persistor back?
>
> Regards,
>
> Minto
>
> java.lang.NullPointerException
> at
> org.apache.isis.core.metamodel.adapter.version.ConcurrencyException.buildMessage(ConcurrencyException.java:36)
> at
> org.apache.isis.core.metamodel.adapter.version.ConcurrencyException.(ConcurrencyException.java:50)
> at
> org.apache.isis.runtimes.dflt.runtime.persistence.adapter.PojoAdapter.checkLock(PojoAdapter.java:337)
> at
> org.apache.isis.viewer.html.context.PersistentRootAdapterMapping.checkVersion(PersistentRootAdapterMapping.java:56)
> at
> org.apache.isis.viewer.html.context.Context.getMappedObject(Context.java:284)
> at
> org.apache.isis.viewer.html.action.view.ObjectViewAbstract.execute(ObjectViewAbstract.java:39)
> at
> org.apache.isis.viewer.html.servlet.internal.WebController.runAction(WebController.java:383)
> at
> org.apache.isis.viewer.html.servlet.internal.WebController.generatePage(WebController.java:286)
> at
> org.apache.isis.viewer.html.servlet.ControllerServlet.processRequest(ControllerServlet.java:129)
> at
> org.apache.isis.viewer.html.servlet.ControllerServlet.processRequest(ControllerServlet.java:104)
> at
> org.apache.isis.viewer.html.servlet.ControllerServlet.doPost(ControllerServlet.java:82)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter$SessionState.handle(IsisSessionFilter.java:383)
> at
> org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:404)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter$SessionState$1.handle(IsisSessionFilter.java:315)
> at
> org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:404)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
>
Oh oh, NullPointerException after switching to isis trunk
Posted by mi...@xup.nl.
Hi Folks,
After switching from 0.2.0 to isis trunk (0.3.1 snapshot) I run into
an NPE (See stacktrace below). I probably did something wrong or
forgot something, but I have no clue what. HELP! :-(
Everything seems to work until I hit the "Ok" button when trying to
create a new object.
BTW. I switched back to in-memory persistor (from sql). What is
required to get the JDO persistor running or to get the sql persistor
back?
Regards,
Minto
java.lang.NullPointerException
at
org.apache.isis.core.metamodel.adapter.version.ConcurrencyException.buildMessage(ConcurrencyException.java:36)
at
org.apache.isis.core.metamodel.adapter.version.ConcurrencyException.(ConcurrencyException.java:50)
at
org.apache.isis.runtimes.dflt.runtime.persistence.adapter.PojoAdapter.checkLock(PojoAdapter.java:337)
at
org.apache.isis.viewer.html.context.PersistentRootAdapterMapping.checkVersion(PersistentRootAdapterMapping.java:56)
at
org.apache.isis.viewer.html.context.Context.getMappedObject(Context.java:284)
at
org.apache.isis.viewer.html.action.view.ObjectViewAbstract.execute(ObjectViewAbstract.java:39)
at
org.apache.isis.viewer.html.servlet.internal.WebController.runAction(WebController.java:383)
at
org.apache.isis.viewer.html.servlet.internal.WebController.generatePage(WebController.java:286)
at
org.apache.isis.viewer.html.servlet.ControllerServlet.processRequest(ControllerServlet.java:129)
at
org.apache.isis.viewer.html.servlet.ControllerServlet.processRequest(ControllerServlet.java:104)
at
org.apache.isis.viewer.html.servlet.ControllerServlet.doPost(ControllerServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter$SessionState.handle(IsisSessionFilter.java:383)
at
org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:404)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter$SessionState$1.handle(IsisSessionFilter.java:315)
at
org.apache.isis.runtimes.dflt.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:404)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Re: Best way to interact with the JSON viewer
Posted by Jeroen van der Wal <je...@stromboli.it>.
I encountered the same issue but using the format "20120906T134034874"
worked for me when using the Restful API.
-Jeroen
On Thu, Sep 6, 2012 at 1:47 PM, <mi...@xup.nl> wrote:
> Additionally ISO8601 date are not supported
>
> When sending:
>
> "timestamp":"2012-09-06T13:40:**34.874+02:00"
>
> I get an "Unparseable date" exception. The following code was used to
> serialize the date:
>
> DateTime dateTime = new DateTime( new Date() );
> DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
> String dateTimeAsString = dateTimeFormatter.print( dateTime );
>
> What string based date format should be used?
>
> Regards,
>
> Minto
>
>
>
> Quoting minto@xup.nl:
>
> Result of my debug session:
>>
>> 1) Missing output details
>>
>> Currently the on the client side debug log shows the following server
>> error:
>>
>> "HTTP/1.1 500 Internal Server Error[\r][\n]"
>> "HTTP/1.1 500 Internal Server Error[\r][\n]"
>> "Content-Type: application/json;profile=urn:**
>> org.restfulobjects/error[\r][\**n]"
>> "Content-Length: 8824[\r][\n]"
>> "Server: Jetty(6.1.26)[\r][\n]"
>>
>> Details are missing here. Server side I have an exception saying
>> 'Unparseable date: "2012-09-05 09:30"'. The exception message is
>> swallowed since it does not appear in either client or server logging.
>>
>> The same happened with other messages
>>
>> 2) Long values < maxint not detected as longs
>>
>> In my domain model a field is defined as long. When entering this field
>> as:
>>
>> arguments.mapPut("**melderVolgnummer", 1);
>>
>> It is detected server side as Integer instead of Long. Forcefully adding
>> 1L or JsonRepresentation( new LongNode(1)) makes no difference. Server
>> side it appeared Jackson sees this field as IntNode. As a result isLong()
>> (on both JsonRepresentation and IntNode) returns false. This results in
>> the following exception.
>>
>> IllegalArgumentException(**formatExMsg(path, "is not a long"))
>>
>> Attached patch solves this issue.
>>
>> Regards,
>>
>> Minto
>>
>>
>> Quoting minto@xup.nl:
>>
>> Hi Folks,
>>>
>>> I managed to get something (using RO-applib) partly working. My current
>>> implementation is based on test code from the TCK.
>>>
>>> Retrieving some information works fine:
>>>
>>> 1) "GET /services/ HTTP/1.1[\r][\n]" (works OK)
>>> 2) "GET /services/servicename? ...." (works OK)
>>> 3) "POST /services/servicename/...." (Fails :( )
>>>
>>> In step 3 I wanted to create a new domain object. Unfortunately the
>>> server responded with a 500 Internal Server Error. Initially I thought
>>> this was due to ISIS-265. But after applying the patch the htmlviewer
>>> works fine but the RO-viewer still gives the same response.
>>>
>>> Looking in the server log I can't find any information about why POST
>>> request actually failed. Next step for me is to start debug the RO-viewer.
>>>
>>> If anyone has a clue what is going on here, I am all ears.
>>>
>>> Regards,
>>>
>>> Minto
>>>
>>>
>>> Quoting minto@xup.nl:
>>>
>>> Oh boy, this look complex.
>>>>
>>>> The code in RO-tck looks like some sort of meta programming. I am
>>>> looking for a piece of code to create a new domain object using
>>>> RO-applib. But I have a hard time digesting what's there.
>>>>
>>>> Can someone give me some more hints (hopefully a snippet)
>>>>
>>>> Regards,
>>>>
>>>> Minto
>>>>
>>>>
>>>> Quoting Dan Haywood <da...@haywood-associates.co.uk>**:
>>>>
>>>> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>>>>>
>>>>>
>>>>>> Should stick with the current release
>>>>>> 0.2.0 or move ahead. How stable is the current trunk version?
>>>>>>
>>>>>>
>>>>> It's pretty stable; starting to move towards getting a release out in
>>>>> the
>>>>> next month or two.
>>>>>
>>>>> And, what's new in trunk is the JDO object store, which may (perhaps)
>>>>> replace the SQL objectstore, at least in the short-term.
>>>>>
>>>>> Also, the v0.2.0 release holds an incomplete cut of the RO viewer
>>>>> (whatever
>>>>> was implemented back in Feb).
>>>>>
>>>>> ~~~
>>>>> If you do decide to track trunk, you might find it easiest to fork my
>>>>> github copy of Isis [1]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I will have a closer look at the latest/trunk ro-applib. I guess
>>>>>> RestfulRestfulClient is entry point to start from.
>>>>>>
>>>>>
>>>>>
>>>>> Yes, org.apache.isis.viewer.**restfulobjects.applib.**RestfulClient.
>>>>>
>>>>> This lets you use either a HATEOAS or a templated URL approach.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> But to be able to use
>>>>>> it I probably have to switch to using the trunk version.
>>>>>>
>>>>>>
>>>>> Not sure; I think you'll find that 0.2.0 does have something. Even
>>>>> so, I
>>>>> do recommend that you switch to trunk
>>>>>
>>>>>
>>>>>>
>>>>> Speaking slightly selfishly, I'd love you to have a go with using the
>>>>>>> RO
>>>>>>> applib; it'll help us determine where the gaps and annoyances are for
>>>>>>> "real-life" use.
>>>>>>>
>>>>>>
>>>>>> I could give it a try If I knew were to start. Is the 0.2.0 json
>>>>>> viewer
>>>>>> documentation still a good starting point? Since I am lazy ;-) I
>>>>>> wonder
>>>>>> if their exists some sample application already. This could give me a
>>>>>> headstart.
>>>>>>
>>>>>>
>>>>> The tests aren't a bad place to look; you'll find these in
>>>>> restfulobjects-tck.
>>>>>
>>>>> Admittedly, these have been knocked-about a bit and so quite a few are
>>>>> currently are @Ignore'd. However,
>>>>> the org.apache.isis.viewer.**restfulobjects.tck.resources.**
>>>>> home.HomePageResourceTest_**accept
>>>>> runs and passes. (It also uses the isisWebServerRule which bootstraps
>>>>> the
>>>>> web.xml within an integration test).
>>>>>
>>>>> Hope that helps some
>>>>>
>>>>> Dan
>>>>>
>>>>> [1] https://github.com/danhaywood/**apache-isis<https://github.com/danhaywood/apache-isis>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Best way to interact with the JSON viewer
Posted by Adam Howard <ho...@gmail.com>.
Minto,
When we get the restfulobjects-viewer up to 1.0.0 spec we will be using
ISO8601 formats. As it stands now I know the date part of the format is
yymmdd. Not sure about the time part. I don't remember off the top of my
head where the parsing lives.
--
Adam Howard
On Thu, Sep 6, 2012 at 6:47 AM, <mi...@xup.nl> wrote:
> Additionally ISO8601 date are not supported
>
> When sending:
>
> "timestamp":"2012-09-06T13:40:**34.874+02:00"
>
> I get an "Unparseable date" exception. The following code was used to
> serialize the date:
>
> DateTime dateTime = new DateTime( new Date() );
> DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
> String dateTimeAsString = dateTimeFormatter.print( dateTime );
>
> What string based date format should be used?
>
> Regards,
>
> Minto
>
>
>
> Quoting minto@xup.nl:
>
> Result of my debug session:
>>
>> 1) Missing output details
>>
>> Currently the on the client side debug log shows the following server
>> error:
>>
>> "HTTP/1.1 500 Internal Server Error[\r][\n]"
>> "HTTP/1.1 500 Internal Server Error[\r][\n]"
>> "Content-Type: application/json;profile=urn:**
>> org.restfulobjects/error[\r][\**n]"
>> "Content-Length: 8824[\r][\n]"
>> "Server: Jetty(6.1.26)[\r][\n]"
>>
>> Details are missing here. Server side I have an exception saying
>> 'Unparseable date: "2012-09-05 09:30"'. The exception message is
>> swallowed since it does not appear in either client or server logging.
>>
>> The same happened with other messages
>>
>> 2) Long values < maxint not detected as longs
>>
>> In my domain model a field is defined as long. When entering this field
>> as:
>>
>> arguments.mapPut("**melderVolgnummer", 1);
>>
>> It is detected server side as Integer instead of Long. Forcefully adding
>> 1L or JsonRepresentation( new LongNode(1)) makes no difference. Server
>> side it appeared Jackson sees this field as IntNode. As a result isLong()
>> (on both JsonRepresentation and IntNode) returns false. This results in
>> the following exception.
>>
>> IllegalArgumentException(**formatExMsg(path, "is not a long"))
>>
>> Attached patch solves this issue.
>>
>> Regards,
>>
>> Minto
>>
>>
>> Quoting minto@xup.nl:
>>
>> Hi Folks,
>>>
>>> I managed to get something (using RO-applib) partly working. My current
>>> implementation is based on test code from the TCK.
>>>
>>> Retrieving some information works fine:
>>>
>>> 1) "GET /services/ HTTP/1.1[\r][\n]" (works OK)
>>> 2) "GET /services/servicename? ...." (works OK)
>>> 3) "POST /services/servicename/...." (Fails :( )
>>>
>>> In step 3 I wanted to create a new domain object. Unfortunately the
>>> server responded with a 500 Internal Server Error. Initially I thought
>>> this was due to ISIS-265. But after applying the patch the htmlviewer
>>> works fine but the RO-viewer still gives the same response.
>>>
>>> Looking in the server log I can't find any information about why POST
>>> request actually failed. Next step for me is to start debug the RO-viewer.
>>>
>>> If anyone has a clue what is going on here, I am all ears.
>>>
>>> Regards,
>>>
>>> Minto
>>>
>>>
>>> Quoting minto@xup.nl:
>>>
>>> Oh boy, this look complex.
>>>>
>>>> The code in RO-tck looks like some sort of meta programming. I am
>>>> looking for a piece of code to create a new domain object using
>>>> RO-applib. But I have a hard time digesting what's there.
>>>>
>>>> Can someone give me some more hints (hopefully a snippet)
>>>>
>>>> Regards,
>>>>
>>>> Minto
>>>>
>>>>
>>>> Quoting Dan Haywood <da...@haywood-associates.co.uk>**:
>>>>
>>>> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>>>>>
>>>>>
>>>>>> Should stick with the current release
>>>>>> 0.2.0 or move ahead. How stable is the current trunk version?
>>>>>>
>>>>>>
>>>>> It's pretty stable; starting to move towards getting a release out in
>>>>> the
>>>>> next month or two.
>>>>>
>>>>> And, what's new in trunk is the JDO object store, which may (perhaps)
>>>>> replace the SQL objectstore, at least in the short-term.
>>>>>
>>>>> Also, the v0.2.0 release holds an incomplete cut of the RO viewer
>>>>> (whatever
>>>>> was implemented back in Feb).
>>>>>
>>>>> ~~~
>>>>> If you do decide to track trunk, you might find it easiest to fork my
>>>>> github copy of Isis [1]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I will have a closer look at the latest/trunk ro-applib. I guess
>>>>>> RestfulRestfulClient is entry point to start from.
>>>>>>
>>>>>
>>>>>
>>>>> Yes, org.apache.isis.viewer.**restfulobjects.applib.**RestfulClient.
>>>>>
>>>>> This lets you use either a HATEOAS or a templated URL approach.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> But to be able to use
>>>>>> it I probably have to switch to using the trunk version.
>>>>>>
>>>>>>
>>>>> Not sure; I think you'll find that 0.2.0 does have something. Even
>>>>> so, I
>>>>> do recommend that you switch to trunk
>>>>>
>>>>>
>>>>>>
>>>>> Speaking slightly selfishly, I'd love you to have a go with using the
>>>>>>> RO
>>>>>>> applib; it'll help us determine where the gaps and annoyances are for
>>>>>>> "real-life" use.
>>>>>>>
>>>>>>
>>>>>> I could give it a try If I knew were to start. Is the 0.2.0 json
>>>>>> viewer
>>>>>> documentation still a good starting point? Since I am lazy ;-) I
>>>>>> wonder
>>>>>> if their exists some sample application already. This could give me a
>>>>>> headstart.
>>>>>>
>>>>>>
>>>>> The tests aren't a bad place to look; you'll find these in
>>>>> restfulobjects-tck.
>>>>>
>>>>> Admittedly, these have been knocked-about a bit and so quite a few are
>>>>> currently are @Ignore'd. However,
>>>>> the org.apache.isis.viewer.**restfulobjects.tck.resources.**
>>>>> home.HomePageResourceTest_**accept
>>>>> runs and passes. (It also uses the isisWebServerRule which bootstraps
>>>>> the
>>>>> web.xml within an integration test).
>>>>>
>>>>> Hope that helps some
>>>>>
>>>>> Dan
>>>>>
>>>>> [1] https://github.com/danhaywood/**apache-isis<https://github.com/danhaywood/apache-isis>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Best way to interact with the JSON viewer
Posted by mi...@xup.nl.
Additionally ISO8601 date are not supported
When sending:
"timestamp":"2012-09-06T13:40:34.874+02:00"
I get an "Unparseable date" exception. The following code was used to
serialize the date:
DateTime dateTime = new DateTime( new Date() );
DateTimeFormatter dateTimeFormatter = ISODateTimeFormat.dateTime();
String dateTimeAsString = dateTimeFormatter.print( dateTime );
What string based date format should be used?
Regards,
Minto
Quoting minto@xup.nl:
> Result of my debug session:
>
> 1) Missing output details
>
> Currently the on the client side debug log shows the following server error:
>
> "HTTP/1.1 500 Internal Server Error[\r][\n]"
> "HTTP/1.1 500 Internal Server Error[\r][\n]"
> "Content-Type:
> application/json;profile=urn:org.restfulobjects/error[\r][\n]"
> "Content-Length: 8824[\r][\n]"
> "Server: Jetty(6.1.26)[\r][\n]"
>
> Details are missing here. Server side I have an exception saying
> 'Unparseable date: "2012-09-05 09:30"'. The exception message is
> swallowed since it does not appear in either client or server logging.
>
> The same happened with other messages
>
> 2) Long values < maxint not detected as longs
>
> In my domain model a field is defined as long. When entering this field as:
>
> arguments.mapPut("melderVolgnummer", 1);
>
> It is detected server side as Integer instead of Long. Forcefully
> adding 1L or JsonRepresentation( new LongNode(1)) makes no
> difference. Server side it appeared Jackson sees this field as
> IntNode. As a result isLong() (on both JsonRepresentation and
> IntNode) returns false. This results in the following exception.
>
> IllegalArgumentException(formatExMsg(path, "is not a long"))
>
> Attached patch solves this issue.
>
> Regards,
>
> Minto
>
>
> Quoting minto@xup.nl:
>
>> Hi Folks,
>>
>> I managed to get something (using RO-applib) partly working. My
>> current implementation is based on test code from the TCK.
>>
>> Retrieving some information works fine:
>>
>> 1) "GET /services/ HTTP/1.1[\r][\n]" (works OK)
>> 2) "GET /services/servicename? ...." (works OK)
>> 3) "POST /services/servicename/...." (Fails :( )
>>
>> In step 3 I wanted to create a new domain object. Unfortunately the
>> server responded with a 500 Internal Server Error. Initially I
>> thought this was due to ISIS-265. But after applying the patch the
>> htmlviewer works fine but the RO-viewer still gives the same
>> response.
>>
>> Looking in the server log I can't find any information about why
>> POST request actually failed. Next step for me is to start debug
>> the RO-viewer.
>>
>> If anyone has a clue what is going on here, I am all ears.
>>
>> Regards,
>>
>> Minto
>>
>>
>> Quoting minto@xup.nl:
>>
>>> Oh boy, this look complex.
>>>
>>> The code in RO-tck looks like some sort of meta programming. I am
>>> looking for a piece of code to create a new domain object using
>>> RO-applib. But I have a hard time digesting what's there.
>>>
>>> Can someone give me some more hints (hopefully a snippet)
>>>
>>> Regards,
>>>
>>> Minto
>>>
>>>
>>> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
>>>
>>>> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>>>>
>>>>>
>>>>> Should stick with the current release
>>>>> 0.2.0 or move ahead. How stable is the current trunk version?
>>>>>
>>>>
>>>> It's pretty stable; starting to move towards getting a release out in the
>>>> next month or two.
>>>>
>>>> And, what's new in trunk is the JDO object store, which may (perhaps)
>>>> replace the SQL objectstore, at least in the short-term.
>>>>
>>>> Also, the v0.2.0 release holds an incomplete cut of the RO viewer
>>>> (whatever
>>>> was implemented back in Feb).
>>>>
>>>> ~~~
>>>> If you do decide to track trunk, you might find it easiest to fork my
>>>> github copy of Isis [1]
>>>>
>>>>
>>>>
>>>>>
>>>>> I will have a closer look at the latest/trunk ro-applib. I guess
>>>>> RestfulRestfulClient is entry point to start from.
>>>>
>>>>
>>>> Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
>>>>
>>>> This lets you use either a HATEOAS or a templated URL approach.
>>>>
>>>>
>>>>
>>>>
>>>>> But to be able to use
>>>>> it I probably have to switch to using the trunk version.
>>>>>
>>>>
>>>> Not sure; I think you'll find that 0.2.0 does have something. Even so, I
>>>> do recommend that you switch to trunk
>>>>
>>>>>
>>>>
>>>>>> Speaking slightly selfishly, I'd love you to have a go with using the RO
>>>>>> applib; it'll help us determine where the gaps and annoyances are for
>>>>>> "real-life" use.
>>>>>
>>>>> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
>>>>> documentation still a good starting point? Since I am lazy ;-) I wonder
>>>>> if their exists some sample application already. This could give me a
>>>>> headstart.
>>>>>
>>>>
>>>> The tests aren't a bad place to look; you'll find these in
>>>> restfulobjects-tck.
>>>>
>>>> Admittedly, these have been knocked-about a bit and so quite a few are
>>>> currently are @Ignore'd. However,
>>>> the
>>>> org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
>>>> runs and passes. (It also uses the isisWebServerRule which bootstraps the
>>>> web.xml within an integration test).
>>>>
>>>> Hope that helps some
>>>>
>>>> Dan
>>>>
>>>> [1] https://github.com/danhaywood/apache-isis
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Best way to interact with the JSON viewer
Posted by mi...@xup.nl.
Result of my debug session:
1) Missing output details
Currently the on the client side debug log shows the following server error:
"HTTP/1.1 500 Internal Server Error[\r][\n]"
"HTTP/1.1 500 Internal Server Error[\r][\n]"
"Content-Type:
application/json;profile=urn:org.restfulobjects/error[\r][\n]"
"Content-Length: 8824[\r][\n]"
"Server: Jetty(6.1.26)[\r][\n]"
Details are missing here. Server side I have an exception saying
'Unparseable date: "2012-09-05 09:30"'. The exception message is
swallowed since it does not appear in either client or server logging.
The same happened with other messages
2) Long values < maxint not detected as longs
In my domain model a field is defined as long. When entering this field as:
arguments.mapPut("melderVolgnummer", 1);
It is detected server side as Integer instead of Long. Forcefully
adding 1L or JsonRepresentation( new LongNode(1)) makes no difference.
Server side it appeared Jackson sees this field as IntNode. As a
result isLong() (on both JsonRepresentation and IntNode) returns
false. This results in the following exception.
IllegalArgumentException(formatExMsg(path, "is not a long"))
Attached patch solves this issue.
Regards,
Minto
Quoting minto@xup.nl:
> Hi Folks,
>
> I managed to get something (using RO-applib) partly working. My
> current implementation is based on test code from the TCK.
>
> Retrieving some information works fine:
>
> 1) "GET /services/ HTTP/1.1[\r][\n]" (works OK)
> 2) "GET /services/servicename? ...." (works OK)
> 3) "POST /services/servicename/...." (Fails :( )
>
> In step 3 I wanted to create a new domain object. Unfortunately the
> server responded with a 500 Internal Server Error. Initially I
> thought this was due to ISIS-265. But after applying the patch the
> htmlviewer works fine but the RO-viewer still gives the same response.
>
> Looking in the server log I can't find any information about why
> POST request actually failed. Next step for me is to start debug the
> RO-viewer.
>
> If anyone has a clue what is going on here, I am all ears.
>
> Regards,
>
> Minto
>
>
> Quoting minto@xup.nl:
>
>> Oh boy, this look complex.
>>
>> The code in RO-tck looks like some sort of meta programming. I am
>> looking for a piece of code to create a new domain object using
>> RO-applib. But I have a hard time digesting what's there.
>>
>> Can someone give me some more hints (hopefully a snippet)
>>
>> Regards,
>>
>> Minto
>>
>>
>> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
>>
>>> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>>>
>>>>
>>>> Should stick with the current release
>>>> 0.2.0 or move ahead. How stable is the current trunk version?
>>>>
>>>
>>> It's pretty stable; starting to move towards getting a release out in the
>>> next month or two.
>>>
>>> And, what's new in trunk is the JDO object store, which may (perhaps)
>>> replace the SQL objectstore, at least in the short-term.
>>>
>>> Also, the v0.2.0 release holds an incomplete cut of the RO viewer (whatever
>>> was implemented back in Feb).
>>>
>>> ~~~
>>> If you do decide to track trunk, you might find it easiest to fork my
>>> github copy of Isis [1]
>>>
>>>
>>>
>>>>
>>>> I will have a closer look at the latest/trunk ro-applib. I guess
>>>> RestfulRestfulClient is entry point to start from.
>>>
>>>
>>> Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
>>>
>>> This lets you use either a HATEOAS or a templated URL approach.
>>>
>>>
>>>
>>>
>>>> But to be able to use
>>>> it I probably have to switch to using the trunk version.
>>>>
>>>
>>> Not sure; I think you'll find that 0.2.0 does have something. Even so, I
>>> do recommend that you switch to trunk
>>>
>>>>
>>>
>>>>> Speaking slightly selfishly, I'd love you to have a go with using the RO
>>>>> applib; it'll help us determine where the gaps and annoyances are for
>>>>> "real-life" use.
>>>>
>>>> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
>>>> documentation still a good starting point? Since I am lazy ;-) I wonder
>>>> if their exists some sample application already. This could give me a
>>>> headstart.
>>>>
>>>
>>> The tests aren't a bad place to look; you'll find these in
>>> restfulobjects-tck.
>>>
>>> Admittedly, these have been knocked-about a bit and so quite a few are
>>> currently are @Ignore'd. However,
>>> the
>>> org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
>>> runs and passes. (It also uses the isisWebServerRule which bootstraps the
>>> web.xml within an integration test).
>>>
>>> Hope that helps some
>>>
>>> Dan
>>>
>>> [1] https://github.com/danhaywood/apache-isis
>>>
>>
>>
>>
>
>
Re: Best way to interact with the JSON viewer
Posted by mi...@xup.nl.
Hi Folks,
I managed to get something (using RO-applib) partly working. My
current implementation is based on test code from the TCK.
Retrieving some information works fine:
1) "GET /services/ HTTP/1.1[\r][\n]" (works OK)
2) "GET /services/servicename? ...." (works OK)
3) "POST /services/servicename/...." (Fails :( )
In step 3 I wanted to create a new domain object. Unfortunately the
server responded with a 500 Internal Server Error. Initially I thought
this was due to ISIS-265. But after applying the patch the htmlviewer
works fine but the RO-viewer still gives the same response.
Looking in the server log I can't find any information about why POST
request actually failed. Next step for me is to start debug the
RO-viewer.
If anyone has a clue what is going on here, I am all ears.
Regards,
Minto
Quoting minto@xup.nl:
> Oh boy, this look complex.
>
> The code in RO-tck looks like some sort of meta programming. I am
> looking for a piece of code to create a new domain object using
> RO-applib. But I have a hard time digesting what's there.
>
> Can someone give me some more hints (hopefully a snippet)
>
> Regards,
>
> Minto
>
>
> Quoting Dan Haywood <da...@haywood-associates.co.uk>:
>
>> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>>
>>>
>>> Should stick with the current release
>>> 0.2.0 or move ahead. How stable is the current trunk version?
>>>
>>
>> It's pretty stable; starting to move towards getting a release out in the
>> next month or two.
>>
>> And, what's new in trunk is the JDO object store, which may (perhaps)
>> replace the SQL objectstore, at least in the short-term.
>>
>> Also, the v0.2.0 release holds an incomplete cut of the RO viewer (whatever
>> was implemented back in Feb).
>>
>> ~~~
>> If you do decide to track trunk, you might find it easiest to fork my
>> github copy of Isis [1]
>>
>>
>>
>>>
>>> I will have a closer look at the latest/trunk ro-applib. I guess
>>> RestfulRestfulClient is entry point to start from.
>>
>>
>> Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
>>
>> This lets you use either a HATEOAS or a templated URL approach.
>>
>>
>>
>>
>>> But to be able to use
>>> it I probably have to switch to using the trunk version.
>>>
>>
>> Not sure; I think you'll find that 0.2.0 does have something. Even so, I
>> do recommend that you switch to trunk
>>
>> >
>>
>>>> Speaking slightly selfishly, I'd love you to have a go with using the RO
>>>> applib; it'll help us determine where the gaps and annoyances are for
>>>> "real-life" use.
>>>
>>> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
>>> documentation still a good starting point? Since I am lazy ;-) I wonder
>>> if their exists some sample application already. This could give me a
>>> headstart.
>>>
>>
>> The tests aren't a bad place to look; you'll find these in
>> restfulobjects-tck.
>>
>> Admittedly, these have been knocked-about a bit and so quite a few are
>> currently are @Ignore'd. However,
>> the
>> org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
>> runs and passes. (It also uses the isisWebServerRule which bootstraps the
>> web.xml within an integration test).
>>
>> Hope that helps some
>>
>> Dan
>>
>> [1] https://github.com/danhaywood/apache-isis
>>
>
>
>
Re: Best way to interact with the JSON viewer
Posted by mi...@xup.nl.
Oh boy, this look complex.
The code in RO-tck looks like some sort of meta programming. I am
looking for a piece of code to create a new domain object using
RO-applib. But I have a hard time digesting what's there.
Can someone give me some more hints (hopefully a snippet)
Regards,
Minto
Quoting Dan Haywood <da...@haywood-associates.co.uk>:
> On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>
>>
>> Should stick with the current release
>> 0.2.0 or move ahead. How stable is the current trunk version?
>>
>
> It's pretty stable; starting to move towards getting a release out in the
> next month or two.
>
> And, what's new in trunk is the JDO object store, which may (perhaps)
> replace the SQL objectstore, at least in the short-term.
>
> Also, the v0.2.0 release holds an incomplete cut of the RO viewer (whatever
> was implemented back in Feb).
>
> ~~~
> If you do decide to track trunk, you might find it easiest to fork my
> github copy of Isis [1]
>
>
>
>>
>> I will have a closer look at the latest/trunk ro-applib. I guess
>> RestfulRestfulClient is entry point to start from.
>
>
> Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
>
> This lets you use either a HATEOAS or a templated URL approach.
>
>
>
>
>> But to be able to use
>> it I probably have to switch to using the trunk version.
>>
>
> Not sure; I think you'll find that 0.2.0 does have something. Even so, I
> do recommend that you switch to trunk
>
> >
>
>> > Speaking slightly selfishly, I'd love you to have a go with using the RO
>> > applib; it'll help us determine where the gaps and annoyances are for
>> > "real-life" use.
>>
>> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
>> documentation still a good starting point? Since I am lazy ;-) I wonder
>> if their exists some sample application already. This could give me a
>> headstart.
>>
>
> The tests aren't a bad place to look; you'll find these in
> restfulobjects-tck.
>
> Admittedly, these have been knocked-about a bit and so quite a few are
> currently are @Ignore'd. However,
> the
> org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
> runs and passes. (It also uses the isisWebServerRule which bootstraps the
> web.xml within an integration test).
>
> Hope that helps some
>
> Dan
>
> [1] https://github.com/danhaywood/apache-isis
>
Re: Best way to interact with the JSON viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>
> Should stick with the current release
> 0.2.0 or move ahead. How stable is the current trunk version?
>
It's pretty stable; starting to move towards getting a release out in the
next month or two.
And, what's new in trunk is the JDO object store, which may (perhaps)
replace the SQL objectstore, at least in the short-term.
Also, the v0.2.0 release holds an incomplete cut of the RO viewer (whatever
was implemented back in Feb).
~~~
If you do decide to track trunk, you might find it easiest to fork my
github copy of Isis [1]
>
> I will have a closer look at the latest/trunk ro-applib. I guess
> RestfulRestfulClient is entry point to start from.
Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
This lets you use either a HATEOAS or a templated URL approach.
> But to be able to use
> it I probably have to switch to using the trunk version.
>
Not sure; I think you'll find that 0.2.0 does have something. Even so, I
do recommend that you switch to trunk
>
> > Speaking slightly selfishly, I'd love you to have a go with using the RO
> > applib; it'll help us determine where the gaps and annoyances are for
> > "real-life" use.
>
> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
> documentation still a good starting point? Since I am lazy ;-) I wonder
> if their exists some sample application already. This could give me a
> headstart.
>
The tests aren't a bad place to look; you'll find these in
restfulobjects-tck.
Admittedly, these have been knocked-about a bit and so quite a few are
currently are @Ignore'd. However,
the org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
runs and passes. (It also uses the isisWebServerRule which bootstraps the
web.xml within an integration test).
Hope that helps some
Dan
[1] https://github.com/danhaywood/apache-isis
Re: Best way to interact with the JSON viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 1 September 2012 10:29, Minto van der sluis <mi...@xup.nl> wrote:
>
> Should stick with the current release
> 0.2.0 or move ahead. How stable is the current trunk version?
>
It's pretty stable; starting to move towards getting a release out in the
next month or two.
And, what's new in trunk is the JDO object store, which may (perhaps)
replace the SQL objectstore, at least in the short-term.
Also, the v0.2.0 release holds an incomplete cut of the RO viewer (whatever
was implemented back in Feb).
~~~
If you do decide to track trunk, you might find it easiest to fork my
github copy of Isis [1]
>
> I will have a closer look at the latest/trunk ro-applib. I guess
> RestfulRestfulClient is entry point to start from.
Yes, org.apache.isis.viewer.restfulobjects.applib.RestfulClient.
This lets you use either a HATEOAS or a templated URL approach.
> But to be able to use
> it I probably have to switch to using the trunk version.
>
Not sure; I think you'll find that 0.2.0 does have something. Even so, I
do recommend that you switch to trunk
>
> > Speaking slightly selfishly, I'd love you to have a go with using the RO
> > applib; it'll help us determine where the gaps and annoyances are for
> > "real-life" use.
>
> I could give it a try If I knew were to start. Is the 0.2.0 json viewer
> documentation still a good starting point? Since I am lazy ;-) I wonder
> if their exists some sample application already. This could give me a
> headstart.
>
The tests aren't a bad place to look; you'll find these in
restfulobjects-tck.
Admittedly, these have been knocked-about a bit and so quite a few are
currently are @Ignore'd. However,
the org.apache.isis.viewer.restfulobjects.tck.resources.home.HomePageResourceTest_accept
runs and passes. (It also uses the isisWebServerRule which bootstraps the
web.xml within an integration test).
Hope that helps some
Dan
[1] https://github.com/danhaywood/apache-isis
Re: Best way to interact with the JSON viewer
Posted by Minto van der sluis <mi...@xup.nl>.
Op 31-8-2012 19:50, Dan Haywood schreef:
> On 31 August 2012 12:32, Minto van der sluis <mi...@xup.nl> wrote:
>
>> Hi folks,
>>
>> I wonder what is the best way to interact with the rest interface for my
>> ISIS application.
>
>
> Quick correction on the subject: the json viewer is now called the
> restfulobjects viewer.
>
>
I guess this is the case for the comming release. Since the current docs
on http://incubator.apache.org/isis/documentation.html still mention
json viewer
This also makes me wonder if I should stick with the current release
0.2.0 or move ahead. How stable is the current trunk version?
>
>
>> Most information I could find mention interaction from
>> display technology like javascipt. In my case I need to interact server
>> side.
>>
>
> The intention is that the org.apache.isis.viewer : restfulobjects-applib
> ("RO Applib") will provide this capability.
>
> In fact, a large part of it is there and implemented; the main issue with
> the RO viewer and its applib is just that it is lagging behind the spec,
> and so only implementing v0.52 (or so), rather than the published v1.0.0
>
>
I will have a closer look at the latest/trunk ro-applib. I guess
RestfulRestfulClient is entry point to start from. But to be able to use
it I probably have to switch to using the trunk version.
Can I use the trunk ro-applib for the client and have my Isis
application still use the latest release version?
>>
>> Ofcourse there are numerous client side REST libraries to choose from.
>> However I am probably not the first one trying to do this for an ISIS
>> project. So I wondered how others are doing this and what's the best way
>> to move forward.
>>
>
> As Jeroen notes in his mail, it isn't necessary to use the RO applib.
> However, it is designed to be extensible in a number of ways. For
> example, the JsonRepresentation has "type-safe" subtypes for each of the
> specific representations, eg DomainObjectRepresentation. Or, it can just
> be used as a "bag" of nodes, and access those nodes using an Xpath-like
> notation. Since the applib (and viewer) is based on RestEasy, there's also
> support for templated URLs if you prefer to work in an RPC rather than
> HATEOAS style.
My case is similar to what Jeroen described. We also have an existing
application for which we intend to replace the backend as a proof of
concept.
>
> Speaking slightly selfishly, I'd love you to have a go with using the RO
> applib; it'll help us determine where the gaps and annoyances are for
> "real-life" use.
I could give it a try If I knew were to start. Is the 0.2.0 json viewer
documentation still a good starting point? Since I am lazy ;-) I wonder
if their exists some sample application already. This could give me a
headstart.
>
> Thx
> Dan
>
>
>
>>
>> Regards,
>>
>> Minto van der Sluis
>>
>>
>
--
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV
Mobiel: +31 (0) 626 014541
Re: Best way to interact with the JSON viewer
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 31 August 2012 12:32, Minto van der sluis <mi...@xup.nl> wrote:
> Hi folks,
>
> I wonder what is the best way to interact with the rest interface for my
> ISIS application.
Quick correction on the subject: the json viewer is now called the
restfulobjects viewer.
> Most information I could find mention interaction from
> display technology like javascipt. In my case I need to interact server
> side.
>
The intention is that the org.apache.isis.viewer : restfulobjects-applib
("RO Applib") will provide this capability.
In fact, a large part of it is there and implemented; the main issue with
the RO viewer and its applib is just that it is lagging behind the spec,
and so only implementing v0.52 (or so), rather than the published v1.0.0
>
> Ofcourse there are numerous client side REST libraries to choose from.
> However I am probably not the first one trying to do this for an ISIS
> project. So I wondered how others are doing this and what's the best way
> to move forward.
>
As Jeroen notes in his mail, it isn't necessary to use the RO applib.
However, it is designed to be extensible in a number of ways. For
example, the JsonRepresentation has "type-safe" subtypes for each of the
specific representations, eg DomainObjectRepresentation. Or, it can just
be used as a "bag" of nodes, and access those nodes using an Xpath-like
notation. Since the applib (and viewer) is based on RestEasy, there's also
support for templated URLs if you prefer to work in an RPC rather than
HATEOAS style.
Speaking slightly selfishly, I'd love you to have a go with using the RO
applib; it'll help us determine where the gaps and annoyances are for
"real-life" use.
Thx
Dan
>
> Regards,
>
> Minto van der Sluis
>
>