[Bug 2052] API: Avoid ever creating Request objects without a receiver

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2052

Jon VanAlten <jon.vanalten at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jon.vanalten at redhat.com

--- Comment #1 from Jon VanAlten <jon.vanalten at redhat.com> ---
(In reply to Omair Majid from comment #0)
> The Request API currently allows the creation of requests without a
> receiever. The agent encounters a NullPointerException when it tries to
> handle them, and no reply (not even ERROR) is ever sent to the client. In my
> test, the client hung until I killed it.
> 

As an immediate, API-preserving measure that we can consider even before 2.0, I
would be all for adding some sanity check for this in RequestQueueImpl, and
sending Error response to any listeners without even needing to go over the
wire.  A check at the agent side also seems appropriate.

> A Request without a receiver set is essentially a mistake by the developer
> trying to use the Request API. We should try and limit such mistakes. Each
> Request object requires a target (in the constructor); it should also
> require a receiver.
> 

That does sound reasonable.  As a nit, the target is not currently *strictly*
required (we don't do null check).  If we add this to the constructor, we
should probably do null checks there.

> On a slightly different note, should a receiver be part of the request API
> at all? Seems more flexible if anything that wants to handle a request can
> handle it.

What would such flexibility offer to plugin developers?

I can think of one pitfall.  Someone implementing a plugin that requires
command channel will not be able to know whether the Request that they create
on the client side will have side effects above and beyond the actions of the
RequestHandler that they implement on the agent side.  This sort of scares me,
and unless there is some practical reason I would prefer if the
destination/handler remains explicit.  It would also require on the agent side,
to go through *all* of the registered handlers to try and handle requests,
which seems wasteful.

That said, maybe there is some nicer way of communicating the intended
destination/handler?  I really just tried to keep it simple, look up receiver
as OSGi service by class name.  It would really be a semantic difference, but
we could create some property other than class name.  Whether we do that or
not, it might also be worthwhile to change ReceiverRegistry so that it enforces
uniqueness.  Right now, unless I am missing something, any RequestHandler can
be registered to a given class name; this means that more than one such Handler
can be registered, and we just arbitrarily take the first one that OSGi runtime
gives us when we go and look it up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141027/e7f8f8b9/attachment-0001.html>