Home » Modeling » EMF » [CDO] Event Notification procedure
| [CDO] Event Notification procedure [message #494458] |
Fri, 30 October 2009 17:30  |
 Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Hi Víctor and everybody.
I've been taking a deeper look on the locks notification issue. I'm,
however, very new to CDO, so I haven't been able able to grasp it
completely just yet.
What I was able to figure out is, parting from the editor (the objective
is to somehow graphically indicate that objects are being locked by
other sessions), I can do:
-editor.getView().getSession() and get the session (and from there
getRemoteSessionManager() and get the manager that knows about all
sessions, which I guess this is not of great use to me).
-I can also get, from the CDOEditor, the CDOEventHandler, which has its
own IListeners.
Recalling, the final intention is to notify/get notified that a lock has
been obtained on some model element.
My current idea (without great knowledge of CDO's architecture) of how
things should go:
1) Define my new type of IEvent (perhaps more than one, LockEvent (Read
and Write) and ReleaseLockEvent, I have to think deeper on that).
2) Make my CDOSession fire these events (as in fireInvalidationEvent). I
believe they should be fired from
"CDOSessionImpl.acquireAtomicRequestLock()" and
"CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
CDOSession interface).
3) Check for these events in my editor's EventHandler (by subclassing
CDOEventHandler and adding a new "IListener lockEventListener", perhaps).
And then some doubts arise (thanks again to my short knowledge of CDO):
May I assume that such new events will get notified to my EventHandler
by default, or must I modify something in between?.
Are those the most appropriate classes/methods to specialize?.
And, most of all, is the whole strategy correct?.
Well, I hope I'm on the right path.
Thanks again.
Regards,
Juan Pedro
|
|
|
| Re: [CDO] Event Notification procedure [message #494546 is a reply to message #494458] |
Sat, 31 October 2009 10:18  |
|
Hi Juan Pedro,
Comments below...
Juan Pedro Silva schrieb:
> Hi Víctor and everybody.
> I've been taking a deeper look on the locks notification issue. I'm,
> however, very new to CDO, so I haven't been able able to grasp it
> completely just yet.
In the meantime I added some hints to https://bugs.eclipse.org/283274
>
> What I was able to figure out is, parting from the editor (the
> objective is to somehow graphically indicate that objects are being
> locked by other sessions), I can do:
> -editor.getView().getSession() and get the session (and from there
> getRemoteSessionManager() and get the manager that knows about all
> sessions, which I guess this is not of great use to me).
The remote session manager could be used for the new notification
protocol, but in this case I'd prefer to do it directly in
CDOSessionProtocol (see the bugzilla).
> -I can also get, from the CDOEditor, the CDOEventHandler, which has
> its own IListeners.
>
> Recalling, the final intention is to notify/get notified that a lock
> has been obtained on some model element.
> My current idea (without great knowledge of CDO's architecture) of how
> things should go:
> 1) Define my new type of IEvent (perhaps more than one, LockEvent
> (Read and Write) and ReleaseLockEvent, I have to think deeper on that).
Yes. How much information should we provide in these events, just the
objects that were locked/unlocked, or the sessions (views?) that caused
these transitions?
> 2) Make my CDOSession fire these events (as in fireInvalidationEvent).
> I believe they should be fired from
> "CDOSessionImpl.acquireAtomicRequestLock()" and
> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
> CDOSession interface).
No, these methods serve a completely different purpose. Since locking
always happens in the scope of a CDOView, the view should fire these new
events. The events themselves must not originate from monly the client
side because you really want them to reflect transitions from other
(remote) sessions/views. I explained in the bugzilla where they really
originate from.
> 3) Check for these events in my editor's EventHandler (by subclassing
> CDOEventHandler and adding a new "IListener lockEventListener", perhaps).
The reflection of the locking state in the UI is indeed separate from
the core functonality that has to be added. But yes, your editor should
listen to the new events and update the label decoration appropriately.
I suggest that we use the new events in our CDOEditor, too.
>
> And then some doubts arise (thanks again to my short knowledge of CDO):
> May I assume that such new events will get notified to my EventHandler
> by default, or must I modify something in between?.
I like the idea of exposing them through CDOEventHandler.
> Are those the most appropriate classes/methods to specialize?.
> And, most of all, is the whole strategy correct?.
Most of it ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Event Notification procedure [message #494733 is a reply to message #494546] |
Mon, 02 November 2009 12:15 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Hi Eike, thanks for your answer.
I saw your post on the bug. Those kinds of insights are fundamental to me.
I'll try to get my hands dirty on this (depends on the time left by
other activities), and will get back to you with any news.
Best regards,
Juan Pedro
Eike Stepper escribió:
> Hi Juan Pedro,
>
> Comments below...
>
>
> Juan Pedro Silva schrieb:
>> Hi Víctor and everybody.
>> I've been taking a deeper look on the locks notification issue. I'm,
>> however, very new to CDO, so I haven't been able able to grasp it
>> completely just yet.
> In the meantime I added some hints to https://bugs.eclipse.org/283274
>
>> What I was able to figure out is, parting from the editor (the
>> objective is to somehow graphically indicate that objects are being
>> locked by other sessions), I can do:
>> -editor.getView().getSession() and get the session (and from there
>> getRemoteSessionManager() and get the manager that knows about all
>> sessions, which I guess this is not of great use to me).
> The remote session manager could be used for the new notification
> protocol, but in this case I'd prefer to do it directly in
> CDOSessionProtocol (see the bugzilla).
>
>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>> its own IListeners.
>>
>> Recalling, the final intention is to notify/get notified that a lock
>> has been obtained on some model element.
>> My current idea (without great knowledge of CDO's architecture) of how
>> things should go:
>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>> (Read and Write) and ReleaseLockEvent, I have to think deeper on that).
> Yes. How much information should we provide in these events, just the
> objects that were locked/unlocked, or the sessions (views?) that caused
> these transitions?
>
>> 2) Make my CDOSession fire these events (as in fireInvalidationEvent).
>> I believe they should be fired from
>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
>> CDOSession interface).
> No, these methods serve a completely different purpose. Since locking
> always happens in the scope of a CDOView, the view should fire these new
> events. The events themselves must not originate from monly the client
> side because you really want them to reflect transitions from other
> (remote) sessions/views. I explained in the bugzilla where they really
> originate from.
>
>> 3) Check for these events in my editor's EventHandler (by subclassing
>> CDOEventHandler and adding a new "IListener lockEventListener", perhaps).
> The reflection of the locking state in the UI is indeed separate from
> the core functonality that has to be added. But yes, your editor should
> listen to the new events and update the label decoration appropriately.
> I suggest that we use the new events in our CDOEditor, too.
>
>> And then some doubts arise (thanks again to my short knowledge of CDO):
>> May I assume that such new events will get notified to my EventHandler
>> by default, or must I modify something in between?.
> I like the idea of exposing them through CDOEventHandler.
>
>> Are those the most appropriate classes/methods to specialize?.
>> And, most of all, is the whole strategy correct?.
> Most of it ;-)
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
|
|
|
| Re: [CDO] Event Notification procedure [message #494734 is a reply to message #494733] |
Mon, 02 November 2009 12:24 |
|
Juan Pedro Silva Gallino schrieb:
> Hi Eike, thanks for your answer.
> I saw your post on the bug. Those kinds of insights are fundamental to
> me.
> I'll try to get my hands dirty on this (depends on the time left by
> other activities), and will get back to you with any news.
Excellent! Don't hesitate to ask if you need further help ;-)
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Best regards,
> Juan Pedro
>
> Eike Stepper escribió:
>> Hi Juan Pedro,
>>
>> Comments below...
>>
>>
>> Juan Pedro Silva schrieb:
>>> Hi Víctor and everybody.
>>> I've been taking a deeper look on the locks notification issue. I'm,
>>> however, very new to CDO, so I haven't been able able to grasp it
>>> completely just yet.
>> In the meantime I added some hints to https://bugs.eclipse.org/283274
>>
>>> What I was able to figure out is, parting from the editor (the
>>> objective is to somehow graphically indicate that objects are being
>>> locked by other sessions), I can do:
>>> -editor.getView().getSession() and get the session (and from there
>>> getRemoteSessionManager() and get the manager that knows about all
>>> sessions, which I guess this is not of great use to me).
>> The remote session manager could be used for the new notification
>> protocol, but in this case I'd prefer to do it directly in
>> CDOSessionProtocol (see the bugzilla).
>>
>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>> its own IListeners.
>>>
>>> Recalling, the final intention is to notify/get notified that a lock
>>> has been obtained on some model element.
>>> My current idea (without great knowledge of CDO's architecture) of how
>>> things should go:
>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on that).
>> Yes. How much information should we provide in these events, just the
>> objects that were locked/unlocked, or the sessions (views?) that caused
>> these transitions?
>>
>>> 2) Make my CDOSession fire these events (as in fireInvalidationEvent).
>>> I believe they should be fired from
>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
>>> CDOSession interface).
>> No, these methods serve a completely different purpose. Since locking
>> always happens in the scope of a CDOView, the view should fire these new
>> events. The events themselves must not originate from monly the client
>> side because you really want them to reflect transitions from other
>> (remote) sessions/views. I explained in the bugzilla where they really
>> originate from.
>>
>>> 3) Check for these events in my editor's EventHandler (by subclassing
>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>> perhaps).
>> The reflection of the locking state in the UI is indeed separate from
>> the core functonality that has to be added. But yes, your editor should
>> listen to the new events and update the label decoration appropriately.
>> I suggest that we use the new events in our CDOEditor, too.
>>
>>> And then some doubts arise (thanks again to my short knowledge of CDO):
>>> May I assume that such new events will get notified to my EventHandler
>>> by default, or must I modify something in between?.
>> I like the idea of exposing them through CDOEventHandler.
>>
>>> Are those the most appropriate classes/methods to specialize?.
>>> And, most of all, is the whole strategy correct?.
>> Most of it ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Event Notification procedure [message #495412 is a reply to message #494734] |
Wed, 04 November 2009 18:23 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080601040500010104040203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Eike, I need guidance, as I believe I may have to introduce a new
package dependency.
I'm implementing the (un)registration mechanism for the locks notification.
The situation is the following:
-CDOSessionImpl knows of
org.eclipse.net4j.util.concurrent.IRWLockManager and
org.eclipse.net4j.util.concurrent.RWLockManager, but knows nothing of
org.eclipse.emf.cdo.internal.server.LockManager. Besides, RWLockManager
performs the actual locking/unlocking that should be notified, so I
though I should introduce the mechanism in RWLockManager. However, I was
under the impression you rather have me do it in LockManager.
-RWLockManager doesn't know CDOSession, ISession, or InternalCDOSession.
If I import any of those packages in RWLockManager, I create a cycle.
-On the other side, LockManager knows ISession, but CDOSession doesn't
know him as it's internal.
How do you suggest I make the lock manager and the session aware of each
other?, which type should I use for the list of registered sessions and
where?.
Look forward to your answer.
Regards,
Juan Pedro
Eike Stepper escribi
|
|
|
| Re: [CDO] Event Notification procedure [message #495510 is a reply to message #495412] |
Thu, 05 November 2009 07:42 |
|
Hi Juan Pedro,
Comments below...
Juan Pedro Silva schrieb:
> Eike, I need guidance, as I believe I may have to introduce a new
> package dependency.
Let's try to avoid that if it introduces a cycle :P
> I'm implementing the (un)registration mechanism for the locks
> notification.
> The situation is the following:
>
> -CDOSessionImpl knows of
> org.eclipse.net4j.util.concurrent.IRWLockManager and
> org.eclipse.net4j.util.concurrent.RWLockManager,
Yes, but only to refer to the nested LockType.
> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
Yes, the client side is not involved in actual lock management.
> Besides, RWLockManager performs the actual locking/unlocking that
> should be notified, so I though I should introduce the mechanism in
> RWLockManager. However, I was under the impression you rather have me
> do it in LockManager.
> -RWLockManager doesn't know CDOSession, ISession, or
> InternalCDOSession. If I import any of those packages in
> RWLockManager, I create a cycle.
> -On the other side, LockManager knows ISession, but CDOSession doesn't
> know him as it's internal.
Yes, all the locking management code is in Net4j's RWLockManager and
that's really the originating area for the new lock notifications. The
CDO LockManager is just a very thin wrapper around RWLockManager that
automates the task of releasing all locks of sessions that have been closed.
>
> How do you suggest I make the lock manager and the session aware of
> each other?, which type should I use for the list of registered
> sessions and where?.
RWLockManager extends Lifecycle, which in turn extends Notifier. So you
can fire events from within the RWLockManager that are handled in higher
layers. A more performant approach would be to add some protected
methods in RWLockManager that are overwritten in LockManager.
Doeos that help?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Look forward to your answer.
> Regards,
> Juan Pedro
>
> Eike Stepper escribió:
>> Juan Pedro Silva Gallino schrieb:
>>
>>> Hi Eike, thanks for your answer.
>>> I saw your post on the bug. Those kinds of insights are fundamental to
>>> me.
>>> I'll try to get my hands dirty on this (depends on the time left by
>>> other activities), and will get back to you with any news.
>>>
>> Excellent! Don't hesitate to ask if you need further help ;-)
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>> Best regards,
>>> Juan Pedro
>>>
>>> Eike Stepper escribió:
>>>
>>>> Hi Juan Pedro,
>>>>
>>>> Comments below...
>>>>
>>>>
>>>> Juan Pedro Silva schrieb:
>>>>
>>>>> Hi Víctor and everybody.
>>>>> I've been taking a deeper look on the locks notification issue. I'm,
>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>> completely just yet.
>>>>>
>>>> In the meantime I added some hints to https://bugs.eclipse.org/283274
>>>>
>>>>
>>>>> What I was able to figure out is, parting from the editor (the
>>>>> objective is to somehow graphically indicate that objects are being
>>>>> locked by other sessions), I can do:
>>>>> -editor.getView().getSession() and get the session (and from there
>>>>> getRemoteSessionManager() and get the manager that knows about all
>>>>> sessions, which I guess this is not of great use to me).
>>>>>
>>>> The remote session manager could be used for the new notification
>>>> protocol, but in this case I'd prefer to do it directly in
>>>> CDOSessionProtocol (see the bugzilla).
>>>>
>>>>
>>>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>>>> its own IListeners.
>>>>>
>>>>> Recalling, the final intention is to notify/get notified that a lock
>>>>> has been obtained on some model element.
>>>>> My current idea (without great knowledge of CDO's architecture) of how
>>>>> things should go:
>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on that).
>>>>>
>>>> Yes. How much information should we provide in these events, just the
>>>> objects that were locked/unlocked, or the sessions (views?) that caused
>>>> these transitions?
>>>>
>>>>
>>>>> 2) Make my CDOSession fire these events (as in fireInvalidationEvent).
>>>>> I believe they should be fired from
>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
>>>>> CDOSession interface).
>>>>>
>>>> No, these methods serve a completely different purpose. Since locking
>>>> always happens in the scope of a CDOView, the view should fire these new
>>>> events. The events themselves must not originate from monly the client
>>>> side because you really want them to reflect transitions from other
>>>> (remote) sessions/views. I explained in the bugzilla where they really
>>>> originate from.
>>>>
>>>>
>>>>> 3) Check for these events in my editor's EventHandler (by subclassing
>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>> perhaps).
>>>>>
>>>> The reflection of the locking state in the UI is indeed separate from
>>>> the core functonality that has to be added. But yes, your editor should
>>>> listen to the new events and update the label decoration appropriately.
>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>
>>>>
>>>>> And then some doubts arise (thanks again to my short knowledge of CDO):
>>>>> May I assume that such new events will get notified to my EventHandler
>>>>> by default, or must I modify something in between?.
>>>>>
>>>> I like the idea of exposing them through CDOEventHandler.
>>>>
>>>>
>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>> And, most of all, is the whole strategy correct?.
>>>>>
>>>> Most of it ;-)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Event Notification procedure [message #495675 is a reply to message #495510] |
Thu, 05 November 2009 17:47 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Hi Eike.
Yes, that helped, although I was under the impression that you wanted
something a little different.
I'll comment on that later, when I get back to describe the final
implementation.
Regards,
Juan Pedro
Eike Stepper escribió:
> Hi Juan Pedro,
>
> Comments below...
>
>
> Juan Pedro Silva schrieb:
>> Eike, I need guidance, as I believe I may have to introduce a new
>> package dependency.
> Let's try to avoid that if it introduces a cycle :P
>
>> I'm implementing the (un)registration mechanism for the locks
>> notification.
>> The situation is the following:
>>
>> -CDOSessionImpl knows of
>> org.eclipse.net4j.util.concurrent.IRWLockManager and
>> org.eclipse.net4j.util.concurrent.RWLockManager,
> Yes, but only to refer to the nested LockType.
>
>> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
> Yes, the client side is not involved in actual lock management.
>
>> Besides, RWLockManager performs the actual locking/unlocking that
>> should be notified, so I though I should introduce the mechanism in
>> RWLockManager. However, I was under the impression you rather have me
>> do it in LockManager.
>> -RWLockManager doesn't know CDOSession, ISession, or
>> InternalCDOSession. If I import any of those packages in
>> RWLockManager, I create a cycle.
>> -On the other side, LockManager knows ISession, but CDOSession doesn't
>> know him as it's internal.
> Yes, all the locking management code is in Net4j's RWLockManager and
> that's really the originating area for the new lock notifications. The
> CDO LockManager is just a very thin wrapper around RWLockManager that
> automates the task of releasing all locks of sessions that have been closed.
>
>
>> How do you suggest I make the lock manager and the session aware of
>> each other?, which type should I use for the list of registered
>> sessions and where?.
> RWLockManager extends Lifecycle, which in turn extends Notifier. So you
> can fire events from within the RWLockManager that are handled in higher
> layers. A more performant approach would be to add some protected
> methods in RWLockManager that are overwritten in LockManager.
>
> Doeos that help?
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>> Look forward to your answer.
>> Regards,
>> Juan Pedro
>>
>> Eike Stepper escribió:
>>> Juan Pedro Silva Gallino schrieb:
>>>
>>>> Hi Eike, thanks for your answer.
>>>> I saw your post on the bug. Those kinds of insights are fundamental to
>>>> me.
>>>> I'll try to get my hands dirty on this (depends on the time left by
>>>> other activities), and will get back to you with any news.
>>>>
>>> Excellent! Don't hesitate to ask if you need further help ;-)
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>>> Best regards,
>>>> Juan Pedro
>>>>
>>>> Eike Stepper escribió:
>>>>
>>>>> Hi Juan Pedro,
>>>>>
>>>>> Comments below...
>>>>>
>>>>>
>>>>> Juan Pedro Silva schrieb:
>>>>>
>>>>>> Hi Víctor and everybody.
>>>>>> I've been taking a deeper look on the locks notification issue. I'm,
>>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>>> completely just yet.
>>>>>>
>>>>> In the meantime I added some hints to https://bugs.eclipse.org/283274
>>>>>
>>>>>
>>>>>> What I was able to figure out is, parting from the editor (the
>>>>>> objective is to somehow graphically indicate that objects are being
>>>>>> locked by other sessions), I can do:
>>>>>> -editor.getView().getSession() and get the session (and from there
>>>>>> getRemoteSessionManager() and get the manager that knows about all
>>>>>> sessions, which I guess this is not of great use to me).
>>>>>>
>>>>> The remote session manager could be used for the new notification
>>>>> protocol, but in this case I'd prefer to do it directly in
>>>>> CDOSessionProtocol (see the bugzilla).
>>>>>
>>>>>
>>>>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>>>>> its own IListeners.
>>>>>>
>>>>>> Recalling, the final intention is to notify/get notified that a lock
>>>>>> has been obtained on some model element.
>>>>>> My current idea (without great knowledge of CDO's architecture) of how
>>>>>> things should go:
>>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on that).
>>>>>>
>>>>> Yes. How much information should we provide in these events, just the
>>>>> objects that were locked/unlocked, or the sessions (views?) that caused
>>>>> these transitions?
>>>>>
>>>>>
>>>>>> 2) Make my CDOSession fire these events (as in fireInvalidationEvent).
>>>>>> I believe they should be fired from
>>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are not in
>>>>>> CDOSession interface).
>>>>>>
>>>>> No, these methods serve a completely different purpose. Since locking
>>>>> always happens in the scope of a CDOView, the view should fire these new
>>>>> events. The events themselves must not originate from monly the client
>>>>> side because you really want them to reflect transitions from other
>>>>> (remote) sessions/views. I explained in the bugzilla where they really
>>>>> originate from.
>>>>>
>>>>>
>>>>>> 3) Check for these events in my editor's EventHandler (by subclassing
>>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>>> perhaps).
>>>>>>
>>>>> The reflection of the locking state in the UI is indeed separate from
>>>>> the core functonality that has to be added. But yes, your editor should
>>>>> listen to the new events and update the label decoration appropriately.
>>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>>
>>>>>
>>>>>> And then some doubts arise (thanks again to my short knowledge of CDO):
>>>>>> May I assume that such new events will get notified to my EventHandler
>>>>>> by default, or must I modify something in between?.
>>>>>>
>>>>> I like the idea of exposing them through CDOEventHandler.
>>>>>
>>>>>
>>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>>> And, most of all, is the whole strategy correct?.
>>>>>>
>>>>> Most of it ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
|
|
|
| Re: [CDO] Event Notification procedure ->NPE [message #496317 is a reply to message #495510] |
Mon, 09 November 2009 17:04 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030108000608090904090900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Eike.
I'm trying to progress in the remote locking notification.
I've been debugging a little to see how the flow of the application when
locks are requested. I'm attaching a class diagram that reflects what I
have grasped so far.
According to my understanding, when a lock is solicited,
CDOClientProtocol.lockObjects(....), which in turn sends a new
LockObjectsRequest(..) (a subclass of signal).
CDOServerProtocl captures the CDOProtocolConstants.SIGNAL_LOCK_OBJECTS
signal with its signal reactor, creating a new LockObjectsIndication(..).
This is the client -> server part of the communication. Now I need the
server -> client part, so that the rest of the clients are notified of
the locks. From the CDOServerProtocol I can get to the respository, the
SessionManager, and get all the sessions on that repository. I can
check with each session if they have registered lock listeners and, if
so, call "sendRemoteLockNotification(IView, List<CDOID>, LockType)"
(new, similar to the "sendRemoteMessageNotification" method).
I don't know if you agree with the strategy. I tried to implement the
notification loop in LockObjectsIndication.indicating(..), as it was a
reaction to the lock objects request (although I'm not completely sure
this is the best place to do this). Anyhow, I'm facing a problem: when I
try to send the LockNotificationRequest, I get a NPE (the stack trace is
below the message). Suggestions?.
I look forward to your comments.
Regards,
Juan Pedro
[ERROR] NullPointerException
java.lang.NullPointerException
at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java: 669)
at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
at
org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource (EMFUtil.java:269)
at
org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFU til.java:248)
at
org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CD OModelUtil.java:393)
at
org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl .read(CDOPackageUnitImpl.java:282)
at
org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnit(CDODataInputImpl.java:88)
at
org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnits(CDODataInputImpl.java:103)
at
org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificati onIndication.indicating(CommitNotificationIndication.java:56 )
at
org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndicat ion.indicating(CDOClientIndication.java:54)
at org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Eike Stepper escribi
|
|
|
| Re: [CDO] Event Notification procedure ->NPE [message #496434 is a reply to message #496317] |
Tue, 10 November 2009 05:33 |
|
Hi Juan Pedro,
That looks a bit as if you messed up the signal IDs, but I'm not sure
without looking at your code. Why don't you attach your patch to the
bugzilla?
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Juan Pedro Silva Gallino schrieb:
> Hi Eike.
> I'm trying to progress in the remote locking notification.
> I've been debugging a little to see how the flow of the application
> when locks are requested. I'm attaching a class diagram that reflects
> what I have grasped so far.
>
> According to my understanding, when a lock is solicited,
> CDOClientProtocol.lockObjects(....), which in turn sends a new
> LockObjectsRequest(..) (a subclass of signal).
>
> CDOServerProtocl captures the CDOProtocolConstants.SIGNAL_LOCK_OBJECTS
> signal with its signal reactor, creating a new LockObjectsIndication(..).
>
> This is the client -> server part of the communication. Now I need the
> server -> client part, so that the rest of the clients are notified of
> the locks. From the CDOServerProtocol I can get to the respository,
> the SessionManager, and get all the sessions on that repository. I
> can check with each session if they have registered lock listeners
> and, if so, call "sendRemoteLockNotification(IView, List<CDOID>,
> LockType)" (new, similar to the "sendRemoteMessageNotification" method).
>
> I don't know if you agree with the strategy. I tried to implement the
> notification loop in LockObjectsIndication.indicating(..), as it was a
> reaction to the lock objects request (although I'm not completely sure
> this is the best place to do this). Anyhow, I'm facing a problem: when
> I try to send the LockNotificationRequest, I get a NPE (the stack
> trace is below the message). Suggestions?.
>
> I look forward to your comments.
> Regards,
> Juan Pedro
>
>
> [ERROR] NullPointerException
> java.lang.NullPointerException
> at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java: 669)
> at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
> at
> org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource (EMFUtil.java:269)
>
> at
> org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFU til.java:248)
> at
> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CD OModelUtil.java:393)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl .read(CDOPackageUnitImpl.java:282)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnit(CDODataInputImpl.java:88)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnits(CDODataInputImpl.java:103)
>
> at
> org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificati onIndication.indicating(CommitNotificationIndication.java:56 )
>
> at
> org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndicat ion.indicating(CDOClientIndication.java:54)
>
> at
> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
>
> Eike Stepper escribió:
>> Hi Juan Pedro,
>>
>> Comments below...
>>
>>
>> Juan Pedro Silva schrieb:
>>> Eike, I need guidance, as I believe I may have to introduce a new
>>> package dependency.
>> Let's try to avoid that if it introduces a cycle :P
>>
>>> I'm implementing the (un)registration mechanism for the locks
>>> notification.
>>> The situation is the following:
>>>
>>> -CDOSessionImpl knows of
>>> org.eclipse.net4j.util.concurrent.IRWLockManager and
>>> org.eclipse.net4j.util.concurrent.RWLockManager,
>> Yes, but only to refer to the nested LockType.
>>
>>> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
>> Yes, the client side is not involved in actual lock management.
>>
>>> Besides, RWLockManager performs the actual locking/unlocking that
>>> should be notified, so I though I should introduce the mechanism in
>>> RWLockManager. However, I was under the impression you rather have me
>>> do it in LockManager.
>>> -RWLockManager doesn't know CDOSession, ISession, or
>>> InternalCDOSession. If I import any of those packages in
>>> RWLockManager, I create a cycle.
>>> -On the other side, LockManager knows ISession, but CDOSession doesn't
>>> know him as it's internal.
>> Yes, all the locking management code is in Net4j's RWLockManager and
>> that's really the originating area for the new lock notifications. The
>> CDO LockManager is just a very thin wrapper around RWLockManager that
>> automates the task of releasing all locks of sessions that have been
>> closed.
>>
>>
>>> How do you suggest I make the lock manager and the session aware of
>>> each other?, which type should I use for the list of registered
>>> sessions and where?.
>> RWLockManager extends Lifecycle, which in turn extends Notifier. So you
>> can fire events from within the RWLockManager that are handled in higher
>> layers. A more performant approach would be to add some protected
>> methods in RWLockManager that are overwritten in LockManager.
>>
>> Doeos that help?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>> Look forward to your answer.
>>> Regards,
>>> Juan Pedro
>>>
>>> Eike Stepper escribió:
>>>> Juan Pedro Silva Gallino schrieb:
>>>>
>>>>> Hi Eike, thanks for your answer.
>>>>> I saw your post on the bug. Those kinds of insights are
>>>>> fundamental to
>>>>> me.
>>>>> I'll try to get my hands dirty on this (depends on the time left by
>>>>> other activities), and will get back to you with any news.
>>>>>
>>>> Excellent! Don't hesitate to ask if you need further help ;-)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>>> Best regards,
>>>>> Juan Pedro
>>>>>
>>>>> Eike Stepper escribió:
>>>>>
>>>>>> Hi Juan Pedro,
>>>>>>
>>>>>> Comments below...
>>>>>>
>>>>>>
>>>>>> Juan Pedro Silva schrieb:
>>>>>>
>>>>>>> Hi Víctor and everybody.
>>>>>>> I've been taking a deeper look on the locks notification issue.
>>>>>>> I'm,
>>>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>>>> completely just yet.
>>>>>>>
>>>>>> In the meantime I added some hints to
>>>>>> https://bugs.eclipse.org/283274
>>>>>>
>>>>>>
>>>>>>> What I was able to figure out is, parting from the editor (the
>>>>>>> objective is to somehow graphically indicate that objects are being
>>>>>>> locked by other sessions), I can do:
>>>>>>> -editor.getView().getSession() and get the session (and from there
>>>>>>> getRemoteSessionManager() and get the manager that knows about all
>>>>>>> sessions, which I guess this is not of great use to me).
>>>>>>>
>>>>>> The remote session manager could be used for the new notification
>>>>>> protocol, but in this case I'd prefer to do it directly in
>>>>>> CDOSessionProtocol (see the bugzilla).
>>>>>>
>>>>>>
>>>>>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>>>>>> its own IListeners.
>>>>>>>
>>>>>>> Recalling, the final intention is to notify/get notified that a
>>>>>>> lock
>>>>>>> has been obtained on some model element.
>>>>>>> My current idea (without great knowledge of CDO's architecture)
>>>>>>> of how
>>>>>>> things should go:
>>>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on
>>>>>>> that).
>>>>>>>
>>>>>> Yes. How much information should we provide in these events, just
>>>>>> the
>>>>>> objects that were locked/unlocked, or the sessions (views?) that
>>>>>> caused
>>>>>> these transitions?
>>>>>>
>>>>>>
>>>>>>> 2) Make my CDOSession fire these events (as in
>>>>>>> fireInvalidationEvent).
>>>>>>> I believe they should be fired from
>>>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are
>>>>>>> not in
>>>>>>> CDOSession interface).
>>>>>>>
>>>>>> No, these methods serve a completely different purpose. Since
>>>>>> locking
>>>>>> always happens in the scope of a CDOView, the view should fire
>>>>>> these new
>>>>>> events. The events themselves must not originate from monly the
>>>>>> client
>>>>>> side because you really want them to reflect transitions from other
>>>>>> (remote) sessions/views. I explained in the bugzilla where they
>>>>>> really
>>>>>> originate from.
>>>>>>
>>>>>>
>>>>>>> 3) Check for these events in my editor's EventHandler (by
>>>>>>> subclassing
>>>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>>>> perhaps).
>>>>>>>
>>>>>> The reflection of the locking state in the UI is indeed separate
>>>>>> from
>>>>>> the core functonality that has to be added. But yes, your editor
>>>>>> should
>>>>>> listen to the new events and update the label decoration
>>>>>> appropriately.
>>>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>>>
>>>>>>
>>>>>>> And then some doubts arise (thanks again to my short knowledge
>>>>>>> of CDO):
>>>>>>> May I assume that such new events will get notified to my
>>>>>>> EventHandler
>>>>>>> by default, or must I modify something in between?.
>>>>>>>
>>>>>> I like the idea of exposing them through CDOEventHandler.
>>>>>>
>>>>>>
>>>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>>>> And, most of all, is the whole strategy correct?.
>>>>>>>
>>>>>> Most of it ;-)
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>> ----
>>>>>> http://thegordian.blogspot.com
>>>>>> http://twitter.com/eikestepper
>>>>>>
>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Event Notification procedure ->NPE [message #496437 is a reply to message #496317] |
Tue, 10 November 2009 05:54 |
|
One more note:
I just noticed the diagram you attached. You seem to think that the
LockManager in the CDOSessionImpl is related to server-side locking, but
that's not true! It's really "only" a local thread synchronization
thing. It's best to ignore it for your purpose.
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Juan Pedro Silva Gallino schrieb:
> Hi Eike.
> I'm trying to progress in the remote locking notification.
> I've been debugging a little to see how the flow of the application
> when locks are requested. I'm attaching a class diagram that reflects
> what I have grasped so far.
>
> According to my understanding, when a lock is solicited,
> CDOClientProtocol.lockObjects(....), which in turn sends a new
> LockObjectsRequest(..) (a subclass of signal).
>
> CDOServerProtocl captures the CDOProtocolConstants.SIGNAL_LOCK_OBJECTS
> signal with its signal reactor, creating a new LockObjectsIndication(..).
>
> This is the client -> server part of the communication. Now I need the
> server -> client part, so that the rest of the clients are notified of
> the locks. From the CDOServerProtocol I can get to the respository,
> the SessionManager, and get all the sessions on that repository. I
> can check with each session if they have registered lock listeners
> and, if so, call "sendRemoteLockNotification(IView, List<CDOID>,
> LockType)" (new, similar to the "sendRemoteMessageNotification" method).
>
> I don't know if you agree with the strategy. I tried to implement the
> notification loop in LockObjectsIndication.indicating(..), as it was a
> reaction to the lock objects request (although I'm not completely sure
> this is the best place to do this). Anyhow, I'm facing a problem: when
> I try to send the LockNotificationRequest, I get a NPE (the stack
> trace is below the message). Suggestions?.
>
> I look forward to your comments.
> Regards,
> Juan Pedro
>
>
> [ERROR] NullPointerException
> java.lang.NullPointerException
> at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java: 669)
> at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
> at
> org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource (EMFUtil.java:269)
>
> at
> org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFU til.java:248)
> at
> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CD OModelUtil.java:393)
>
> at
> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl .read(CDOPackageUnitImpl.java:282)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnit(CDODataInputImpl.java:88)
>
> at
> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnits(CDODataInputImpl.java:103)
>
> at
> org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificati onIndication.indicating(CommitNotificationIndication.java:56 )
>
> at
> org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndicat ion.indicating(CDOClientIndication.java:54)
>
> at
> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
>
> Eike Stepper escribió:
>> Hi Juan Pedro,
>>
>> Comments below...
>>
>>
>> Juan Pedro Silva schrieb:
>>> Eike, I need guidance, as I believe I may have to introduce a new
>>> package dependency.
>> Let's try to avoid that if it introduces a cycle :P
>>
>>> I'm implementing the (un)registration mechanism for the locks
>>> notification.
>>> The situation is the following:
>>>
>>> -CDOSessionImpl knows of
>>> org.eclipse.net4j.util.concurrent.IRWLockManager and
>>> org.eclipse.net4j.util.concurrent.RWLockManager,
>> Yes, but only to refer to the nested LockType.
>>
>>> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
>> Yes, the client side is not involved in actual lock management.
>>
>>> Besides, RWLockManager performs the actual locking/unlocking that
>>> should be notified, so I though I should introduce the mechanism in
>>> RWLockManager. However, I was under the impression you rather have me
>>> do it in LockManager.
>>> -RWLockManager doesn't know CDOSession, ISession, or
>>> InternalCDOSession. If I import any of those packages in
>>> RWLockManager, I create a cycle.
>>> -On the other side, LockManager knows ISession, but CDOSession doesn't
>>> know him as it's internal.
>> Yes, all the locking management code is in Net4j's RWLockManager and
>> that's really the originating area for the new lock notifications. The
>> CDO LockManager is just a very thin wrapper around RWLockManager that
>> automates the task of releasing all locks of sessions that have been
>> closed.
>>
>>
>>> How do you suggest I make the lock manager and the session aware of
>>> each other?, which type should I use for the list of registered
>>> sessions and where?.
>> RWLockManager extends Lifecycle, which in turn extends Notifier. So you
>> can fire events from within the RWLockManager that are handled in higher
>> layers. A more performant approach would be to add some protected
>> methods in RWLockManager that are overwritten in LockManager.
>>
>> Doeos that help?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>> Look forward to your answer.
>>> Regards,
>>> Juan Pedro
>>>
>>> Eike Stepper escribió:
>>>> Juan Pedro Silva Gallino schrieb:
>>>>
>>>>> Hi Eike, thanks for your answer.
>>>>> I saw your post on the bug. Those kinds of insights are
>>>>> fundamental to
>>>>> me.
>>>>> I'll try to get my hands dirty on this (depends on the time left by
>>>>> other activities), and will get back to you with any news.
>>>>>
>>>> Excellent! Don't hesitate to ask if you need further help ;-)
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>
>>>>> Best regards,
>>>>> Juan Pedro
>>>>>
>>>>> Eike Stepper escribió:
>>>>>
>>>>>> Hi Juan Pedro,
>>>>>>
>>>>>> Comments below...
>>>>>>
>>>>>>
>>>>>> Juan Pedro Silva schrieb:
>>>>>>
>>>>>>> Hi Víctor and everybody.
>>>>>>> I've been taking a deeper look on the locks notification issue.
>>>>>>> I'm,
>>>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>>>> completely just yet.
>>>>>>>
>>>>>> In the meantime I added some hints to
>>>>>> https://bugs.eclipse.org/283274
>>>>>>
>>>>>>
>>>>>>> What I was able to figure out is, parting from the editor (the
>>>>>>> objective is to somehow graphically indicate that objects are being
>>>>>>> locked by other sessions), I can do:
>>>>>>> -editor.getView().getSession() and get the session (and from there
>>>>>>> getRemoteSessionManager() and get the manager that knows about all
>>>>>>> sessions, which I guess this is not of great use to me).
>>>>>>>
>>>>>> The remote session manager could be used for the new notification
>>>>>> protocol, but in this case I'd prefer to do it directly in
>>>>>> CDOSessionProtocol (see the bugzilla).
>>>>>>
>>>>>>
>>>>>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>>>>>> its own IListeners.
>>>>>>>
>>>>>>> Recalling, the final intention is to notify/get notified that a
>>>>>>> lock
>>>>>>> has been obtained on some model element.
>>>>>>> My current idea (without great knowledge of CDO's architecture)
>>>>>>> of how
>>>>>>> things should go:
>>>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on
>>>>>>> that).
>>>>>>>
>>>>>> Yes. How much information should we provide in these events, just
>>>>>> the
>>>>>> objects that were locked/unlocked, or the sessions (views?) that
>>>>>> caused
>>>>>> these transitions?
>>>>>>
>>>>>>
>>>>>>> 2) Make my CDOSession fire these events (as in
>>>>>>> fireInvalidationEvent).
>>>>>>> I believe they should be fired from
>>>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are
>>>>>>> not in
>>>>>>> CDOSession interface).
>>>>>>>
>>>>>> No, these methods serve a completely different purpose. Since
>>>>>> locking
>>>>>> always happens in the scope of a CDOView, the view should fire
>>>>>> these new
>>>>>> events. The events themselves must not originate from monly the
>>>>>> client
>>>>>> side because you really want them to reflect transitions from other
>>>>>> (remote) sessions/views. I explained in the bugzilla where they
>>>>>> really
>>>>>> originate from.
>>>>>>
>>>>>>
>>>>>>> 3) Check for these events in my editor's EventHandler (by
>>>>>>> subclassing
>>>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>>>> perhaps).
>>>>>>>
>>>>>> The reflection of the locking state in the UI is indeed separate
>>>>>> from
>>>>>> the core functonality that has to be added. But yes, your editor
>>>>>> should
>>>>>> listen to the new events and update the label decoration
>>>>>> appropriately.
>>>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>>>
>>>>>>
>>>>>>> And then some doubts arise (thanks again to my short knowledge
>>>>>>> of CDO):
>>>>>>> May I assume that such new events will get notified to my
>>>>>>> EventHandler
>>>>>>> by default, or must I modify something in between?.
>>>>>>>
>>>>>> I like the idea of exposing them through CDOEventHandler.
>>>>>>
>>>>>>
>>>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>>>> And, most of all, is the whole strategy correct?.
>>>>>>>
>>>>>> Most of it ;-)
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>> ----
>>>>>> http://thegordian.blogspot.com
>>>>>> http://twitter.com/eikestepper
>>>>>>
>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Event Notification procedure ->NPE [message #496534 is a reply to message #496437] |
Tue, 10 November 2009 13:03 |
Juan Pedro Silva
Messages: 258
Registered: July 2009 |
Senior Member |
|
|
Hi Eike.
Sorry if my diagram mislead you. No, I realize that each session has it
own lock manager, and the server protocol reacts to lock requests with
signal reactors. Anyhow, I may still not have the whole picture in my mind.
I will do as you suggested and attach my code to the bugzilla after I
clean it up a little.
Regards,
JP
Eike Stepper escribió:
> One more note:
>
> I just noticed the diagram you attached. You seem to think that the
> LockManager in the CDOSessionImpl is related to server-side locking, but
> that's not true! It's really "only" a local thread synchronization
> thing. It's best to ignore it for your purpose.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Juan Pedro Silva Gallino schrieb:
>> Hi Eike.
>> I'm trying to progress in the remote locking notification.
>> I've been debugging a little to see how the flow of the application
>> when locks are requested. I'm attaching a class diagram that reflects
>> what I have grasped so far.
>>
>> According to my understanding, when a lock is solicited,
>> CDOClientProtocol.lockObjects(....), which in turn sends a new
>> LockObjectsRequest(..) (a subclass of signal).
>>
>> CDOServerProtocl captures the CDOProtocolConstants.SIGNAL_LOCK_OBJECTS
>> signal with its signal reactor, creating a new LockObjectsIndication(..).
>>
>> This is the client -> server part of the communication. Now I need the
>> server -> client part, so that the rest of the clients are notified of
>> the locks. From the CDOServerProtocol I can get to the respository,
>> the SessionManager, and get all the sessions on that repository. I
>> can check with each session if they have registered lock listeners
>> and, if so, call "sendRemoteLockNotification(IView, List<CDOID>,
>> LockType)" (new, similar to the "sendRemoteMessageNotification" method).
>>
>> I don't know if you agree with the strategy. I tried to implement the
>> notification loop in LockObjectsIndication.indicating(..), as it was a
>> reaction to the lock objects request (although I'm not completely sure
>> this is the best place to do this). Anyhow, I'm facing a problem: when
>> I try to send the LockNotificationRequest, I get a NPE (the stack
>> trace is below the message). Suggestions?.
>>
>> I look forward to your comments.
>> Regards,
>> Juan Pedro
>>
>>
>> [ERROR] NullPointerException
>> java.lang.NullPointerException
>> at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java: 669)
>> at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
>> at
>> org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource (EMFUtil.java:269)
>>
>> at
>> org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFU til.java:248)
>> at
>> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CD OModelUtil.java:393)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl .read(CDOPackageUnitImpl.java:282)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnit(CDODataInputImpl.java:88)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnits(CDODataInputImpl.java:103)
>>
>> at
>> org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificati onIndication.indicating(CommitNotificationIndication.java:56 )
>>
>> at
>> org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndicat ion.indicating(CDOClientIndication.java:54)
>>
>> at
>> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>> Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>>
>>
>> Eike Stepper escribió:
>>> Hi Juan Pedro,
>>>
>>> Comments below...
>>>
>>>
>>> Juan Pedro Silva schrieb:
>>>> Eike, I need guidance, as I believe I may have to introduce a new
>>>> package dependency.
>>> Let's try to avoid that if it introduces a cycle :P
>>>
>>>> I'm implementing the (un)registration mechanism for the locks
>>>> notification.
>>>> The situation is the following:
>>>>
>>>> -CDOSessionImpl knows of
>>>> org.eclipse.net4j.util.concurrent.IRWLockManager and
>>>> org.eclipse.net4j.util.concurrent.RWLockManager,
>>> Yes, but only to refer to the nested LockType.
>>>
>>>> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
>>> Yes, the client side is not involved in actual lock management.
>>>
>>>> Besides, RWLockManager performs the actual locking/unlocking that
>>>> should be notified, so I though I should introduce the mechanism in
>>>> RWLockManager. However, I was under the impression you rather have me
>>>> do it in LockManager.
>>>> -RWLockManager doesn't know CDOSession, ISession, or
>>>> InternalCDOSession. If I import any of those packages in
>>>> RWLockManager, I create a cycle.
>>>> -On the other side, LockManager knows ISession, but CDOSession doesn't
>>>> know him as it's internal.
>>> Yes, all the locking management code is in Net4j's RWLockManager and
>>> that's really the originating area for the new lock notifications. The
>>> CDO LockManager is just a very thin wrapper around RWLockManager that
>>> automates the task of releasing all locks of sessions that have been
>>> closed.
>>>
>>>
>>>> How do you suggest I make the lock manager and the session aware of
>>>> each other?, which type should I use for the list of registered
>>>> sessions and where?.
>>> RWLockManager extends Lifecycle, which in turn extends Notifier. So you
>>> can fire events from within the RWLockManager that are handled in higher
>>> layers. A more performant approach would be to add some protected
>>> methods in RWLockManager that are overwritten in LockManager.
>>>
>>> Doeos that help?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>> Look forward to your answer.
>>>> Regards,
>>>> Juan Pedro
>>>>
>>>> Eike Stepper escribió:
>>>>> Juan Pedro Silva Gallino schrieb:
>>>>>
>>>>>> Hi Eike, thanks for your answer.
>>>>>> I saw your post on the bug. Those kinds of insights are
>>>>>> fundamental to
>>>>>> me.
>>>>>> I'll try to get my hands dirty on this (depends on the time left by
>>>>>> other activities), and will get back to you with any news.
>>>>>>
>>>>> Excellent! Don't hesitate to ask if you need further help ;-)
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>> ----
>>>>> http://thegordian.blogspot.com
>>>>> http://twitter.com/eikestepper
>>>>>
>>>>>
>>>>>
>>>>>> Best regards,
>>>>>> Juan Pedro
>>>>>>
>>>>>> Eike Stepper escribió:
>>>>>>
>>>>>>> Hi Juan Pedro,
>>>>>>>
>>>>>>> Comments below...
>>>>>>>
>>>>>>>
>>>>>>> Juan Pedro Silva schrieb:
>>>>>>>
>>>>>>>> Hi Víctor and everybody.
>>>>>>>> I've been taking a deeper look on the locks notification issue.
>>>>>>>> I'm,
>>>>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>>>>> completely just yet.
>>>>>>>>
>>>>>>> In the meantime I added some hints to
>>>>>>> https://bugs.eclipse.org/283274
>>>>>>>
>>>>>>>
>>>>>>>> What I was able to figure out is, parting from the editor (the
>>>>>>>> objective is to somehow graphically indicate that objects are being
>>>>>>>> locked by other sessions), I can do:
>>>>>>>> -editor.getView().getSession() and get the session (and from there
>>>>>>>> getRemoteSessionManager() and get the manager that knows about all
>>>>>>>> sessions, which I guess this is not of great use to me).
>>>>>>>>
>>>>>>> The remote session manager could be used for the new notification
>>>>>>> protocol, but in this case I'd prefer to do it directly in
>>>>>>> CDOSessionProtocol (see the bugzilla).
>>>>>>>
>>>>>>>
>>>>>>>> -I can also get, from the CDOEditor, the CDOEventHandler, which has
>>>>>>>> its own IListeners.
>>>>>>>>
>>>>>>>> Recalling, the final intention is to notify/get notified that a
>>>>>>>> lock
>>>>>>>> has been obtained on some model element.
>>>>>>>> My current idea (without great knowledge of CDO's architecture)
>>>>>>>> of how
>>>>>>>> things should go:
>>>>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on
>>>>>>>> that).
>>>>>>>>
>>>>>>> Yes. How much information should we provide in these events, just
>>>>>>> the
>>>>>>> objects that were locked/unlocked, or the sessions (views?) that
>>>>>>> caused
>>>>>>> these transitions?
>>>>>>>
>>>>>>>
>>>>>>>> 2) Make my CDOSession fire these events (as in
>>>>>>>> fireInvalidationEvent).
>>>>>>>> I believe they should be fired from
>>>>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are
>>>>>>>> not in
>>>>>>>> CDOSession interface).
>>>>>>>>
>>>>>>> No, these methods serve a completely different purpose. Since
>>>>>>> locking
>>>>>>> always happens in the scope of a CDOView, the view should fire
>>>>>>> these new
>>>>>>> events. The events themselves must not originate from monly the
>>>>>>> client
>>>>>>> side because you really want them to reflect transitions from other
>>>>>>> (remote) sessions/views. I explained in the bugzilla where they
>>>>>>> really
>>>>>>> originate from.
>>>>>>>
>>>>>>>
>>>>>>>> 3) Check for these events in my editor's EventHandler (by
>>>>>>>> subclassing
>>>>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>>>>> perhaps).
>>>>>>>>
>>>>>>> The reflection of the locking state in the UI is indeed separate
>>>>>>> from
>>>>>>> the core functonality that has to be added. But yes, your editor
>>>>>>> should
>>>>>>> listen to the new events and update the label decoration
>>>>>>> appropriately.
>>>>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>>>>
>>>>>>>
>>>>>>>> And then some doubts arise (thanks again to my short knowledge
>>>>>>>> of CDO):
>>>>>>>> May I assume that such new events will get notified to my
>>>>>>>> EventHandler
>>>>>>>> by default, or must I modify something in between?.
>>>>>>>>
>>>>>>> I like the idea of exposing them through CDOEventHandler.
>>>>>>>
>>>>>>>
>>>>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>>>>> And, most of all, is the whole strategy correct?.
>>>>>>>>
>>>>>>> Most of it ;-)
>>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>>
>>>>>>> ----
>>>>>>> http://thegordian.blogspot.com
>>>>>>> http://twitter.com/eikestepper
>>>>>>>
>>>>>>>
|
|
|
| Re: [CDO] Event Notification procedure ->NPE [message #496537 is a reply to message #496534] |
Tue, 10 November 2009 13:22 |
|
Juan Pedro Silva Gallino schrieb:
> Hi Eike.
> Sorry if my diagram mislead you. No, I realize that each session has
> it own lock manager, and the server protocol reacts to lock requests
> with signal reactors. Anyhow, I may still not have the whole picture
> in my mind.
> I will do as you suggested and attach my code to the bugzilla after I
> clean it up a little.
Thx! I'll comment there...
Cheers
/Eike
----
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> Regards,
> JP
>
>
> Eike Stepper escribió:
>> One more note:
>>
>> I just noticed the diagram you attached. You seem to think that the
>> LockManager in the CDOSessionImpl is related to server-side locking, but
>> that's not true! It's really "only" a local thread synchronization
>> thing. It's best to ignore it for your purpose.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Juan Pedro Silva Gallino schrieb:
>>> Hi Eike.
>>> I'm trying to progress in the remote locking notification.
>>> I've been debugging a little to see how the flow of the application
>>> when locks are requested. I'm attaching a class diagram that reflects
>>> what I have grasped so far.
>>>
>>> According to my understanding, when a lock is solicited,
>>> CDOClientProtocol.lockObjects(....), which in turn sends a new
>>> LockObjectsRequest(..) (a subclass of signal).
>>>
>>> CDOServerProtocl captures the CDOProtocolConstants.SIGNAL_LOCK_OBJECTS
>>> signal with its signal reactor, creating a new
>>> LockObjectsIndication(..).
>>>
>>> This is the client -> server part of the communication. Now I need the
>>> server -> client part, so that the rest of the clients are notified of
>>> the locks. From the CDOServerProtocol I can get to the respository,
>>> the SessionManager, and get all the sessions on that repository. I
>>> can check with each session if they have registered lock listeners
>>> and, if so, call "sendRemoteLockNotification(IView, List<CDOID>,
>>> LockType)" (new, similar to the "sendRemoteMessageNotification"
>>> method).
>>>
>>> I don't know if you agree with the strategy. I tried to implement the
>>> notification loop in LockObjectsIndication.indicating(..), as it was a
>>> reaction to the lock objects request (although I'm not completely sure
>>> this is the best place to do this). Anyhow, I'm facing a problem: when
>>> I try to send the LockNotificationRequest, I get a NPE (the stack
>>> trace is below the message). Suggestions?.
>>>
>>> I look forward to your comments.
>>> Regards,
>>> Juan Pedro
>>>
>>>
>>> [ERROR] NullPointerException
>>> java.lang.NullPointerException
>>> at org.eclipse.emf.common.util.URI.createURIWithCache(URI.java: 669)
>>> at org.eclipse.emf.common.util.URI.createURI(URI.java:541)
>>> at
>>> org.eclipse.emf.cdo.common.model.EMFUtil.createEcoreResource (EMFUtil.java:269)
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.common.model.EMFUtil.createEPackage(EMFU til.java:248)
>>>
>>> at
>>> org.eclipse.emf.cdo.common.model.CDOModelUtil.readPackage(CD OModelUtil.java:393)
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.model.CDOPackageUnitImpl .read(CDOPackageUnitImpl.java:282)
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnit(CDODataInputImpl.java:88)
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.common.io.CDODataInputImpl.read CDOPackageUnits(CDODataInputImpl.java:103)
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.net4j.protocol.CommitNotificati onIndication.indicating(CommitNotificationIndication.java:56 )
>>>
>>>
>>> at
>>> org.eclipse.emf.cdo.internal.net4j.protocol.CDOClientIndicat ion.indicating(CDOClientIndication.java:54)
>>>
>>>
>>> at
>>> org.eclipse.net4j.signal.Indication.doExtendedInput(Indicati on.java:55)
>>> at org.eclipse.net4j.signal.Signal.doInput(Signal.java:312)
>>> at org.eclipse.net4j.signal.Indication.execute(Indication.java: 49)
>>> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:239)
>>> at org.eclipse.net4j.signal.Signal.run(Signal.java:147)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
>>> Source)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>> Source)
>>> at java.lang.Thread.run(Unknown Source)
>>>
>>>
>>>
>>> Eike Stepper escribió:
>>>> Hi Juan Pedro,
>>>>
>>>> Comments below...
>>>>
>>>>
>>>> Juan Pedro Silva schrieb:
>>>>> Eike, I need guidance, as I believe I may have to introduce a new
>>>>> package dependency.
>>>> Let's try to avoid that if it introduces a cycle :P
>>>>
>>>>> I'm implementing the (un)registration mechanism for the locks
>>>>> notification.
>>>>> The situation is the following:
>>>>>
>>>>> -CDOSessionImpl knows of
>>>>> org.eclipse.net4j.util.concurrent.IRWLockManager and
>>>>> org.eclipse.net4j.util.concurrent.RWLockManager,
>>>> Yes, but only to refer to the nested LockType.
>>>>
>>>>> but knows nothing of org.eclipse.emf.cdo.internal.server.LockManager.
>>>> Yes, the client side is not involved in actual lock management.
>>>>
>>>>> Besides, RWLockManager performs the actual locking/unlocking that
>>>>> should be notified, so I though I should introduce the mechanism in
>>>>> RWLockManager. However, I was under the impression you rather have me
>>>>> do it in LockManager.
>>>>> -RWLockManager doesn't know CDOSession, ISession, or
>>>>> InternalCDOSession. If I import any of those packages in
>>>>> RWLockManager, I create a cycle.
>>>>> -On the other side, LockManager knows ISession, but CDOSession
>>>>> doesn't
>>>>> know him as it's internal.
>>>> Yes, all the locking management code is in Net4j's RWLockManager and
>>>> that's really the originating area for the new lock notifications. The
>>>> CDO LockManager is just a very thin wrapper around RWLockManager that
>>>> automates the task of releasing all locks of sessions that have been
>>>> closed.
>>>>
>>>>
>>>>> How do you suggest I make the lock manager and the session aware of
>>>>> each other?, which type should I use for the list of registered
>>>>> sessions and where?.
>>>> RWLockManager extends Lifecycle, which in turn extends Notifier. So
>>>> you
>>>> can fire events from within the RWLockManager that are handled in
>>>> higher
>>>> layers. A more performant approach would be to add some protected
>>>> methods in RWLockManager that are overwritten in LockManager.
>>>>
>>>> Doeos that help?
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>> ----
>>>> http://thegordian.blogspot.com
>>>> http://twitter.com/eikestepper
>>>>
>>>>
>>>>> Look forward to your answer.
>>>>> Regards,
>>>>> Juan Pedro
>>>>>
>>>>> Eike Stepper escribió:
>>>>>> Juan Pedro Silva Gallino schrieb:
>>>>>>
>>>>>>> Hi Eike, thanks for your answer.
>>>>>>> I saw your post on the bug. Those kinds of insights are
>>>>>>> fundamental to
>>>>>>> me.
>>>>>>> I'll try to get my hands dirty on this (depends on the time left by
>>>>>>> other activities), and will get back to you with any news.
>>>>>>>
>>>>>> Excellent! Don't hesitate to ask if you need further help ;-)
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>> ----
>>>>>> http://thegordian.blogspot.com
>>>>>> http://twitter.com/eikestepper
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Best regards,
>>>>>>> Juan Pedro
>>>>>>>
>>>>>>> Eike Stepper escribió:
>>>>>>>
>>>>>>>> Hi Juan Pedro,
>>>>>>>>
>>>>>>>> Comments below...
>>>>>>>>
>>>>>>>>
>>>>>>>> Juan Pedro Silva schrieb:
>>>>>>>>
>>>>>>>>> Hi Víctor and everybody.
>>>>>>>>> I've been taking a deeper look on the locks notification issue.
>>>>>>>>> I'm,
>>>>>>>>> however, very new to CDO, so I haven't been able able to grasp it
>>>>>>>>> completely just yet.
>>>>>>>>>
>>>>>>>> In the meantime I added some hints to
>>>>>>>> https://bugs.eclipse.org/283274
>>>>>>>>
>>>>>>>>
>>>>>>>>> What I was able to figure out is, parting from the editor (the
>>>>>>>>> objective is to somehow graphically indicate that objects are
>>>>>>>>> being
>>>>>>>>> locked by other sessions), I can do:
>>>>>>>>> -editor.getView().getSession() and get the session (and from
>>>>>>>>> there
>>>>>>>>> getRemoteSessionManager() and get the manager that knows about
>>>>>>>>> all
>>>>>>>>> sessions, which I guess this is not of great use to me).
>>>>>>>>>
>>>>>>>> The remote session manager could be used for the new notification
>>>>>>>> protocol, but in this case I'd prefer to do it directly in
>>>>>>>> CDOSessionProtocol (see the bugzilla).
>>>>>>>>
>>>>>>>>
>>>>>>>>> -I can also get, from the CDOEditor, the CDOEventHandler,
>>>>>>>>> which has
>>>>>>>>> its own IListeners.
>>>>>>>>>
>>>>>>>>> Recalling, the final intention is to notify/get notified that a
>>>>>>>>> lock
>>>>>>>>> has been obtained on some model element.
>>>>>>>>> My current idea (without great knowledge of CDO's architecture)
>>>>>>>>> of how
>>>>>>>>> things should go:
>>>>>>>>> 1) Define my new type of IEvent (perhaps more than one, LockEvent
>>>>>>>>> (Read and Write) and ReleaseLockEvent, I have to think deeper on
>>>>>>>>> that).
>>>>>>>>>
>>>>>>>> Yes. How much information should we provide in these events, just
>>>>>>>> the
>>>>>>>> objects that were locked/unlocked, or the sessions (views?) that
>>>>>>>> caused
>>>>>>>> these transitions?
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2) Make my CDOSession fire these events (as in
>>>>>>>>> fireInvalidationEvent).
>>>>>>>>> I believe they should be fired from
>>>>>>>>> "CDOSessionImpl.acquireAtomicRequestLock()" and
>>>>>>>>> "CDOSessionImpl.releaseAtomicRequestLock()" (those methods are
>>>>>>>>> not in
>>>>>>>>> CDOSession interface).
>>>>>>>>>
>>>>>>>> No, these methods serve a completely different purpose. Since
>>>>>>>> locking
>>>>>>>> always happens in the scope of a CDOView, the view should fire
>>>>>>>> these new
>>>>>>>> events. The events themselves must not originate from monly the
>>>>>>>> client
>>>>>>>> side because you really want them to reflect transitions from
>>>>>>>> other
>>>>>>>> (remote) sessions/views. I explained in the bugzilla where they
>>>>>>>> really
>>>>>>>> originate from.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 3) Check for these events in my editor's EventHandler (by
>>>>>>>>> subclassing
>>>>>>>>> CDOEventHandler and adding a new "IListener lockEventListener",
>>>>>>>>> perhaps).
>>>>>>>>>
>>>>>>>> The reflection of the locking state in the UI is indeed separate
>>>>>>>> from
>>>>>>>> the core functonality that has to be added. But yes, your editor
>>>>>>>> should
>>>>>>>> listen to the new events and update the label decoration
>>>>>>>> appropriately.
>>>>>>>> I suggest that we use the new events in our CDOEditor, too.
>>>>>>>>
>>>>>>>>
>>>>>>>>> And then some doubts arise (thanks again to my short knowledge
>>>>>>>>> of CDO):
>>>>>>>>> May I assume that such new events will get notified to my
>>>>>>>>> EventHandler
>>>>>>>>> by default, or must I modify something in between?.
>>>>>>>>>
>>>>>>>> I like the idea of exposing them through CDOEventHandler.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Are those the most appropriate classes/methods to specialize?.
>>>>>>>>> And, most of all, is the whole strategy correct?.
>>>>>>>>>
>>>>>>>> Most of it ;-)
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>> ----
>>>>>>>> http://thegordian.blogspot.com
>>>>>>>> http://twitter.com/eikestepper
>>>>>>>>
>>>>>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:46:22 GMT 2024
Powered by FUDForum. Page generated in 0.04101 seconds |
] 
Search
Help
Register
Login
Home
