cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Razumovsky <>
Subject Re: [jira] Commented: (CAY-1312) Allow lifecycle callbacks on ROP client
Date Thu, 19 Nov 2009 09:50:50 GMT
I'm not sure I understand. DI can help to set EntityListenerFactory but how
would it help in this common case: to map listeners for usage on client?
This should be done in modeler without any extra code and configuration

2009/11/19 Andrus Adamchik <>

> On Nov 19, 2009, at 10:09 AM, Andrey Razumovsky (JIRA) wrote:
>  On Nov 19, 2009, at 12:42 AM, Ari Maniatis (JIRA) wrote:
>>> Just throwing this out as an idea: would users sometimes want to specify
>>> particular clients? For instance, you might have a data processing node
>>> which is different to a client GUI node or a (in the future) Cayenne aware
>>> Ajax node.
>>> If so, the schema would allow for this to be arbitrary text (not an
>>> enumeration), but the modeler would by default give you three options (as
>>> you specified) and maybe (later) a free entry text option.
>> Makes sense, but generating LifecyleCallbackRegistry for client should be
>> as simple as possible, i.e. without any extra parameters for connection.
>> How then shall we decide what listeners are sent to ROP client? Comparing
>> strings is not so safe as comparing enums. So I would suggest adding this
>> logic to a listener itself, e.g. adding checkings for client "type" in
>> callback method
> I think this problem is more general than that, and it will be hard to
> address it via the mapping.
> I am often running in a situation with server-side objects that require
> different sets of listeners in different applications using the same common
> mapping. In fact in many cases the listener class is defined outside the jar
> file containing the mapping, and is therefore available to some war's but
> not others.
> In 3.0 I am using EntityListenerFactory as a stop gap measure, but I want
> something easier to use... Again I am hoping that DI approach would allow
> for simple listener extensions.
> But I am unsure that we need to further complicate the mapping, since it
> makes it less reusable.
> Andrus


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message