[VOTE] Release of Apache Directory Studio Maven Plugin 1.0.5 (Take 2)
Hi guys, I've managed to fix the bugs that prevented the release (obscure things needed to be configured for this to work). This release fixes a minor bug: - DIRSTUDIO-660 ([Maven Studio Plugin] Unify naming for 'outputDirectory' accross goals) [1] The staging repository is available at [2]. The documentation has been uploaded and will be available within the hour at [3]. Let's vote now: [ ] +1 | Release Apache Directory Studio Maven Plugin 1.0.5 [ ] +/-0 | Abstain [ ] -1 | Do NOT release Apache Directory Studio Maven Plugin 1.0.5 Regards, Pierre-Arnaud [1] - https://issues.apache.org/jira/browse/DIRSTUDIO-660 [2] - https://repository.apache.org/content/repositories/orgapachedirectory-375/ [3] - http://directory.apache.org/studio-plugin/gen-docs/1.0.5/
Re: [VOTE] Release of Apache Directory Studio Maven Plugin 1.0.5 (Take 2)
+1 - have not checked the release though On Tue, Dec 20, 2011 at 3:09 PM, Pierre-Arnaud Marcelot wrote: > Hi guys, > > I've managed to fix the bugs that prevented the release (obscure things > needed to be configured for this to work). > > This release fixes a minor bug: > - DIRSTUDIO-660 ([Maven Studio Plugin] Unify naming for 'outputDirectory' > accross goals) [1] > > The staging repository is available at [2]. > The documentation has been uploaded and will be available within the hour > at [3]. > > Let's vote now: > [ ] +1 | Release Apache Directory Studio Maven Plugin 1.0.5 > [ ] +/-0 | Abstain > [ ] -1 | Do NOT release Apache Directory Studio Maven Plugin 1.0.5 > > Regards, > Pierre-Arnaud > > [1] - https://issues.apache.org/jira/browse/DIRSTUDIO-660 > [2] - > https://repository.apache.org/content/repositories/orgapachedirectory-375/ > [3] - http://directory.apache.org/studio-plugin/gen-docs/1.0.5/ > -- Best Regards, -- Alex
Re: [VOTE] Release of Apache Directory Studio Maven Plugin 1.0.5 (Take 2)
[X] +1 | Release Apache Directory Studio Maven Plugin 1.0.5 Documentation looks good now, thanks for fixing it. Regards Felix
Re: [VOTE] Release of Apache Directory Studio Maven Plugin 1.0.5 (Take 2)
[X] +1 | Release Apache Directory Studio Maven Plugin 1.0.5 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Transactions and Search/Cursor
Hi,
I have added txns support in LdapCoreSessionConnection, but I have some
issues with searches : the txn has to remain opened until the cursor is
closed. That means the cursor must retain the txns and that the commit
is done in the cursor.close() operation.
I think we can use the inner ClosureMonitor to do that, but the question
is what should we do when we get an exception during the search ? I
would suggest that a search is done this way :
Cursor cursor = null;
try
{
cursor = connection.search( blah ) // The txn is started and stored
into the ClosureMonitor
while (cursor.next())
{
Entry result = cursor.get();
// do whatever is needed with the entry
}
}
finally
{
cursor.close(); // Here, the cursor holds the current status for the
search : successful or failure.
// If successful, do a commit, otherwise, do a rollback
}
Does it makes sense ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
TxnManager should be moved to shared-ldap
Hi, if we want to make the search operation part of the transaction, then we may need to move the Txnmanager to the shared-ldap library, as we don't see this class from any cursor. The need is to be able to commit or rollback the txn when the cursor.close() is done (or if we've got an exception). I'll check if it's possible. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: TxnManager should be moved to shared-ldap
On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny wrote: > Hi, > > if we want to make the search operation part of the transaction, then we > may need to move the Txnmanager to the shared-ldap library, as we don't see > this class from any cursor. > > I see what you mean. But there are ways in which we can decouple things without having to have TxnManager moved. This can be done by registering for Cursor close notification and there the transaction manager can be called within an Observer type object. First of all I was wondering if we can use the Java Transaction API here at all to prevent re-inventing these interfaces. Have not looked at the overlap. > The need is to be able to commit or rollback the txn when the > cursor.close() is done (or if we've got an exception). > > Again I think we can decouple this with notifications/callbacks. -- Best Regards, -- Alex
Re: TxnManager should be moved to shared-ldap
I am saying this because clearly TxnManager does not belong in shared if we just step back and think about it. Yes the mechanics of the code is making us consider this but we should resist and see what we can do with some pattern to decouple this. On Tue, Dec 20, 2011 at 7:00 PM, Alex Karasulu wrote: > > On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny wrote: > >> Hi, >> >> if we want to make the search operation part of the transaction, then we >> may need to move the Txnmanager to the shared-ldap library, as we don't see >> this class from any cursor. >> >> > I see what you mean. But there are ways in which we can decouple things > without having to have TxnManager moved. This can be done by registering > for Cursor close notification and there the transaction manager can be > called within an Observer type object. > > First of all I was wondering if we can use the Java Transaction API here > at all to prevent re-inventing these interfaces. Have not looked at the > overlap. > > >> The need is to be able to commit or rollback the txn when the >> cursor.close() is done (or if we've got an exception). >> >> > Again I think we can decouple this with notifications/callbacks. > > -- > Best Regards, > -- Alex > > -- Best Regards, -- Alex
Re: Transactions and Search/Cursor
On Tue, Dec 20, 2011 at 4:50 PM, Emmanuel Lecharny wrote:
> Hi,
>
> I have added txns support in LdapCoreSessionConnection, but I have some
> issues with searches : the txn has to remain opened until the cursor is
> closed. That means the cursor must retain the txns and that the commit is
> done in the cursor.close() operation.
>
>
We need the connection to register a callback with the cursor. That way
when it is closed we can have the LCSConnection actually close the txn.
> I think we can use the inner ClosureMonitor to do that, but the question
> is what should we do when we get an exception during the search ? I would
> suggest that a search is done this way :
>
> Cursor cursor = null;
> try
> {
> cursor = connection.search( blah ) // The txn is started and stored into
> the ClosureMonitor
>
> while (cursor.next())
> {
>Entry result = cursor.get();
>// do whatever is needed with the entry
> }
> }
> finally
> {
> cursor.close(); // Here, the cursor holds the current status for the
> search : successful or failure.
> // If successful, do a commit, otherwise, do a rollback
> }
>
> Does it makes sense ?
>
>
How does the ClosureMonitor fit into this code above? This must be a new
class I guess ... this is the first time I am seeing it. I should take a
look at this code.
--
Best Regards,
-- Alex
Re: TxnManager should be moved to shared-ldap
Hi Alex, I just discussed this with Emmanuel, and like you, I think the transaction does not belong in shared. It's really meant to be placed between the piece of code which captures LDAP requests on the server and the various partition back-end implementations. I haven't looked at the code closely, but I think a simple class extending our cursor implementation in shared, with the close() method overridden, should probably do the trick. This would leave most of the cursor behavior implementation in shared where we need "basic" cursor, while letting us do additional stuff on the server side by overriding methods and calling super.methodName() to inherit the default behavior. Regards, Pierre-Arnaud On 20 déc. 2011, at 18:01, Alex Karasulu wrote: > I am saying this because clearly TxnManager does not belong in shared if we > just step back and think about it. Yes the mechanics of the code is making us > consider this but we should resist and see what we can do with some pattern > to decouple this. > > On Tue, Dec 20, 2011 at 7:00 PM, Alex Karasulu wrote: > > On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny > wrote: > Hi, > > if we want to make the search operation part of the transaction, then we may > need to move the Txnmanager to the shared-ldap library, as we don't see this > class from any cursor. > > > I see what you mean. But there are ways in which we can decouple things > without having to have TxnManager moved. This can be done by registering for > Cursor close notification and there the transaction manager can be called > within an Observer type object. > > First of all I was wondering if we can use the Java Transaction API here at > all to prevent re-inventing these interfaces. Have not looked at the overlap. > > The need is to be able to commit or rollback the txn when the cursor.close() > is done (or if we've got an exception). > > > Again I think we can decouple this with notifications/callbacks. > > -- > Best Regards, > -- Alex > > > > > -- > Best Regards, > -- Alex >
[Studio] Setting the 'Apache Directory LDAP API' as the default network provider
Hi guys, Today, I have introduced a change in the Connection Core plugin of Apache Directory Studio to set the 'Apache Directory LDAP API' as the default network provider, instead of JNDI. I think it's safe to say that the LDAP API is now a great alternative to JNDI. It might still lack a few features here and there, like pulling a schema manager from a connection or the lack a connection pool, but from Studio's standpoint, each feature we used from JNDI has now an equivalent in the LDAP API. I have added a new setting in the 'Connections' preferences page [1] where the user can choose its preferred default network provider (either 'Apache Directory LDAP API', the default value, or 'JNDI'). The user can still decide which network provider to use on a per connection basis in the 'New Connection' Wizard page or the 'Connection' Properties page [2]. I believe this move can give a lot of credit to the LDAP API and help us promote it towards the general public. (It might also be helpful in the beginning to help find hidden bugs I guess.) WDYT? Should we go in this direction or should we rollback to 'JNDI' as default setting? Regards, Pierre-Arnaud [1] - http://cl.ly/Cl1B [2] - http://cl.ly/CkPF
Re: [Studio] Setting the 'Apache Directory LDAP API' as the default network provider
On Tue, Dec 20, 2011 at 11:13 PM, Pierre-Arnaud Marcelot wrote: > Hi guys, > > Today, I have introduced a change in the Connection Core plugin of Apache > Directory Studio to set the 'Apache Directory LDAP API' as the default > network provider, instead of JNDI. > > I think it's safe to say that the LDAP API is now a great alternative to JNDI. > It might still lack a few features here and there, like pulling a schema > manager from a connection or the lack a connection pool, but from Studio's > standpoint, each feature we used from JNDI has now an equivalent in the LDAP > API. > > I have added a new setting in the 'Connections' preferences page [1] where > the user can choose its preferred default network provider (either 'Apache > Directory LDAP API', the default value, or 'JNDI'). > The user can still decide which network provider to use on a per connection > basis in the 'New Connection' Wizard page or the 'Connection' Properties page > [2]. > > I believe this move can give a lot of credit to the LDAP API and help us > promote it towards the general public. (It might also be helpful in the > beginning to help find hidden bugs I guess.) > > WDYT? > Should we go in this direction or should we rollback to 'JNDI' as default > setting? > +1 to keep the client API as default provider thanks Pierre-Arnaud > Regards, > Pierre-Arnaud > > [1] - http://cl.ly/Cl1B > [2] - http://cl.ly/CkPF -- Kiran Ayyagari
[Studio] Releasing a first milestone for version 2.0 (2.0.0-M1) soon?
Hi (again) guys, As you might have noticed, I took some time last week to go on a JIRA fixing campaign on Apache Directory Studio. With the recent developments, I think we are nearing a possible release of a first milestone for version 2.0. Of course, it still needs some work but various reasons makes me think we should probably consider releasing the first milestone really soon: 1°/ It's been more than 20 months since the last release (April 5th, 2010). That's really a shame, but it's the reality… :( Such a long time without a release gives a very bad impression on users. Almost like if Studio was an abandoned project... 2°/ Milestone releases worked well on the API and ApacheDS. We've had some great results from milestone releases on these projects. Even if they are not stable and production-ready yet, they have helped us get back in touch with our users and forced us to focus on specific key-features for each iteration. 3°/ A hell lot of things have changed in Studio, with lots of improvements and bug fixes. I can't name everything but it includes things like: - the inclusion of the Apache Directory LDAP API as network provider (as a replacement for JNDI - which is still selectable) - the use of Shared's SchemaManager in the Schema Editor - the rewrite of the ApacheDS plugins into something more open, the LDAP Servers plugin - the new ApacheDS V2 Configuration Plugin which edits via LDAP and LDIF the configuration of an ApacheDS 2.0 server - the update of Eclipse dependencies and launchers to the latest and greatest versions - many bug fixes, improvements and feature requests This mail isn't to vote about the release yet. A few things really need to be polished first. But I'd like to get your thoughts about a possible release of a first milestone for version 2.0 in the next days/weeks. Thanks, Pierre-Arnaud
Re: Transactions and Search/Cursor
On 12/20/11 6:04 PM, Alex Karasulu wrote:
On Tue, Dec 20, 2011 at 4:50 PM, Emmanuel Lecharnywrote:
Hi,
I have added txns support in LdapCoreSessionConnection, but I have some
issues with searches : the txn has to remain opened until the cursor is
closed. That means the cursor must retain the txns and that the commit is
done in the cursor.close() operation.
We need the connection to register a callback with the cursor. That way
when it is closed we can have the LCSConnection actually close the txn.
I think we can use the inner ClosureMonitor to do that, but the question
is what should we do when we get an exception during the search ? I would
suggest that a search is done this way :
Cursor cursor = null;
try
{
cursor = connection.search( blah ) // The txn is started and stored into
the ClosureMonitor
while (cursor.next())
{
Entry result = cursor.get();
// do whatever is needed with the entry
}
}
finally
{
cursor.close(); // Here, the cursor holds the current status for the
search : successful or failure.
// If successful, do a commit, otherwise, do a rollback
}
Does it makes sense ?
How does the ClosureMonitor fit into this code above? This must be a new
class I guess ... this is the first time I am seeing it. I should take a
look at this code.`
Forget about this stupid proposal. I must have been sleepy when I wrote
that...
We discussed with Pierre-Arnaud, and it's clear that the txn must *not*
be stored into the monitor, not does it hs to be moved to shared : there
is no reason for the API to expose something which is just for our
internal use.
I have started to refactor the refactoring to come back with something
sane.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Studio] Releasing a first milestone for version 2.0 (2.0.0-M1) soon?
On 12/20/11 7:09 PM, Pierre-Arnaud Marcelot wrote: Hi (again) guys, As you might have noticed, I took some time last week to go on a JIRA fixing campaign on Apache Directory Studio. With the recent developments, I think we are nearing a possible release of a first milestone for version 2.0. Of course, it still needs some work but various reasons makes me think we should probably consider releasing the first milestone really soon: 1°/ It's been more than 20 months since the last release (April 5th, 2010). That's really a shame, but it's the reality… :( Such a long time without a release gives a very bad impression on users. Almost like if Studio was an abandoned project... 2°/ Milestone releases worked well on the API and ApacheDS. We've had some great results from milestone releases on these projects. Even if they are not stable and production-ready yet, they have helped us get back in touch with our users and forced us to focus on specific key-features for each iteration. 3°/ A hell lot of things have changed in Studio, with lots of improvements and bug fixes. I can't name everything but it includes things like: - the inclusion of the Apache Directory LDAP API as network provider (as a replacement for JNDI - which is still selectable) - the use of Shared's SchemaManager in the Schema Editor - the rewrite of the ApacheDS plugins into something more open, the LDAP Servers plugin - the new ApacheDS V2 Configuration Plugin which edits via LDAP and LDIF the configuration of an ApacheDS 2.0 server - the update of Eclipse dependencies and launchers to the latest and greatest versions - many bug fixes, improvements and feature requests This mail isn't to vote about the release yet. A few things really need to be polished first. But I'd like to get your thoughts about a possible release of a first milestone for version 2.0 in the next days/weeks. It will be a milestone, you don't have to be too cautious, IMO. Just go for it when you think it's ready. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: TxnManager should be moved to shared-ldap
On Tue, Dec 20, 2011 at 7:11 PM, Pierre-Arnaud Marcelot wrote: > Hi Alex, > > I just discussed this with Emmanuel, and like you, I think the transaction > does not belong in shared. > It's really meant to be placed between the piece of code which captures > LDAP requests on the server and the various partition back-end > implementations. > > Glad you both feel this way. > I haven't looked at the code closely, but I think a simple class extending > our cursor implementation in shared, with the close() method overridden, > should probably do the trick. > This would leave most of the cursor behavior implementation in shared > where we need "basic" cursor, while letting us do additional stuff on the > server side by overriding methods and calling super.methodName() to inherit > the default behavior. > > Sure this is yet another simpler way to do it. However it's done we can give it a try and see how well it holds. Best, Alex > Regards, > Pierre-Arnaud > > On 20 déc. 2011, at 18:01, Alex Karasulu wrote: > > I am saying this because clearly TxnManager does not belong in shared if > we just step back and think about it. Yes the mechanics of the code is > making us consider this but we should resist and see what we can do with > some pattern to decouple this. > > On Tue, Dec 20, 2011 at 7:00 PM, Alex Karasulu wrote: > >> >> On Tue, Dec 20, 2011 at 5:41 PM, Emmanuel Lecharny >> wrote: >> >>> Hi, >>> >>> if we want to make the search operation part of the transaction, then we >>> may need to move the Txnmanager to the shared-ldap library, as we don't see >>> this class from any cursor. >>> >>> >> I see what you mean. But there are ways in which we can decouple things >> without having to have TxnManager moved. This can be done by registering >> for Cursor close notification and there the transaction manager can be >> called within an Observer type object. >> >> First of all I was wondering if we can use the Java Transaction API here >> at all to prevent re-inventing these interfaces. Have not looked at the >> overlap. >> >> >>> The need is to be able to commit or rollback the txn when the >>> cursor.close() is done (or if we've got an exception). >>> >>> >> Again I think we can decouple this with notifications/callbacks. >> >> -- >> Best Regards, >> -- Alex >> >> > > > -- > Best Regards, > -- Alex > > > -- Best Regards, -- Alex
Re: [Studio] Setting the 'Apache Directory LDAP API' as the default network provider
On Tue, Dec 20, 2011 at 8:03 PM, Kiran Ayyagari wrote: > On Tue, Dec 20, 2011 at 11:13 PM, Pierre-Arnaud Marcelot > wrote: > > Hi guys, > > > > Today, I have introduced a change in the Connection Core plugin of > Apache Directory Studio to set the 'Apache Directory LDAP API' as the > default network provider, instead of JNDI. > > > > I think it's safe to say that the LDAP API is now a great alternative to > JNDI. > > It might still lack a few features here and there, like pulling a schema > manager from a connection or the lack a connection pool, but from Studio's > standpoint, each feature we used from JNDI has now an equivalent in the > LDAP API. > > > > I have added a new setting in the 'Connections' preferences page [1] > where the user can choose its preferred default network provider (either > 'Apache Directory LDAP API', the default value, or 'JNDI'). > > The user can still decide which network provider to use on a per > connection basis in the 'New Connection' Wizard page or the 'Connection' > Properties page [2]. > > > > I believe this move can give a lot of credit to the LDAP API and help us > promote it towards the general public. (It might also be helpful in the > beginning to help find hidden bugs I guess.) > > > > WDYT? > > Should we go in this direction or should we rollback to 'JNDI' as > default setting? > > > +1 to keep the client API as default provider > thanks Pierre-Arnaud > > Ditto. -- Best Regards, -- Alex
Re: [Studio] Releasing a first milestone for version 2.0 (2.0.0-M1) soon?
On Tue, Dec 20, 2011 at 9:32 PM, Emmanuel Lecharny wrote: > On 12/20/11 7:09 PM, Pierre-Arnaud Marcelot wrote: > >> Hi (again) guys, >> >> As you might have noticed, I took some time last week to go on a JIRA >> fixing campaign on Apache Directory Studio. >> >> With the recent developments, I think we are nearing a possible release >> of a first milestone for version 2.0. >> Of course, it still needs some work but various reasons makes me think we >> should probably consider releasing the first milestone really soon: >> >> 1°/ It's been more than 20 months since the last release (April 5th, >> 2010). >> That's really a shame, but it's the reality… :( >> Such a long time without a release gives a very bad impression on users. >> Almost like if Studio was an abandoned project... >> >> 2°/ Milestone releases worked well on the API and ApacheDS. >> We've had some great results from milestone releases on these projects. >> Even if they are not stable and production-ready yet, they have helped us >> get back in touch with our users and forced us to focus on specific >> key-features for each iteration. >> >> 3°/ A hell lot of things have changed in Studio, with lots of >> improvements and bug fixes. >> I can't name everything but it includes things like: >> - the inclusion of the Apache Directory LDAP API as network provider (as >> a replacement for JNDI - which is still selectable) >> - the use of Shared's SchemaManager in the Schema Editor >> - the rewrite of the ApacheDS plugins into something more open, the LDAP >> Servers plugin >> - the new ApacheDS V2 Configuration Plugin which edits via LDAP and LDIF >> the configuration of an ApacheDS 2.0 server >> - the update of Eclipse dependencies and launchers to the latest and >> greatest versions >> - many bug fixes, improvements and feature requests >> >> This mail isn't to vote about the release yet. A few things really need >> to be polished first. >> But I'd like to get your thoughts about a possible release of a first >> milestone for version 2.0 in the next days/weeks. >> > > It will be a milestone, you don't have to be too cautious, IMO. Just go > for it when you think it's ready. > > Agree w/ Emm here ... -- Best Regards, -- Alex
How do we handle recursive requests wrt transactions ?
Hi, I tried to get some tests passing where a recursive delete is done. The problem is that we do a search at each level, whch means we start a new transaction at each new level. I can easily check that a transaction has not been started yet (so that the txn is only started once), but as I try to commit the txn when the cursor is closed, I have a problem to close the right txn (ie, the one that has been started in the outer loop). Any idea on how to get it working ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: How do we handle recursive requests wrt transactions ?
Since you cannot use triggers right now, I am assuming you are trying to do the recursive delete thorugh ldap core connection? As I tried to explain in my previous emails, the first thing to decide is to where to put the transaction boundaries: * For Ldap requests over the wite, ldap protocol handlers insert the txn boundaries. * For ldap core connection, it seems you guys discussed and wanted to put txn boundary per request and want to close the txn when cursor is closed. when discussing with Emmanuel, I remember clearly that user should be aware that LDAP is not transactional and users should be aware of it. So if you are doing a recursive delete through ldap core connection and transaction boundaries are per request, then you should know that the whole thing is not a txn itself. That said, if you insert txn boundaries per request, then you need to deal with a couple of things: * Handle txn commit, abort for search. As mentioned in previous emails, this can be done in cursor close. *When a search cursor is open, another search cursor can be opened. *When a search cursor is open, a delete/add/modify request might be made. If txn boundary is per request, then you have two options to handle the above: * Introduce txn ref count and close the txn context when the ref count drops to zero. This is similar to nested txns concept and if a nested txn aborts, the final enclosing txn aborts. * When a cursor is open and a delete/add/modify is made, read only txn has to be upgraded to read write txn. When the final enclosing txn commits, it can get a conlfict exception and the whole request has to be repeated. So, although we try to hide the txns from the user, the above approach is clearly not intuitive for the user as final cursor close determines txn boundary and txn has to be retried after a conflict exception. We have two options: * Have a txn context per request. Store context with cursor, then when user switches into cursor, restore its context, when it is leaving cursor, remove txn context. This way you dont have to deal with txn ref count or txn upgrade. I did something like this with jdbm browsers so that implementation there was totally hidden from the upper layers. *In embedded case, leave it to the user to determine the txn boundaries. This way things like recursive delete thorugh ldap core connection would meaningfully work . Last and not least, since more than one person is involved in the code now, please let us know what you plan to do before you do any anything about code. Many of the points above were discussed here and there but I did not see a clear decision made about them, at least in the emails. regards Selcuk On Wed, Dec 21, 2011 at 2:33 AM, Emmanuel Lecharny wrote: > Hi, > > I tried to get some tests passing where a recursive delete is done. The > problem is that we do a search at each level, whch means we start a new > transaction at each new level. > > I can easily check that a transaction has not been started yet (so that the > txn is only started once), but as I try to commit the txn when the cursor is > closed, I have a problem to close the right txn (ie, the one that has been > started in the outer loop). > > Any idea on how to get it working ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
