You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by "Thomas G. Schuessler" <tg...@arasoft.de> on 2011/08/06 14:18:16 UTC
Invoking an HTTP POST service that returns a value object, not a
URL
Executing a PostQuery returns a URL, but I need a way to invoke a service
that does not strictly follow the REST philosophy. The service returns - on
successful completion of the insert - an instance (JSON) of the created
object.
The documentation states:
"Pivot web queries are designed primarily to facilitate interaction with
JSON-based REST services. However, they are sufficiently generic to support
communication with any type of HTTP-based service, using any data format
(for example, XML). This renders the classes in the org.apache.pivot.web
package applicable to a broad range of server communication scenarios."
How do I proceed? Do I have to write my own subclass of Query? Or is there
some other way of accessing existing Web Service APIs that are not totally
RESTy?
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
>I haven't worked with Jersey so I can't really comment. Anyone else?
me too, so I can propose to Thomas to start prototype something to interact
with Jersey, and report to us if there is something in Pivot that's blocking
its usage, so we can see what to do ...
Or if have time to create a minimal prototype so we can play/test it better.
I can try to setup but at the moment I haven't time, sorry.
Probably create a simple java project with Maven could help to simplify the
setup/dependency phase and even the run server and client ...
Bye
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3235670.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
>>> If so, it might be possible to lift the restriction on line 469 that
>>> requires a GET request in order to return data. Does anyone know if it
>>> is
>>> possible to determine if a request contains a response body? Perhaps
>>> that
>>> check could be used to gate the if block instead of method ==
>>> Method.GET.
>>>
>> Might getContentLength() help?
>
>I don't believe a server is required to set that field, so it probably
wouldn't be 100% reliable, but might be >sufficient.
Any objection to make this little change for 2.0.2 (and related ticket) ?
BUT NOT without a test case (Jersey or not) ...
Bye
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3245500.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object,
not a URL
Posted by Greg Brown <gk...@verizon.net>.
>> If so, it might be possible to lift the restriction on line 469 that
>> requires a GET request in order to return data. Does anyone know if it is
>> possible to determine if a request contains a response body? Perhaps that
>> check could be used to gate the if block instead of method == Method.GET.
>>
> Might getContentLength() help?
I don't believe a server is required to set that field, so it probably wouldn't be 100% reliable, but might be sufficient.
> In the meantime I have tried out the Jersey client library. Everything I
> need works fine. Would it make sense to consider using Jersey with Pivot?
> What would need to be done to have the same level of integration as
> available for Pivot.Query (notifying listeners etc.)?
I haven't worked with Jersey so I can't really comment. Anyone else?
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by "Thomas G. Schuessler" <tg...@arasoft.de>.
gk_brown@verizon.net wrote:
>
> I forgot about one other important aspect of this. Query only defines a
> single serializer property. Currently, that serializer is used to read
> GETs and write POSTs and PUTs. Will you be able to use a single serializer
> to address your use case? I imagine so, since Serializer defines both
> readObject() and writeObject(), but I just wanted to make sure.
>
I do not foresee any problems.
gk_brown@verizon.net wrote:
>
> If so, it might be possible to lift the restriction on line 469 that
> requires a GET request in order to return data. Does anyone know if it is
> possible to determine if a request contains a response body? Perhaps that
> check could be used to gate the if block instead of method == Method.GET.
>
Might getContentLength() help?
In the meantime I have tried out the Jersey client library. Everything I
need works fine. Would it make sense to consider using Jersey with Pivot?
What would need to be done to have the same level of integration as
available for Pivot.Query (notifying listeners etc.)?
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3235577.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object,
not a URL
Posted by Greg Brown <gk...@verizon.net>.
I forgot about one other important aspect of this. Query only defines a single serializer property. Currently, that serializer is used to read GETs and write POSTs and PUTs. Will you be able to use a single serializer to address your use case? I imagine so, since Serializer defines both readObject() and writeObject(), but I just wanted to make sure.
If so, it might be possible to lift the restriction on line 469 that requires a GET request in order to return data. Does anyone know if it is possible to determine if a request contains a response body? Perhaps that check could be used to gate the if block instead of method == Method.GET.
G
On Aug 6, 2011, at 9:49 AM, Thomas G. Schuessler wrote:
>
> gk_brown@verizon.net wrote:
>>
>> Yes, but this shouldn't be too difficult. You can probably use the
>> existing GetQuery and PostQuery classes as a guide. Let us know if you
>> have any questions.
>>
>
> Below please see my first non-working humble attempt. The problem is here:
>
> inputStream = connection.getInputStream();
>
> I cannot access the connection since it is local to Query's execute method.
> The only ways I can think of to fix this, are:
> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not call
> the inherited method at all.
> 2. Create my own abstract Query class and subclass that.
>
> Both choices seem to come with maintenance issues for future releases of
> Pivot...
>
> Any alternatives I have overlooked? If not, would you choose 1 or 2?
>
> --------------------------------------------
> package pivot.test;
>
> import java.io.InputStream;
> import java.util.concurrent.ExecutorService;
>
> import org.apache.pivot.json.JSONSerializer;
> import org.apache.pivot.serialization.Serializer;
> import org.apache.pivot.web.Query;
> import org.apache.pivot.web.QueryException;
>
> public class MyPostQuery extends Query {
> public static final Method METHOD = Method.POST;
>
> private Object value = null;
> private Serializer<?> serializer = new JSONSerializer();
>
> public MyPostQuery(String hostname, String path) {
> this(hostname, DEFAULT_PORT, path, false);
> }
>
> public MyPostQuery(String hostname, int port, String path, boolean secure)
> {
> this(hostname, port, path, secure, DEFAULT_EXECUTOR_SERVICE);
> }
>
> public MyPostQuery(String hostname, int port, String path, boolean secure,
> ExecutorService executorService) {
> super(hostname, port, path, secure, executorService);
> }
>
> @Override
> public Method getMethod() {
> return METHOD;
> }
>
> public Object getValue() {
> return this.value;
> }
>
> public void setValue(Object value) {
> this.value = value;
> }
>
> @Override
> public Object execute() throws QueryException {
> execute(METHOD, this.value);
> if (getStatus() == Status.CREATED) {
> InputStream inputStream = null;
> try {
> inputStream = connection.getInputStream();
> this.value = this.serializer.readObject(new MonitoredInputStream(
> inputStream));
> } finally {
> if (inputStream != null) {
> inputStream.close();
> }
> }
>
> }
> return this.value;
> }
>
> }
>
>
> --
> View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3231076.html
> Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object,
not a URL
Posted by Greg Brown <gk...@verizon.net>.
As Bill noted, we intentionally took the conservative approach of making things private until we discovered a need to make them protected. I personally think it makes sense to continue with that philosophy as it help to limit the surface area of the APIs.
G
On Aug 8, 2011, at 5:03 AM, Chris Bartlett wrote:
> Valid points there, Roger. I don't think there will be a single
> solution to apply to all Pivot classes for the reasons you state.
>
> Some classes, like the previously mentioned MessageBus could be
> changed easily with low risk. The change might be to make the class
> final, make the HashMap protected or to add a protected getter for the
> HashMap. However a user could easily copy the source of this class,
> rename it and just use their version if they wanted to.
> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
>
> I think I am right in saying that the provided Skins classes are
> intended to be subclassed, so they might have some or all of their
> private methods & fields changed to protected.
>
> There will be plenty of others that fall between these two extremes
> which will not be so obvious.
>
> For example, the Resources class is used by BXMLSerializer to provide
> locale based text localization so cannot just be replaced by a custom
> version made from a copy of the source code. Extending it would be
> much easier if the 'resourceMap' field was protected or had a
> public/protected accessor. If the class is not meant to be extended,
> then marking it as final more clearly communicates that fact, and
> therefore that Pivot Resources must be JSON on the classpath, as there
> is no way to provide an alternate implementation.
> http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/Resources.java
>
> If we were to mark any public classes as final now, it would be a
> breaking change for any code that currently does extend them. Making
> the fields/methods more accessible would be far less disruptive, but
> implies that the classes are *intended* to be subclassed.
>
> As I mentioned in my earlier email, I think that such expectations can
> be managed/limited via documentation. I wouldn't feel much sympathy
> for a developer who extends a class without reading its documentation
> first, and then gets caught out later when a necessary change affects
> them.
>
>
> On 8 August 2011 11:06, Roger and Beth Whitcomb
> <Ro...@rbwhitcomb.com> wrote:
>> This is an issue we have been wrestling with in our code, because we
>> implemented a "Tools API", which is a public contract, really, that if it
>> were to be used by outside developers would mean we would have to maintain
>> compatibility over the long term. At this point we're not ready (nor
>> equipped) to do that, so we chose to not make the API public right now.
>>
>> So, I think similar questions could be asked here:
>> - Are the classes sufficiently stable so that we could reasonably make a
>> contract with future users that "protected" fields are not going to change?
>> - How much risk is there to limiting future change due to user applications
>> depending on what may become vestigial members/methods?
>> - How much additional (really useful) functionality would be made available
>> by allowing the classes to be extended?
>> - How much work is it for users to have to copy/reinvent things if we don't
>> allow extensions?
>>
>> I don't know the answers, but these are some of the questions we have been
>> asking about our own APIs....
>>
>>
>> On 8/7/11 3:06 AM, Chris Bartlett wrote:
>>>
>>> (This discussion could perhaps be moved to its own thread, but for now
>>> I will continue here)
>>>
>>> I feel the same way as Sandro regarding making Pivot classes easily
>>> extendible unless there is a good reason not to. Classes that are not
>>> meant to be extended should be marked as 'final' to signal the intent
>>> clearly, especially when there are limited Javadocs. Leaving classes
>>> non-final makes the API look unfinished IMO as there are times when
>>> the only things you would ever need in a subclass are the things
>>> marked private and therefore inaccessible to you.
>>>
>>> It would only need a few lines of documentation in the FAQ and
>>> Javadocs to explain that Pivot has chosen to allow its classes to be
>>> more easily extended rather than defaulting to making all methods&
>>> fields private. This could include a note to say that the API is
>>> still evolving and there may be changes later that could affect custom
>>> subclasses of Pivot classes, but the choice was made to help Pivot
>>> consumers get the most benefit out of the code in the library.
>>>
>>> There are many Pivot classes that *can* be extended because they are
>>> non-final, but which are very hard to meaningfully extend because of
>>> the private fields& methods. I mentioned
>>> org.apache.pivot.util.MessageBus and org.apache.pivot.util.Resources
>>> on the Dev mailing list recently, but Component Skins are a problem
>>> too. They contain a lot of private fields& methods which means that
>>> it is often easier (or the only option) to copy an entire Skin class
>>> and make changes in the copy rather than trying to extend the
>>> original, especially if painting is involved.
>>>
>>> (Threads mentioned above)
>>>
>>> http://apache-pivot-developers.417237.n3.nabble.com/org-apache-pivot-util-MessageBus-td3151762.html
>>>
>>> http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-org-apache-pivot-util-Resources-localization-td3156467.html
>>>
>>> If anyone else feels strongly about this (either 'for', or 'against'
>>> changes) then please let us know. If there is a desire for change,
>>> then it might happen, but I don't think it will happen unless it is
>>> requested.
>>>
>>> Chris
>>>
>>> On 7 August 2011 04:43, Sandro Martini<sa...@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>> if you have some real use case that require to change a little some Pivot
>>>> classes (even that could change a little its API) maybe a JIRA ticket for
>>>> our 2.1 release could be useful.
>>>>
>>>> My point of view is to enable users to extend Pivot where needed.
>>>> And Greg likes real use cases before changing anything in Pivot ... so
>>>> write
>>>> them (and if possible put even a reference to this thread).
>>>>
>>>> Bye
>>>>
>>>> Il giorno 06/ago/2011 20:05, "Bill van Melle"<bi...@gmail.com>
>>>> ha
>>>> scritto:
>>>>>
>>>>> I remember facing a similar question when I wanted to add an http
>>>>> timeout to GetQuery. These classes could be much more usefully
>>>>> extended if some of their important locals were marked protected
>>>>> instead of private. (Not that it's an easy decision to know when to
>>>>> do that when you're implementing the base class. Pivot seems to take
>>>>> the conservative approach of marking everything private for which
>>>>> Pivot does not itself have a subclass that wants access.)
>>>>>
>>>>> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler<tg...@arasoft.de>
>>>>> wrote:
>>>>>>
>>>>>> I cannot access the connection since it is local to Query's execute
>>>>>> method.
>>>>>> The only ways I can think of to fix this, are:
>>>>>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not
>>>>>> call
>>>>>> the inherited method at all.
>>>>>> 2. Create my own abstract Query class and subclass that.
>>>
>>
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
in my opinion, Pivot API are almost stable, but as Chris I think there
should be some changes to enable/disable subclassing, but for the 2.1.x.
So I think it's natural to expect that in the 2.1 some incompatible change
will happen (this is the main reason for the little change in numbers), but
not-so-big things. But note that with this I don't want to generate anxiety
... at the moment all is under discussion, and all changes are mostly
experimental and to have more features inside Pivot.
Note that some of these changes are not committed, or even committed in some
of our apache-extrax projects, like the validators extensions, etc ... and
maybe some of these changes could even stay forever outside Pivot sources
(this is another question to see, but we have next months to see what to do
:-) ), BUT the important thing here is to see if/how change Pivot to be able
to have have them (if Pivot team say that are valid extensions of course).
Bye
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3235140.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object, not a URL
Posted by Chris Bartlett <cb...@gmail.com>.
Valid points there, Roger. I don't think there will be a single
solution to apply to all Pivot classes for the reasons you state.
Some classes, like the previously mentioned MessageBus could be
changed easily with low risk. The change might be to make the class
final, make the HashMap protected or to add a protected getter for the
HashMap. However a user could easily copy the source of this class,
rename it and just use their version if they wanted to.
http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/MessageBus.java
I think I am right in saying that the provided Skins classes are
intended to be subclassed, so they might have some or all of their
private methods & fields changed to protected.
There will be plenty of others that fall between these two extremes
which will not be so obvious.
For example, the Resources class is used by BXMLSerializer to provide
locale based text localization so cannot just be replaced by a custom
version made from a copy of the source code. Extending it would be
much easier if the 'resourceMap' field was protected or had a
public/protected accessor. If the class is not meant to be extended,
then marking it as final more clearly communicates that fact, and
therefore that Pivot Resources must be JSON on the classpath, as there
is no way to provide an alternate implementation.
http://svn.apache.org/repos/asf/pivot/trunk/core/src/org/apache/pivot/util/Resources.java
If we were to mark any public classes as final now, it would be a
breaking change for any code that currently does extend them. Making
the fields/methods more accessible would be far less disruptive, but
implies that the classes are *intended* to be subclassed.
As I mentioned in my earlier email, I think that such expectations can
be managed/limited via documentation. I wouldn't feel much sympathy
for a developer who extends a class without reading its documentation
first, and then gets caught out later when a necessary change affects
them.
On 8 August 2011 11:06, Roger and Beth Whitcomb
<Ro...@rbwhitcomb.com> wrote:
> This is an issue we have been wrestling with in our code, because we
> implemented a "Tools API", which is a public contract, really, that if it
> were to be used by outside developers would mean we would have to maintain
> compatibility over the long term. At this point we're not ready (nor
> equipped) to do that, so we chose to not make the API public right now.
>
> So, I think similar questions could be asked here:
> - Are the classes sufficiently stable so that we could reasonably make a
> contract with future users that "protected" fields are not going to change?
> - How much risk is there to limiting future change due to user applications
> depending on what may become vestigial members/methods?
> - How much additional (really useful) functionality would be made available
> by allowing the classes to be extended?
> - How much work is it for users to have to copy/reinvent things if we don't
> allow extensions?
>
> I don't know the answers, but these are some of the questions we have been
> asking about our own APIs....
>
>
> On 8/7/11 3:06 AM, Chris Bartlett wrote:
>>
>> (This discussion could perhaps be moved to its own thread, but for now
>> I will continue here)
>>
>> I feel the same way as Sandro regarding making Pivot classes easily
>> extendible unless there is a good reason not to. Classes that are not
>> meant to be extended should be marked as 'final' to signal the intent
>> clearly, especially when there are limited Javadocs. Leaving classes
>> non-final makes the API look unfinished IMO as there are times when
>> the only things you would ever need in a subclass are the things
>> marked private and therefore inaccessible to you.
>>
>> It would only need a few lines of documentation in the FAQ and
>> Javadocs to explain that Pivot has chosen to allow its classes to be
>> more easily extended rather than defaulting to making all methods&
>> fields private. This could include a note to say that the API is
>> still evolving and there may be changes later that could affect custom
>> subclasses of Pivot classes, but the choice was made to help Pivot
>> consumers get the most benefit out of the code in the library.
>>
>> There are many Pivot classes that *can* be extended because they are
>> non-final, but which are very hard to meaningfully extend because of
>> the private fields& methods. I mentioned
>> org.apache.pivot.util.MessageBus and org.apache.pivot.util.Resources
>> on the Dev mailing list recently, but Component Skins are a problem
>> too. They contain a lot of private fields& methods which means that
>> it is often easier (or the only option) to copy an entire Skin class
>> and make changes in the copy rather than trying to extend the
>> original, especially if painting is involved.
>>
>> (Threads mentioned above)
>>
>> http://apache-pivot-developers.417237.n3.nabble.com/org-apache-pivot-util-MessageBus-td3151762.html
>>
>> http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-org-apache-pivot-util-Resources-localization-td3156467.html
>>
>> If anyone else feels strongly about this (either 'for', or 'against'
>> changes) then please let us know. If there is a desire for change,
>> then it might happen, but I don't think it will happen unless it is
>> requested.
>>
>> Chris
>>
>> On 7 August 2011 04:43, Sandro Martini<sa...@gmail.com> wrote:
>>>
>>> Hi all,
>>> if you have some real use case that require to change a little some Pivot
>>> classes (even that could change a little its API) maybe a JIRA ticket for
>>> our 2.1 release could be useful.
>>>
>>> My point of view is to enable users to extend Pivot where needed.
>>> And Greg likes real use cases before changing anything in Pivot ... so
>>> write
>>> them (and if possible put even a reference to this thread).
>>>
>>> Bye
>>>
>>> Il giorno 06/ago/2011 20:05, "Bill van Melle"<bi...@gmail.com>
>>> ha
>>> scritto:
>>>>
>>>> I remember facing a similar question when I wanted to add an http
>>>> timeout to GetQuery. These classes could be much more usefully
>>>> extended if some of their important locals were marked protected
>>>> instead of private. (Not that it's an easy decision to know when to
>>>> do that when you're implementing the base class. Pivot seems to take
>>>> the conservative approach of marking everything private for which
>>>> Pivot does not itself have a subclass that wants access.)
>>>>
>>>> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler<tg...@arasoft.de>
>>>> wrote:
>>>>>
>>>>> I cannot access the connection since it is local to Query's execute
>>>>> method.
>>>>> The only ways I can think of to fix this, are:
>>>>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not
>>>>> call
>>>>> the inherited method at all.
>>>>> 2. Create my own abstract Query class and subclass that.
>>
>
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by Roger and Beth Whitcomb <Ro...@rbwhitcomb.com>.
This is an issue we have been wrestling with in our code, because we
implemented a "Tools API", which is a public contract, really, that if
it were to be used by outside developers would mean we would have to
maintain compatibility over the long term. At this point we're not
ready (nor equipped) to do that, so we chose to not make the API public
right now.
So, I think similar questions could be asked here:
- Are the classes sufficiently stable so that we could reasonably make a
contract with future users that "protected" fields are not going to change?
- How much risk is there to limiting future change due to user
applications depending on what may become vestigial members/methods?
- How much additional (really useful) functionality would be made
available by allowing the classes to be extended?
- How much work is it for users to have to copy/reinvent things if we
don't allow extensions?
I don't know the answers, but these are some of the questions we have
been asking about our own APIs....
On 8/7/11 3:06 AM, Chris Bartlett wrote:
> (This discussion could perhaps be moved to its own thread, but for now
> I will continue here)
>
> I feel the same way as Sandro regarding making Pivot classes easily
> extendible unless there is a good reason not to. Classes that are not
> meant to be extended should be marked as 'final' to signal the intent
> clearly, especially when there are limited Javadocs. Leaving classes
> non-final makes the API look unfinished IMO as there are times when
> the only things you would ever need in a subclass are the things
> marked private and therefore inaccessible to you.
>
> It would only need a few lines of documentation in the FAQ and
> Javadocs to explain that Pivot has chosen to allow its classes to be
> more easily extended rather than defaulting to making all methods&
> fields private. This could include a note to say that the API is
> still evolving and there may be changes later that could affect custom
> subclasses of Pivot classes, but the choice was made to help Pivot
> consumers get the most benefit out of the code in the library.
>
> There are many Pivot classes that *can* be extended because they are
> non-final, but which are very hard to meaningfully extend because of
> the private fields& methods. I mentioned
> org.apache.pivot.util.MessageBus and org.apache.pivot.util.Resources
> on the Dev mailing list recently, but Component Skins are a problem
> too. They contain a lot of private fields& methods which means that
> it is often easier (or the only option) to copy an entire Skin class
> and make changes in the copy rather than trying to extend the
> original, especially if painting is involved.
>
> (Threads mentioned above)
> http://apache-pivot-developers.417237.n3.nabble.com/org-apache-pivot-util-MessageBus-td3151762.html
> http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-org-apache-pivot-util-Resources-localization-td3156467.html
>
> If anyone else feels strongly about this (either 'for', or 'against'
> changes) then please let us know. If there is a desire for change,
> then it might happen, but I don't think it will happen unless it is
> requested.
>
> Chris
>
> On 7 August 2011 04:43, Sandro Martini<sa...@gmail.com> wrote:
>> Hi all,
>> if you have some real use case that require to change a little some Pivot
>> classes (even that could change a little its API) maybe a JIRA ticket for
>> our 2.1 release could be useful.
>>
>> My point of view is to enable users to extend Pivot where needed.
>> And Greg likes real use cases before changing anything in Pivot ... so write
>> them (and if possible put even a reference to this thread).
>>
>> Bye
>>
>> Il giorno 06/ago/2011 20:05, "Bill van Melle"<bi...@gmail.com> ha
>> scritto:
>>> I remember facing a similar question when I wanted to add an http
>>> timeout to GetQuery. These classes could be much more usefully
>>> extended if some of their important locals were marked protected
>>> instead of private. (Not that it's an easy decision to know when to
>>> do that when you're implementing the base class. Pivot seems to take
>>> the conservative approach of marking everything private for which
>>> Pivot does not itself have a subclass that wants access.)
>>>
>>> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler<tg...@arasoft.de>
>>> wrote:
>>>> I cannot access the connection since it is local to Query's execute
>>>> method.
>>>> The only ways I can think of to fix this, are:
>>>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not
>>>> call
>>>> the inherited method at all.
>>>> 2. Create my own abstract Query class and subclass that.
>
Re: Invoking an HTTP POST service that returns a value object, not a URL
Posted by Chris Bartlett <cb...@gmail.com>.
(This discussion could perhaps be moved to its own thread, but for now
I will continue here)
I feel the same way as Sandro regarding making Pivot classes easily
extendible unless there is a good reason not to. Classes that are not
meant to be extended should be marked as 'final' to signal the intent
clearly, especially when there are limited Javadocs. Leaving classes
non-final makes the API look unfinished IMO as there are times when
the only things you would ever need in a subclass are the things
marked private and therefore inaccessible to you.
It would only need a few lines of documentation in the FAQ and
Javadocs to explain that Pivot has chosen to allow its classes to be
more easily extended rather than defaulting to making all methods &
fields private. This could include a note to say that the API is
still evolving and there may be changes later that could affect custom
subclasses of Pivot classes, but the choice was made to help Pivot
consumers get the most benefit out of the code in the library.
There are many Pivot classes that *can* be extended because they are
non-final, but which are very hard to meaningfully extend because of
the private fields & methods. I mentioned
org.apache.pivot.util.MessageBus and org.apache.pivot.util.Resources
on the Dev mailing list recently, but Component Skins are a problem
too. They contain a lot of private fields & methods which means that
it is often easier (or the only option) to copy an entire Skin class
and make changes in the copy rather than trying to extend the
original, especially if painting is involved.
(Threads mentioned above)
http://apache-pivot-developers.417237.n3.nabble.com/org-apache-pivot-util-MessageBus-td3151762.html
http://apache-pivot-developers.417237.n3.nabble.com/Some-thoughts-on-org-apache-pivot-util-Resources-localization-td3156467.html
If anyone else feels strongly about this (either 'for', or 'against'
changes) then please let us know. If there is a desire for change,
then it might happen, but I don't think it will happen unless it is
requested.
Chris
On 7 August 2011 04:43, Sandro Martini <sa...@gmail.com> wrote:
> Hi all,
> if you have some real use case that require to change a little some Pivot
> classes (even that could change a little its API) maybe a JIRA ticket for
> our 2.1 release could be useful.
>
> My point of view is to enable users to extend Pivot where needed.
> And Greg likes real use cases before changing anything in Pivot ... so write
> them (and if possible put even a reference to this thread).
>
> Bye
>
> Il giorno 06/ago/2011 20:05, "Bill van Melle" <bi...@gmail.com> ha
> scritto:
>> I remember facing a similar question when I wanted to add an http
>> timeout to GetQuery. These classes could be much more usefully
>> extended if some of their important locals were marked protected
>> instead of private. (Not that it's an easy decision to know when to
>> do that when you're implementing the base class. Pivot seems to take
>> the conservative approach of marking everything private for which
>> Pivot does not itself have a subclass that wants access.)
>>
>> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler <tg...@arasoft.de>
>> wrote:
>>> I cannot access the connection since it is local to Query's execute
>>> method.
>>> The only ways I can think of to fix this, are:
>>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not
>>> call
>>> the inherited method at all.
>>> 2. Create my own abstract Query class and subclass that.
>
Re: Invoking an HTTP POST service that returns a value object, not a URL
Posted by Sandro Martini <sa...@gmail.com>.
Hi all,
if you have some real use case that require to change a little some Pivot
classes (even that could change a little its API) maybe a JIRA ticket for
our 2.1 release could be useful.
My point of view is to enable users to extend Pivot where needed.
And Greg likes real use cases before changing anything in Pivot ... so write
them (and if possible put even a reference to this thread).
Bye
Il giorno 06/ago/2011 20:05, "Bill van Melle" <bi...@gmail.com> ha
scritto:
> I remember facing a similar question when I wanted to add an http
> timeout to GetQuery. These classes could be much more usefully
> extended if some of their important locals were marked protected
> instead of private. (Not that it's an easy decision to know when to
> do that when you're implementing the base class. Pivot seems to take
> the conservative approach of marking everything private for which
> Pivot does not itself have a subclass that wants access.)
>
> On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler <tg...@arasoft.de>
wrote:
>> I cannot access the connection since it is local to Query's execute
method.
>> The only ways I can think of to fix this, are:
>> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not
call
>> the inherited method at all.
>> 2. Create my own abstract Query class and subclass that.
Re: Invoking an HTTP POST service that returns a value object, not a URL
Posted by Bill van Melle <bi...@gmail.com>.
I remember facing a similar question when I wanted to add an http
timeout to GetQuery. These classes could be much more usefully
extended if some of their important locals were marked protected
instead of private. (Not that it's an easy decision to know when to
do that when you're implementing the base class. Pivot seems to take
the conservative approach of marking everything private for which
Pivot does not itself have a subclass that wants access.)
On Sat, Aug 6, 2011 at 6:49 AM, Thomas G. Schuessler <tg...@arasoft.de> wrote:
> I cannot access the connection since it is local to Query's execute method.
> The only ways I can think of to fix this, are:
> 1. Copy the complete Query.execute, modify it in MyPostQuery, and not call
> the inherited method at all.
> 2. Create my own abstract Query class and subclass that.
Re: Invoking an HTTP POST service that returns a value object, not
a URL
Posted by "Thomas G. Schuessler" <tg...@arasoft.de>.
gk_brown@verizon.net wrote:
>
> Yes, but this shouldn't be too difficult. You can probably use the
> existing GetQuery and PostQuery classes as a guide. Let us know if you
> have any questions.
>
Below please see my first non-working humble attempt. The problem is here:
inputStream = connection.getInputStream();
I cannot access the connection since it is local to Query's execute method.
The only ways I can think of to fix this, are:
1. Copy the complete Query.execute, modify it in MyPostQuery, and not call
the inherited method at all.
2. Create my own abstract Query class and subclass that.
Both choices seem to come with maintenance issues for future releases of
Pivot...
Any alternatives I have overlooked? If not, would you choose 1 or 2?
--------------------------------------------
package pivot.test;
import java.io.InputStream;
import java.util.concurrent.ExecutorService;
import org.apache.pivot.json.JSONSerializer;
import org.apache.pivot.serialization.Serializer;
import org.apache.pivot.web.Query;
import org.apache.pivot.web.QueryException;
public class MyPostQuery extends Query {
public static final Method METHOD = Method.POST;
private Object value = null;
private Serializer<?> serializer = new JSONSerializer();
public MyPostQuery(String hostname, String path) {
this(hostname, DEFAULT_PORT, path, false);
}
public MyPostQuery(String hostname, int port, String path, boolean secure)
{
this(hostname, port, path, secure, DEFAULT_EXECUTOR_SERVICE);
}
public MyPostQuery(String hostname, int port, String path, boolean secure,
ExecutorService executorService) {
super(hostname, port, path, secure, executorService);
}
@Override
public Method getMethod() {
return METHOD;
}
public Object getValue() {
return this.value;
}
public void setValue(Object value) {
this.value = value;
}
@Override
public Object execute() throws QueryException {
execute(METHOD, this.value);
if (getStatus() == Status.CREATED) {
InputStream inputStream = null;
try {
inputStream = connection.getInputStream();
this.value = this.serializer.readObject(new MonitoredInputStream(
inputStream));
} finally {
if (inputStream != null) {
inputStream.close();
}
}
}
return this.value;
}
}
--
View this message in context: http://apache-pivot-users.399431.n3.nabble.com/Invoking-an-HTTP-POST-service-that-returns-a-value-object-not-a-URL-tp3230971p3231076.html
Sent from the Apache Pivot - Users mailing list archive at Nabble.com.
Re: Invoking an HTTP POST service that returns a value object,
not a URL
Posted by Greg Brown <gk...@verizon.net>.
> Executing a PostQuery returns a URL, but I need a way to invoke a service
> that does not strictly follow the REST philosophy. The service returns - on
> successful completion of the insert - an instance (JSON) of the created object.
> ...
> How do I proceed? Do I have to write my own subclass of Query?
Yes, but this shouldn't be too difficult. You can probably use the existing GetQuery and PostQuery classes as a guide. Let us know if you have any questions.
G