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, <[email protected]> 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 [email protected]: > > 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 [email protected]: >> >> 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 [email protected]: >>> >>> 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 <[email protected]>**: >>>> >>>> On 1 September 2012 10:29, Minto van der sluis <[email protected]> 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> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >
