| Item |
Section |
Comment |
Response |
| 1 |
2.1 |
I think the scope should be defined in a better detail, i.e in terms of what to be monitored. I would recommend moving the following sentence from 4.1 to here: "The goal of this project..." |
Done. |
|
| 2 |
2.2 |
I do not understand the statement: "We should be able to manage lifecycle of resources(telemetry objects) we define". Later in 4.1 three options are mentioned for the module design and two of them do not include implementing your own telemetry objects. My suggestion would be to remove this sentence from 2.2 |
Please see response for 4. |
|
| 3 |
3.1 |
Since Jason is Java-platform based, i think it would be better to list e.g. perl, ruby, etc. |
Agree |
|
| 4 |
4.1 |
It is not clear, how the telemetry objects will look like, and you make assumptions, it would be possible to just annotate them with JAXB and JAX-RS related annotations. What i have seen so far was in fact interfaces and there it is not straightforward (please see e.g. here ). In addition you would need to gain control over the corresponding code, which would mean not really clear separation of modules. I would think it would be better to go with the delegation model you suggest bellow. Another thing is that in Jersey you register classes and not instances as web resources, so the idea of switching resources off and on based on tags on particular instances won't work (maybe i just misunderstood the idea). Overall it would be useful to distinguish between web resources (exposed at certain addresses/URIs) and their representations (actual data exchanged between client and server). I disagree the delegation model is not a pluggable solution, as you could plug it in (switch the REST interface on) and unplug it again (switch it off). |
When you provide class literals(example: myreource.class) to Jersey runtime to expose it as URL, Jersey manages the lifecycle of this object per request. In our case, monitoring object view hierarchy lifecycle is managed by monitoring infrastructure and we would like to handle over these objects to Jersey to expose as URLs. I was referring to Pluggability from third-party V3 module providers. But, I think you are right, its upto them how they want to expose thier objects. Through delegates or otherwise. |
|
| 5 |
4.3 |
WADL support is provided out-of-the-box in Jersey |
Great |
|
| 6 |
4.5 |
As i mentioned above (comment 4), interface description should contain not only URI->web resource mapping, but also information on representations provided by each resource. (Presuming the only allowed method in this context is GET) |
Added example of return response. |
