[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Pattern Matching Massage Deliverer
|
On Mi, 2016-06-29 at 15:35 +0200, Michal Knizek wrote:
> Hi Kai,
>
> everything is Java based now:
>
> https://github.com/macrosak/coap-server
>
Much better :-)
However, I have some concerns regarding the "pattern matching
algorithm" imposed by your approach of iterating over the key set.
It basically means that the first resource registered with a matching
pattern is returned. It doesn't consider "specificity" of the matched
pattern, i.e. a pattern of "/path/to/my/resource" has no precedence
over "/pa.*" but it simply depends on the order in which the patterns
are returned by the iterator for the key set, right?
The current implementation does try to find the most specific resource
for the given path ...
> 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?
>
We can certainly make the method protected. I do not see why we would
need to prevent subclassing here.
> 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#findReso
> > ur
> > > 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/groo
> > vy/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
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
