On Dec 9, 2008, at 5:53 PM, Markus KARG wrote:
> Paul,
>
> currently no unit tests do exist but I will provide a sample that
> will use JPA to map WebDAV on a database. I agree that unit tests
> are valueable but I just have no idea what they shall actually test,
> since most of my code is purely declarative, while a unit test
> typically targets in testing an implementation (and it makes no
> sense to check whether JAXB is correctly working -- this is the job
> of JAXB's own unit test).
>
In this case we could view the unit tests as more functional and
create resource classes that utilize the WebDAV functionality and we
can use the client API. So in this case the unit test framework is
just a very useful mechanism for the automation and reporting of
tests. The jersey-test module is an example of such usage. Naresh is
working on a test-framework we should be able to reuse but for now we
could copy the testing classes we need from the jersey-test module.
> So for the process of contributing into Jersey's code base, I will
> write again in a few days asking for the technical process.
> Currently I am mavenizing my standalone project, filling code gaps
> and tidying up code (it's hard work to come to a clean generall
> purpose code when all what you did before was matching a *specific*
> use case).
OK.
>
> For the issue with the empty bodies: We need to find a solution
> since it's really a black spot on the overall great API. I think it
> would be not much a problem to convince everybody that it makes more
> sense to inject null instead of throwing a NullPointerException? :-)
Yes, i can see it both ways. Sometimes you want a null value to be
propagated and sometimes you do not and want a 400 response instead
(the latter probably being the most common i suspect).
One solution is to have a separate resource method for a request that
does not contain a request entity. Another could be to annotation the
request entity or the resource method that declares if there is not
content-type then the entity should be assigned a null value. I think
i prefer the latter solution.
Paul.
>
> Have Fun
> Markus
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Montag, 8. Dezember 2008 22:40
> To: dev_at_jersey.dev.java.net
> Subject: Re: [Jersey] JAX-RS based WebDAV support
>
> Hi Marcus,
>
> I am very supportive of such an contribution being part of the
> Jersey contribution source code base. There is no conflict. I think
> it would make a great addition, with the potential to build upon it.
>
> Do you plan to provide unit tests and some samples? I think both are
> important in terms of adoption and scaling (as the project gets
> larger it is not possible for one or two people to be experts in all
> areas).
>
> BTW the issue you logged is a known one [1]. I think we can work
> around it, but it also highlights a bug in the the 311 spec.
>
> Paul.
>
> [1] https://jersey.dev.java.net/issues/show_bug.cgi?id=145
>
> On Dec 6, 2008, at 3:34 PM, Markus KARG wrote:
>
>
> Dear Jersey Team,
>
> I have developed partial support for WebDAV based RESTful web
> services based on pure JAX-RS (not Jersey-dependent). It works
> pretty well and would be a good starting point for some kind of
> "official" WebDAV support package. If nobody else is working on
> something like that, I'd like to complete this package and
> contribute it to java.net.
>
> So I need to know two things of you:
>
> (a) Whether my contribution would conflict with WebDAV plannings of
> somebody else / the "official" Jersey plannings? If that would be
> the case, I'd see no sense in completing my contribution, obviously.
>
> (b) Whether my contribution shall become something like a "Jersey
> Sub-Project" or whether I shall go my own ways and open an
> "unrelated" top-level project?
>
> Please send me your opinions! I don't want to create a concurrency
> situation with Jersey, but I also don't want to wait for years until
> there is a complete JAX-RS WebDAV support elsewhere.
>
> Thanks
> Markus
>
>