[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470294 ] Craig Russell commented on OPENJPA-117: --- Maybe this case would best be handled by having the TransactionListener itself register for the event. I'm assuming that the listener is stateful and is listening on a specific Broker. Then add a method on the TransactionListenerImpl like void listenOn(Broker broker). If it is already listening on the parameter, it returns. Otherwise it registers itself. This can be exended if a listener can listen on multiple Brokers. In that case, the listener can manage a Set of Brokers that it is listening on. I'm not so concerned about different users of a Broker getting information about other users. As Abe points out, all the actors who share a Broker are already intimately connected, and any one can cause damage. So it's not about isolation, it's more about separation of concerns. In this case, why should an actor care if a listener is already listening? The listener can be active making sure it's not registered multiple times with the same Broker. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469093 ] Pinaki Poddar commented on OPENJPA-117: --- > Adding listeners should generally either be done as an initialization step Of course. The use case that prompted the request is the code that registers listeners do not initialize Persistence/EntityManagers. At least that is what I gathered from the users' input. Did not feel 'strongly' about the use case either which reflects in the 'minor' priority of the request. As an alternative, one may consider a listener mechanism attached to the BrokerFactory itself that will notify creation/closure of managed Brokers. Then a user code that does not explictly control Broker may get a hook during broker initialization/closure. Exposing list of listeners does raise the concern about one user removing others listeners -- but isn't one of the prevailing themes of OpenJPA architecture thrieves upon the users having deep visibility and customization of its myriad internal features? > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Hello Abe, in our use Case we need the Transactionlister to implement an audit-log on PC-Object and PC-Object-Attributelevel. Because were a building a item/masterdata-Management-system. One of the main targets is to track every change on the Masterdata and then to export the Change to over 100 other Systems. In our case we want to use OPEN-JPA Broker-Listeners to replace a whole bunch of oracle Database triggers, because they make us some headaches. If you want more details, feel free to ask for. regards Marcus -Ursprüngliche Nachricht- Von: Abe White (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 21:16 An: open-jpa-dev@incubator.apache.org Betreff: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection [ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468770 ] Abe White commented on OPENJPA-117: --- I don't see why listeners are some special case that require more isolation than all of the other state we expose. There are tons of things you can do with a broker,etc to screw other users of that broker,etc. I don't see how this is unique. That said, I also think the proposed use case is weak. I'd question the quality of an application that had code paths that could result in the same listener being added twice. Adding listeners should generally either be done as an initialization step or as a temporary step where the listener is removed immediately following a specific action. It's hard to imagine a scenario where listeners are added so haphazardly that duplicates could occur. I'd be interested to hear a more concrete use case. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
> 1. Why could the Transactionlister not have the same > structure of API as the Instancelifecycle Listener. That mean > configuring a Default Transactionlister with the > brokerfactory, reading actual transactionlistener's in the > broker and manipulating actual transactionlisterners (that > means deactivating or changing) Personally, I think that this would be very useful. To extend on this, I think it'd be nice to be able to configure default TxListeners and InstanceLifecycleListeners declaratively, in the OpenJPA properties. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -Original Message- > From: Thierling, Marcus (Salt Solutions) > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 31, 2007 1:22 AM > To: open-jpa-dev@incubator.apache.org > Subject: AW: [jira] Commented: (OPENJPA-117) Collection of > TransactionListeners registered to a Broker should be > available as unmodifiable collection > > Hello, > > the request from Pinaki regarding the transactionlistener > also are in our business need. The actual possibility of > Transactionlistener API are to small in OPEN-JPA/Kodo. It > would be great when the folloing apsects could be considered. > > 1. Why could the Transactionlister not have the same > structure of API as the Instancelifecycle Listener. That mean > configuring a Default Transactionlister with the > brokerfactory, reading actual transactionlistener's in the > broker and manipulating actual transactionlisterners (that > means deactivating or changing) > > 2. I can understand your concerns Patrick, but I'm as a > customer can tell you that KODO is great becouse you can > configure and change so much in the deep of brokers and > factory's...The responsibility not to build something what is > not working, is at the teams which are using Open-JPA. E.g. > in our team the code and Configuration which is making all > the lister stuff is "holy", that means almost untouchable > (only for the priest's)(;-). So the normal developer is not > allowed to change something on the listener Configuration. > > My post is not so on that technical Level, but I've > understand the mailing list also as a place for committing > and discussing Changerequest. When it is wanted, I could give > sometimes a view from a OPEN-JPA user. Pinaki knows a little > bit about our projects, because he was involevd in Workshop > in november in Hamburg. > > many Regards > > Marcus Thierling > > > -----Ursprüngliche Nachricht----- > Von: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 30. Januar 2007 19:38 > An: open-jpa-dev@incubator.apache.org > Betreff: [jira] Commented: (OPENJPA-117) Collection of > TransactionListeners registered to a Broker should be available as > unmodifiable collection > > > > [ > https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atl assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468735 > ] > > Patrick Linskey commented on OPENJPA-117: > - > > The problem is that this lets party A get what party B set. > So if one bit of code added a particular listener, a > different bit of code could then get the listener and remove > it. Is this something that we want to make easy for people to > do? It seems like different listeners should be relatively > isolated from each other. > > > Collection of TransactionListeners registered to a Broker > should be available as unmodifiable collection > > > -- > -- > > > > Key: OPENJPA-117 > > URL: > https://issues.apache.org/jira/browse/OPENJPA-117 > > Project: OpenJPA > > Issue Type: Improvement > > Components: kernel > >Reporter: Pinaki Poddar > > Assigned To: Pinaki Poddar > >Priority: Minor > > > > Currently TransactionListeners can be added/removed to a > broker but the list of transaction listeners registered to a > particular broker is not available. Such a collection can be > made available in read-only mode so a caller can determine > whether to add a new listener or not, or whether a particular > listener is already registered. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
AW: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
Hello, the request from Pinaki regarding the transactionlistener also are in our business need. The actual possibility of Transactionlistener API are to small in OPEN-JPA/Kodo. It would be great when the folloing apsects could be considered. 1. Why could the Transactionlister not have the same structure of API as the Instancelifecycle Listener. That mean configuring a Default Transactionlister with the brokerfactory, reading actual transactionlistener's in the broker and manipulating actual transactionlisterners (that means deactivating or changing) 2. I can understand your concerns Patrick, but I'm as a customer can tell you that KODO is great becouse you can configure and change so much in the deep of brokers and factory's...The responsibility not to build something what is not working, is at the teams which are using Open-JPA. E.g. in our team the code and Configuration which is making all the lister stuff is "holy", that means almost untouchable (only for the priest's)(;-). So the normal developer is not allowed to change something on the listener Configuration. My post is not so on that technical Level, but I've understand the mailing list also as a place for committing and discussing Changerequest. When it is wanted, I could give sometimes a view from a OPEN-JPA user. Pinaki knows a little bit about our projects, because he was involevd in Workshop in november in Hamburg. many Regards Marcus Thierling -Ursprüngliche Nachricht- Von: Patrick Linskey (JIRA) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 30. Januar 2007 19:38 An: open-jpa-dev@incubator.apache.org Betreff: [jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection [ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468735 ] Patrick Linskey commented on OPENJPA-117: - The problem is that this lets party A get what party B set. So if one bit of code added a particular listener, a different bit of code could then get the listener and remove it. Is this something that we want to make easy for people to do? It seems like different listeners should be relatively isolated from each other. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468770 ] Abe White commented on OPENJPA-117: --- I don't see why listeners are some special case that require more isolation than all of the other state we expose. There are tons of things you can do with a broker,etc to screw other users of that broker,etc. I don't see how this is unique. That said, I also think the proposed use case is weak. I'd question the quality of an application that had code paths that could result in the same listener being added twice. Adding listeners should generally either be done as an initialization step or as a temporary step where the listener is removed immediately following a specific action. It's hard to imagine a scenario where listeners are added so haphazardly that duplicates could occur. I'd be interested to hear a more concrete use case. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468735 ] Patrick Linskey commented on OPENJPA-117: - The problem is that this lets party A get what party B set. So if one bit of code added a particular listener, a different bit of code could then get the listener and remove it. Is this something that we want to make easy for people to do? It seems like different listeners should be relatively isolated from each other. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468734 ] Abe White commented on OPENJPA-117: --- I don't think we should encourage use of user objects for tracking state we could trivially expose ourselves. Most of our APIs allow you to "get" anything you can "set", so I agree with Pinaki's approach of exposing the listener collection unless our internal bookkeeping mechanism in this case makes it inefficient for some reason. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[
https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468724
]
Patrick Linskey commented on OPENJPA-117:
-
So an alternate approach that would not expose any additional interfaces would
be for the code to call Broker.putUserObject() at the same time as it set up
the listener, and then check the user object beferehand:
OpenJPAEntityManager oem = OpenJPAPersistence.cast(em);
if (oem.getUserObject(MyListener.class) == null) {
TransactionListener tl = new MyListener();
oem.addTransactionListener(tl);
oem.putUserObject(MyListener.class, tl);
}
> Collection of TransactionListeners registered to a Broker should be available
> as unmodifiable collection
>
>
> Key: OPENJPA-117
> URL: https://issues.apache.org/jira/browse/OPENJPA-117
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
>Reporter: Pinaki Poddar
> Assigned To: Pinaki Poddar
>Priority: Minor
>
> Currently TransactionListeners can be added/removed to a broker but the list
> of transaction listeners registered to a particular broker is not available.
> Such a collection can be made available in read-only mode so a caller can
> determine whether to add a new listener or not, or whether a particular
> listener is already registered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468719 ] Pinaki Poddar commented on OPENJPA-117: --- The use case is the code that intends to register a listener but gets the PersistenceManager/EntityManager from another layer outside of its own control. Then the registerer does not know whether the obtained PM/EM is already carrying a particular listener or not. Currently the internal collection of listener is not a Set, so unconditionally adding a listener results in duplicates. > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468711 ] Patrick Linskey commented on OPENJPA-117: - What's the use case for this? If someone were to write code that cannot track for itself what it's done, the code could always add a user object (Broker.putUserObject()). > Collection of TransactionListeners registered to a Broker should be available > as unmodifiable collection > > > Key: OPENJPA-117 > URL: https://issues.apache.org/jira/browse/OPENJPA-117 > Project: OpenJPA > Issue Type: Improvement > Components: kernel >Reporter: Pinaki Poddar > Assigned To: Pinaki Poddar >Priority: Minor > > Currently TransactionListeners can be added/removed to a broker but the list > of transaction listeners registered to a particular broker is not available. > Such a collection can be made available in read-only mode so a caller can > determine whether to add a new listener or not, or whether a particular > listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
