Hi Kai,
everything is Java based now:
please let me know what do you think. Especially this:
Could we make this method (ServerMessageDeliverer#findResource) protected in the future release? That would simplify it a lot. Or do you have any other ideas how to achieve this
behavior?
Thanks,
Michal
Hi Michal,
I like the idea of being able to register Resources with an annotation
containing the resource path.
However, your code seems to make use of Groovy specific features not
available in Java 7, e.g. in
PatternMatchingMessageDeliverer.findResource().
I would be very much interested in a "plain Java" implementation,
though.Â
--
Mit freundlichen GrÃÃen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
SchÃneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
On Sa, 2016-06-25 at 12:53 +0200, Michal Knizek wrote:
> Hi,
>
> I was playing with an idea of defining resourceÂmapping with regular
> expressions:
>
> https://github.com/macrosak/coap-server
>
> You can define routes like this:
>
> MessageDeliverer deliverer = new PatternMatchingMessageDeliverer()
> Â .registerResource(Pattern.compile("device/[^/]+/temperature"), new
> SensorsResource("temperature"));
>
> Or in a similar way to Spring RequestMapping:
>
> @CoapRequestMapping("land/people/[^/]+")
> class MagicMirrorResource extends CoapResource {
> Â // ...
> }
>
> This is just a proof of concept right now, but I would be grateful
> for any feedback.
>
> The actual implementation was super straight-forward. I just needed
> to change one method:
>
> org.eclipse.californium.core.server.ServerMessageDeliverer#findResour
> ce
>
> Since this method is private, I ended up copy-
> pastingÂServerMessageDeliverer implementation to a separate class:
>
> https://github.com/macrosak/coap-server/blob/master/src/main/groovy/c
> om/tado/coap/PatternMatchingMessageDeliverer.groovy
>
> Could we make this method protected in the future release? That would
> simplify it a lot. Or do you have any other ideas how to achieve this
> behavior?
>
> Best,
> Michal
