Nabble - Apache Directory Project

Re: [VOTE] Release of Apache Directory Studio 1.5.1

2009-11-24T01:22:31Z

> [ X ] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)

Kiran Ayyagari

Re: [VOTE] Release of Apache Directory Studio 1.5.1

2009-11-24T00:59:24Z

[X] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)

On Tue, Nov 24, 2009 at 10:22, Pierre-Arnaud Marcelot <pa@...> wrote:

Hi all,

We'd like to propose a vote for the release of Apache Directory Studio version 1.5.1.

Version 1.5 shipped less than a month ago with lots of new features and improvements. Unfortunately, a few bugs (particularly a critical one) have gotten into the release too.

We've addressed 14 Jiras since the release of 1.5 mainly related to:
- a nasty bug where a modify operation could be sent to the server when refreshing the LDAP Browser view
- correctly handling entries with a hash sign (#) in their DN
- glitches and performance improvements in the UI
- typos in the french translation

Here are the complete release notes from JIRA:
* Bug
- [DIRSTUDIO-576] - Context menu not shown after a right-click on a non-cached entry
- [DIRSTUDIO-577] - LDIF editor doesn't notify Eclipse that the LDIF file has changed when saving
- [DIRSTUDIO-580] - Setting "Validate certificates for secure LDAP connections" is not saved
- [DIRSTUDIO-587] - UI flickers on quick search
- [DIRSTUDIO-589] - InvalidNameException: unexpected token for user ids starting with hash sign
- [DIRSTUDIO-590] - The 'Quick Search' string has not been externalized in the LDAP Browser view
- [DIRSTUDIO-591] - Error reading objects with # in DN
- [DIRSTUDIO-592] - LDAP Browser view is refreshed twice after the initialization of the children of an entry
- [DIRSTUDIO-593] - Missing string and typo in the french translation of the Password Editor
- [DIRSTUDIO-594] - The 'Show new password details' checkbox does not display the 'Enter new password' text field as clear text when checked in the Password Editor
- [DIRSTUDIO-596] - Various typos in the french translation
- [DIRSTUDIO-597] - Modification sent to the server while browsing through the DIT and refreshing entries
- [DIRSTUDIO-598] - Base64 encoded DN marked as invalid in LDIF editor

* Improvement
- [DIRSTUDIO-595] - The icon of the entry in the 'Outline' view should be the same as the one in the 'LDAP Browser' view

Let's vote now:
[ ] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)
[ ] +/-0 | Abstain
[ ] -1 | Do *NOT* release Apache Directory Studio 1.5.1 (and Shared 0.9.16)

IMPORTANT NOTE: The release of Studio *DOES* implicates the release of Shared version 0.9.16 as it bring fixes for correctly parsing DNs containing a hash sign (#).

Thanks,
Pierre-Arnaud Marcelot

--
Ersin Er
The Apache Directory Project
Committer, PMC

Re: [VOTE] Release of Apache Directory Studio 1.5.1

2009-11-24T00:38:09Z

As usual, distributions will be available for testing.

I'm going to generate and upload them here:
http://people.apache.org/~pamarcelot/ApacheDirectoryStudio_1.5.1-SNAPSHOT/

Regards,
P-A

On 24 nov. 2009, at 09:22, Pierre-Arnaud Marcelot wrote:

Hi all,

We'd like to propose a vote for the release of Apache Directory Studio version 1.5.1.

Version 1.5 shipped less than a month ago with lots of new features and improvements. Unfortunately, a few bugs (particularly a critical one) have gotten into the release too.

We've addressed 14 Jiras since the release of 1.5 mainly related to:
- a nasty bug where a modify operation could be sent to the server when refreshing the LDAP Browser view
- correctly handling entries with a hash sign (#) in their DN
- glitches and performance improvements in the UI
- typos in the french translation

Here are the complete release notes from JIRA:
* Bug
- [DIRSTUDIO-576] - Context menu not shown after a right-click on a non-cached entry
- [DIRSTUDIO-577] - LDIF editor doesn't notify Eclipse that the LDIF file has changed when saving
- [DIRSTUDIO-580] - Setting "Validate certificates for secure LDAP connections" is not saved
- [DIRSTUDIO-587] - UI flickers on quick search
- [DIRSTUDIO-589] - InvalidNameException: unexpected token for user ids starting with hash sign
- [DIRSTUDIO-590] - The 'Quick Search' string has not been externalized in the LDAP Browser view
- [DIRSTUDIO-591] - Error reading objects with # in DN
- [DIRSTUDIO-592] - LDAP Browser view is refreshed twice after the initialization of the children of an entry
- [DIRSTUDIO-593] - Missing string and typo in the french translation of the Password Editor
- [DIRSTUDIO-594] - The 'Show new password details' checkbox does not display the 'Enter new password' text field as clear text when checked in the Password Editor
- [DIRSTUDIO-596] - Various typos in the french translation
- [DIRSTUDIO-597] - Modification sent to the server while browsing through the DIT and refreshing entries
- [DIRSTUDIO-598] - Base64 encoded DN marked as invalid in LDIF editor

* Improvement
- [DIRSTUDIO-595] - The icon of the entry in the 'Outline' view should be the same as the one in the 'LDAP Browser' view

Let's vote now:
[ ] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)
[ ] +/-0 | Abstain
[ ] -1 | Do *NOT* release Apache Directory Studio 1.5.1 (and Shared 0.9.16)

IMPORTANT NOTE: The release of Studio *DOES* implicates the release of Shared version 0.9.16 as it bring fixes for correctly parsing DNs containing a hash sign (#).

Thanks,
Pierre-Arnaud Marcelot

Re: [VOTE] Release of Apache Directory Studio 1.5.1

2009-11-24T00:26:43Z

Pierre-Arnaud Marcelot wrote:
> [X] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)
>
>
Go for it !

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[VOTE] Release of Apache Directory Studio 1.5.1

2009-11-24T00:22:16Z

Hi all,

We'd like to propose a vote for the release of Apache Directory Studio version 1.5.1.

Version 1.5 shipped less than a month ago with lots of new features and improvements. Unfortunately, a few bugs (particularly a critical one) have gotten into the release too.

We've addressed 14 Jiras since the release of 1.5 mainly related to:
- a nasty bug where a modify operation could be sent to the server when refreshing the LDAP Browser view
- correctly handling entries with a hash sign (#) in their DN
- glitches and performance improvements in the UI
- typos in the french translation

Here are the complete release notes from JIRA:
* Bug
- [DIRSTUDIO-576] - Context menu not shown after a right-click on a non-cached entry
- [DIRSTUDIO-577] - LDIF editor doesn't notify Eclipse that the LDIF file has changed when saving
- [DIRSTUDIO-580] - Setting "Validate certificates for secure LDAP connections" is not saved
- [DIRSTUDIO-587] - UI flickers on quick search
- [DIRSTUDIO-589] - InvalidNameException: unexpected token for user ids starting with hash sign
- [DIRSTUDIO-590] - The 'Quick Search' string has not been externalized in the LDAP Browser view
- [DIRSTUDIO-591] - Error reading objects with # in DN
- [DIRSTUDIO-592] - LDAP Browser view is refreshed twice after the initialization of the children of an entry
- [DIRSTUDIO-593] - Missing string and typo in the french translation of the Password Editor
- [DIRSTUDIO-594] - The 'Show new password details' checkbox does not display the 'Enter new password' text field as clear text when checked in the Password Editor
- [DIRSTUDIO-596] - Various typos in the french translation
- [DIRSTUDIO-597] - Modification sent to the server while browsing through the DIT and refreshing entries
- [DIRSTUDIO-598] - Base64 encoded DN marked as invalid in LDIF editor

* Improvement
- [DIRSTUDIO-595] - The icon of the entry in the 'Outline' view should be the same as the one in the 'LDAP Browser' view

Let's vote now:
[ ] +1 | Release Apache Directory Studio 1.5.1 (and Shared 0.9.16)
[ ] +/-0 | Abstain
[ ] -1 | Do *NOT* release Apache Directory Studio 1.5.1 (and Shared 0.9.16)

IMPORTANT NOTE: The release of Studio *DOES* implicates the release of Shared version 0.9.16 as it bring fixes for correctly parsing DNs containing a hash sign (#).

Thanks,
Pierre-Arnaud Marcelot

Re: [Studio] Development for 1.5.1

2009-11-23T23:50:39Z

Hi Stefan,

That's a very great news... :)

Let's launch the vote!
Shall I do it ?

Regards,
Pierre-Arnaud

On 24 nov. 2009, at 00:05, Stefan Seelmann wrote:

> Pierre-Arnaud Marcelot wrote:
>> 6 issues have been fixed since my last mail and I know Stefan is in its way to resolve the two last ones (tests just need to be added for non-regression).
>> Should we consider launching a vote for releasing 1.5.1 quickly?
>
> If I count correctly we now have 14 fixed issues (+2 issues in shared). There was a very serious one [1]: A modify operation was sent to the server when doing wild refreshs in the browser.
>
> So I suggest to launch a vote for 1.5.1, this time including a shared release.
>
> Kind Regards,
> Stefan
>
> [1]https://issues.apache.org/jira/browse/DIRSTUDIO-597
>

Re: [Schema Refactoring] Serious side effect...

2009-11-23T15:57:10Z

Howard Chu wrote:

> Emmanuel Lecharny wrote:
>> <snip/>
>> Any other operation (delete, modify, rename, disabling a schema) are
>> most certainly leading to dire errors, something an administrator
>> will not want to experiment in production. IMO, they should be
>> forbidden on a working base. Such operation is like manipulating a
>> loaded weapon with no safety...
>
> This is pretty much the same conclusion we reached, which is why in
> OpenLDAP 2.3 we only supported dynamic adding of schema. In 2.4 we
> support delete/modify but it's a hack - the deleted elements are kept
> around. If you do a Modify to alter an existing value (e.g.
> Modify/delete foo=1/add foo=2) we make sure the subsequent add applies
> to the corresponding deleted element. Since we don't refcount
> AttributeDescriptions, these things are kept around for the life of
> the server process, and only get purged on a restart.

Funny enough, this was what I got in ADS, until the point I decided that
I should clean the old schema, to avoid memory leaks. Too bad !!! All
the objects pointing to the deleted schema were doomed ! That led to
this thread...

>
>> For the reason I mentionned, I don't think that any alternative is ok.
>> We probably don't have a perfect solution because there are none. As we
>> say : "any problem vanishes when there is no solution"...
>>
>> More seriously, I don't think we need a dynamic schemaManager for a LDAP
>> server in production : admins don't change such a critical thing in
>> production, except those who are insane or desesperate. We must accept
>> the idea that we might have a downtime, we just have to minimize it.
>
> That was my generally my perspective as well. IMO, admins should be
> able to dynamically Add tested schema to a production server. If
> they're experimenting and need to alter the schema on-the-fly, they
> should be testing in a dedicated test environment. This was the
> rationale behind the 2.3 implementation.

Make totally sense to me. But ...
>
> But it seems that admins like to whine a lot about things they think
> they need, even if they're more likely to shoot themselves in the
> foot. So we added dynamic delete/modify support in 2.4.
There is also a special use case we are aware of : people using an
embedded server want to keep it running, forever. This is a reason why
they might want dynamic schema modifications.

Anyway, the desire to change a schema in production, embedded or not, is
probably sick. The larger the base, the sicker this request is : it's a
bit like trying to fix your engine while driving on the highway at 60
mph...

The few users I know who have huge database (from 100 000 entries to 70
00 000 entries) don't change the schema *at all*. The service don't go
in production if the schema is wrong, anyway. It's like changing a
database schema in production...

Let's be realistic : it can happen, but people have to pay the price for
their under tested system. Considering that a LDAP server is mainly used
for searches, the downtime to export the data, massage them accordingly
to the new schema, inject them in another server, index everyting,
launch the new server, stop the old one, inject the data updated between
the moment the extract has been done and the moment the old server has
been stopped, is probably very limited.
My own experience (with an OpenLDAP server - 2.4.16, and 5 millions
entries) demonstrate that the downtime is around 5 minutes if we stop
all the server before exporting the data and reimport them. Probably
acceptable, if you are not managing the Kennedy Airport with this system
! Even if it's a one hour downtime, twice a year, this is a 99.98% uptime.

FYI, Amazon EC2 SLA is 99.95% uptime, a 4.38 hours/year downtime. Here,
what is important is not the downtime, but the failover solution, and
more important, the fact that you *select* the downtime period. Sundays
are not only a day off : they are a perfect day for maintenance operations !
>
> Either way, 2.3 or 2.4, it's possible to end up with entries in the DB
> using schema that no longer exist - we don't search them out and
> remove them when deleting schema elements. (Indeed, you really
> shouldn't; someone may be adding a new version of the deleted schema
> in the next operation. You have no way to know when a delete is really
> final, and spontaneously deleting user data is always a mistake...)
Make sense. Again, Admin must *know* what they are doing. Aren't they ?
... Hopefully, we provide expensive consulting to those guys ;)

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Schema Refactoring] Serious side effect...

2009-11-23T15:31:43Z

Emmanuel Lecharny wrote:

> We discussed this point with Alex extensively lately. This Observer/Listener pattern sounds good, but IMO, it does not solve the problem.
> 1) We have to deal with all the serverEntries being currently processed, and maybe being modified. A ServerEntry is not an atomic object, and we don't want to deal with the extra complexity of a event occuring while we are in the middle of a modification of this ServerEntry
> 2) Many ServerEntries might be stuck in memory, waiting for a thread to be free. This is the case for every partial ServerEntry waiting for some more bytes from the client.
> 3) We have many places where we store cached ServerEntries. The question is how do we update them ?
> 4) What do we do with the Original entry, which is stored into each OpContext, as we may need it later ? Do we update it too ? IMO, that would defeat the purpose of this object
> 5) ServerEntries are serialized in the Backend, and if we modify the schema, it will most certainly impact them. If they are not migrated, they might not be usable anymore after the schema modification. Also if we have millions of entries, changing them online is probably not realistic. Anyway, the admin has to deal with this problem in any case
>
> I don't see how possibly we can deal with a schema modification live, except for a few modifications :
> - AT, OC, S, MR, C, N and SC, and only for Add or Move operations
> - schema enabling
>
> Any other operation (delete, modify, rename, disabling a schema) are most certainly leading to dire errors, something an administrator will not want to experiment in production. IMO, they should be forbidden on a working base. Such operation is like manipulating a loaded weapon with no safety...

This is pretty much the same conclusion we reached, which is why in OpenLDAP
2.3 we only supported dynamic adding of schema. In 2.4 we support
delete/modify but it's a hack - the deleted elements are kept around. If you
do a Modify to alter an existing value (e.g. Modify/delete foo=1/add foo=2) we
make sure the subsequent add applies to the corresponding deleted element.
Since we don't refcount AttributeDescriptions, these things are kept around
for the life of the server process, and only get purged on a restart.

> For the reason I mentionned, I don't think that any alternative is ok.
> We probably don't have a perfect solution because there are none. As we
> say : "any problem vanishes when there is no solution"...
>
> More seriously, I don't think we need a dynamic schemaManager for a LDAP
> server in production : admins don't change such a critical thing in
> production, except those who are insane or desesperate. We must accept
> the idea that we might have a downtime, we just have to minimize it.

That was my generally my perspective as well. IMO, admins should be able to
dynamically Add tested schema to a production server. If they're experimenting
and need to alter the schema on-the-fly, they should be testing in a dedicated
test environment. This was the rationale behind the 2.3 implementation.

But it seems that admins like to whine a lot about things they think they
need, even if they're more likely to shoot themselves in the foot. So we added
dynamic delete/modify support in 2.4.

Either way, 2.3 or 2.4, it's possible to end up with entries in the DB using
schema that no longer exist - we don't search them out and remove them when
deleting schema elements. (Indeed, you really shouldn't; someone may be adding
a new version of the deleted schema in the next operation. You have no way to
know when a delete is really final, and spontaneously deleting user data is
always a mistake...)

> Unless someone has a genious idea !
>> Regards,
>>
>>
>
>

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/

Re: [ApacheDS] [Schema] Update mechanism

2009-11-23T15:30:22Z

Alex Karasulu wrote:
> Thinking more about how to update the schema and the mechanics involved
> along with the various trade offs. Here's how this should progress:
>
> Schema Change Steps
>
> (1) A schema change operation arrives and changes are performed on a cloned
> set of registries where the impact of the change is calculated in terms of
> the total number of indirect dependents affected.
>
As of today, the clone is mainly used to check that the registries
remain consistent after the changes. Calculating all the impacted
elements is a bit complex...

> (2a) If the operation is consistent then a schema-txn-begin message is sent
> to all listeners informing them of the OIDs impacted by the schema change
> calculated in the first step. This lets objects dependent on these schema
> entities to respond to the situation. This message is delivered
> synchronously. Access to the old Registries is provided before the swap in
> case the object needs them via the SchemaManager handle if they are exposed.
> (2b) If the operation leaves the schema in an inconsistent state then no
> message is sent to schema listeners and the schema change is rejected.
> (3) The schema registries are swapped out.
> (4) The SchemaManager then sends a schema-txn-commit message to all
> listeners to now be able to access the modified schema elements they're
> interested in from the newly swapped in registries. This message is
> delivered synchronously.
>
>
> Schema Change Responses
>
> (1) Invalidate the object in question so all using/run processes and caches
> can reset or update themselves via the acquisition of a new valid object to
> continue the process.
> (2) Make the object depending on schema objects valid by updating stale
> references and hope for the best. Sometimes timing will cause certain
> failures but this is really OK with us since this is a rare situation to
> update the schema.
>

If the object has already been checked by the SchemaInterceptor, and if
the schema modification makes this object to be inconsistent, we won't
be able to fix that, as the chek has already be applied.
>
> SchemaListener Interface Methods
>
> schemaChangeBegin( SchemaManager sm, List<String> oids );
> schemaChangeCommit( SchemaManager sm, List<String> oids );
>
> Pulled these out of my arse so please elaborate.
>
My guts say that it's far too complex to implement right now. My kidneys
feel that it might even don't work correctly : too many corner cases...

IMHO, we shoudl try to get the server back on rail, even without all
those dynamic schema modifications, except for the additions operation
and for the schema enabling operation.

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Schema Refactoring] Serious side effect...

2009-11-23T15:19:44Z

More inline...

Alex Karasulu wrote:

> Hi Emmanuel,
>
> On Mon, Nov 23, 2009 at 3:31 AM, Emmanuel Lecharny <elecharny@...>wrote:
>
>
>> Hi,
>>
>> when we modify the schema, for instance by adding a new AT, in order not to
>> break the current schema, we apply the modification to a cloned Registries.
>> So far, so good. And if the new registries is ok with the newly added
>> SchemaObject, we swap the registries.
>>
>> Now, this create a dull issue : all the ServerEntry instances still point
>> to the previous registries, and as we clean the previous registries to avoid
>> memory leaks, all those instances now point to non existing SchemaObjects
>> (more specifically, each instance has attributes which contain a reference
>> to the AttributeType schemaObject they are associated with) !
>>
>>
>>
> We cannot hold references to AttributeType or other schema objects anymore.
> Instead we need to perform a lookup everytime to get these schema objects
> from the registries via the schema manager. This way when the swap occurs
> the new objects are extracted every time. No member references should be
> made to schema objects any longer.
>
> Question : how can we avoid this problem ?
>
>
> See above.
>

We discussed about this point this afternoon with Pierre Arnaud, but I
didn't decide anything before having updated the wiki with a page
describing the current data structure and all the interactions between
objects. The page is
http://directory.apache.org/apacheds/1.5/apache-ds-schemamanager.html

The big problem with this approach (which was what was implemented
before) is that each lookup is costly, and we do a lot of them while
processing a request.

Having the AT stored into the AttributeEntry solve this problem, as we
have a direct access to the data : we just do a single lookup at the
beginning.

>
>
>> My idea is to apply the modification to the initial registries once it has
>> been proven that the registries alteration leave the Regsitries consistent.
>> We will just clean the cloned registries, and don't swap anymore.
>>
>>
>>
>
> I think this is not a good idea. The swap is a clean approach that does the
> job just fine. Otherwise if there are sticking points in the registries we
> will have problems. This is too much to do to solve this issue. Instead we
> need dynamic look ups of all the schema objects or we need a update pattern
> to inform of schema changes to swap out these objects.
>
> I am thinking of the Observer or Listener notification patterns here.
> Otherwise we will have to use dynamic lookups every time which can cost us a
> lot.
>

We discussed this point with Alex extensively lately. This Observer/Listener pattern sounds good, but IMO, it does not solve the problem.
1) We have to deal with all the serverEntries being currently processed, and maybe being modified. A ServerEntry is not an atomic object, and we don't want to deal with the extra complexity of a event occuring while we are in the middle of a modification of this ServerEntry
2) Many ServerEntries might be stuck in memory, waiting for a thread to be free. This is the case for every partial ServerEntry waiting for some more bytes from the client.
3) We have many places where we store cached ServerEntries. The question is how do we update them ?
4) What do we do with the Original entry, which is stored into each OpContext, as we may need it later ? Do we update it too ? IMO, that would defeat the purpose of this object
5) ServerEntries are serialized in the Backend, and if we modify the schema, it will most certainly impact them. If they are not migrated, they might not be usable anymore after the schema modification. Also if we have millions of entries, changing them online is probably not realistic. Anyway, the admin has to deal with this problem in any case

I don't see how possibly we can deal with a schema modification live, except for a few modifications :
- AT, OC, S, MR, C, N and SC, and only for Add or Move operations
- schema enabling

Any other operation (delete, modify, rename, disabling a schema) are most certainly leading to dire errors, something an administrator will not want to experiment in production. IMO, they should be forbidden on a working base. Such operation is like manipulating a loaded weapon with no safety...

>
>
>> Does it sound good to you, or do you have any better idea ?
>>
>>
>>
> No I think we either go with expensive dynamic lookups all over the place or
> we utilize a update notification mechanism via the Observer or Listener
> patterns.
>
> Does this sound like a viable alternative?
>

For the reason I mentionned, I don't think that any alternative is ok.
We probably don't have a perfect solution because there are none. As we
say : "any problem vanishes when there is no solution"...

More seriously, I don't think we need a dynamic schemaManager for a LDAP
server in production : admins don't change such a critical thing in
production, except those who are insane or desesperate. We must accept
the idea that we might have a downtime, we just have to minimize it.

Unless someone has a genious idea !
> Regards,
>
>

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Studio] Development for 1.5.1

2009-11-23T15:05:07Z

Pierre-Arnaud Marcelot wrote:
> 6 issues have been fixed since my last mail and I know Stefan is in its way to resolve the two last ones (tests just need to be added for non-regression).
>
> Should we consider launching a vote for releasing 1.5.1 quickly?

If I count correctly we now have 14 fixed issues (+2 issues in shared).
There was a very serious one [1]: A modify operation was sent to the
server when doing wild refreshs in the browser.

So I suggest to launch a vote for 1.5.1, this time including a shared
release.

Kind Regards,
Stefan

[1]https://issues.apache.org/jira/browse/DIRSTUDIO-597

[jira] Closed: (DIRSTUDIO-597) Modification sent to the server while browsing through the DIT and refreshing entries

2009-11-23T14:56:39Z

[ https://issues.apache.org/jira/browse/DIRSTUDIO-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Seelmann closed DIRSTUDIO-597.
-------------------------------------

Resolution: Fixed
Assignee: Stefan Seelmann

Fixed:
http://svn.apache.org/viewvc?rev=882581&view=rev
http://svn.apache.org/viewvc?rev=882586&view=rev

> Modification sent to the server while browsing through the DIT and refreshing entries
> -------------------------------------------------------------------------------------
>
> Key: DIRSTUDIO-597
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-597
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.0
> Reporter: Stefan Seelmann
> Assignee: Stefan Seelmann
> Priority: Blocker
> Fix For: 1.5.1
>
>
> I walk throught the DIT using mouse and/or arrow keys and refresh entries from time to time. Suddenly an error dialog pops up, an modification request was sent to the server!
> #!RESULT ERROR
> #!CONNECTION ldap://localhost:10389
> #!DATE 2009-11-19T21:09:51.497
> #!ERROR [LDAP: error code 65 - OBJECT_CLASS_VIOLATION: failed for Modify Request Object : '0.9.2342.19200300.100.1.25=example,0.9.2342.19200300.100.1.25=com' Modification[0] Operation : delete Modification objectClass: (null) : null]
> dn: dc=example,dc=com
> changetype: modify
> delete: objectClass
> -

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRSHARED-40) DN parser, LdapDN, Rdn, Atav issues

2009-11-23T14:23:39Z

DN parser, LdapDN, Rdn, Atav issues
-----------------------------------

Key: DIRSHARED-40
URL: https://issues.apache.org/jira/browse/DIRSHARED-40
Project: Directory Shared
Issue Type: Bug
Affects Versions: 0.9.15
Reporter: Stefan Seelmann

In the last days I tried to fix DIRSHARED-39 and investigated some issues in the DN/Rdn/ATAV implementation. I just want to write them down, I think it makes sense to fix them after the schema branch is finished.

Class AttributeTypeAndValue:
- the first three constructors are not used by productive code, only by unit tests
- setType, setTypeNormalized, setValueNormalized are never used
- getNormalizedValue returns a name (<type>=<value>) instead of a value
- the meaning of upValue and normValue is not clear to me and is not consistent, see below
- upValue and normValue are of type Value<?>, however they contain escaped string values. IMO they should contain the real unescaped values because the escapes are only necessary for the DN string representation. For this case we have another field upName that contains <type>=<escaped value>

Class Rdn:
- three methods getValue, getUpValue, getNormValue; what does getValue() mean?
- getNormValue() for MV-RDN returns the calls ATAV.getNormalizedValue() which returns a name
- the meaning of upValue and normValue is not clear to me and not consistent, see below
- getUpValue and getNormValue always return strings, what if RDN value is binary?

Class RdnParser:
- this is still a hand-written parser. The hand-written code should be removed and the FastDnParser and ComplexDnParser should be used (like LdapDnParser)

General:
- getNormValue and getUpValue should return the Value<?> object instead of a String or byte[]
- getUpValue returns the escaped value, thus in the server and studio code we need to call Rdn.unescapeValue() to get the unescaped value
- the normalizing is quite complex, I was not able to understand how it works.

Example: for the DN "ou=A\ " (trailing escaped whitespace) we have the following issues:
After calling
LdapDN dn = new LdapDN("ou=A\\ ");
we have the following result:
upValue is escaped: "A\ "
nornValue is unescaped: "A "
upName and normName are escaped: "ou=A\ "

After calling
dn.normalize( oidOids );
we have the following result:
upValue is still escaped: "A\ "
normValue is "a" -> the space is gone!!!
upName is "ou=A\ "
normName is "2.5.4.11=a" -> the space is gone!!!

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[ApacheDS] [Schema] Update mechanism

2009-11-23T13:20:42Z

Thinking more about how to update the schema and the mechanics involved along with the various trade offs. Here's how this should progress:

Schema Change Steps

(1) A schema change operation arrives and changes are performed on a cloned set of registries where the impact of the change is calculated in terms of the total number of indirect dependents affected.
(2a) If the operation is consistent then a schema-txn-begin message is sent to all listeners informing them of the OIDs impacted by the schema change calculated in the first step. This lets objects dependent on these schema entities to respond to the situation. This message is delivered synchronously. Access to the old Registries is provided before the swap in case the object needs them via the SchemaManager handle if they are exposed.
(2b) If the operation leaves the schema in an inconsistent state then no message is sent to schema listeners and the schema change is rejected.
(3) The schema registries are swapped out.
(4) The SchemaManager then sends a schema-txn-commit message to all listeners to now be able to access the modified schema elements they're interested in from the newly swapped in registries. This message is delivered synchronously.

Schema Change Responses

(1) Invalidate the object in question so all using/run processes and caches can reset or update themselves via the acquisition of a new valid object to continue the process.
(2) Make the object depending on schema objects valid by updating stale references and hope for the best. Sometimes timing will cause certain failures but this is really OK with us since this is a rare situation to update the schema.

SchemaListener Interface Methods

schemaChangeBegin( SchemaManager sm, List<String> oids );
schemaChangeCommit( SchemaManager sm, List<String> oids );

Pulled these out of my arse so please elaborate.

Regards,
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

[jira] Closed: (DIRSHARED-39) Trailing escaped space not parsed correctly by the DN parser

2009-11-23T13:15:39Z

[ https://issues.apache.org/jira/browse/DIRSHARED-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Seelmann closed DIRSHARED-39.
------------------------------------

Resolution: Fixed

Fixed in trunk and branches/schema
http://svn.apache.org/viewvc?rev=883499&view=rev
http://svn.apache.org/viewvc?rev=883500&view=rev

> Trailing escaped space not parsed correctly by the DN parser
> ------------------------------------------------------------
>
> Key: DIRSHARED-39
> URL: https://issues.apache.org/jira/browse/DIRSHARED-39
> Project: Directory Shared
> Issue Type: Bug
> Affects Versions: 0.9.15
> Reporter: Stefan Seelmann
> Assignee: Stefan Seelmann
> Fix For: 0.9.16
>
>
> A trailing escaped space is not parsed correctly by te DN parser. Example: "cn=x\ "

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRSHARED-39) Trailing escaped space not parsed correctly by the DN parser

2009-11-23T11:41:39Z

Trailing escaped space not parsed correctly by the DN parser
------------------------------------------------------------

Key: DIRSHARED-39
URL: https://issues.apache.org/jira/browse/DIRSHARED-39
Project: Directory Shared
Issue Type: Bug
Affects Versions: 0.9.15
Reporter: Stefan Seelmann
Assignee: Stefan Seelmann
Fix For: 0.9.16

A trailing escaped space is not parsed correctly by te DN parser. Example: "cn=x\ "

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Schema Refactoring] Serious side effect...

2009-11-23T11:05:49Z

Hi Emmanuel,

On Mon, Nov 23, 2009 at 3:31 AM, Emmanuel Lecharny <elecharny@...> wrote:

Hi,

when we modify the schema, for instance by adding a new AT, in order not to break the current schema, we apply the modification to a cloned Registries. So far, so good. And if the new registries is ok with the newly added SchemaObject, we swap the registries.

Now, this create a dull issue : all the ServerEntry instances still point to the previous registries, and as we clean the previous registries to avoid memory leaks, all those instances now point to non existing SchemaObjects (more specifically, each instance has attributes which contain a reference to the AttributeType schemaObject they are associated with) !

We cannot hold references to AttributeType or other schema objects anymore. Instead we need to perform a lookup everytime to get these schema objects from the registries via the schema manager. This way when the swap occurs the new objects are extracted every time. No member references should be made to schema objects any longer.

Question : how can we avoid this problem ?

See above.

My idea is to apply the modification to the initial registries once it has been proven that the registries alteration leave the Regsitries consistent. We will just clean the cloned registries, and don't swap anymore.

I think this is not a good idea. The swap is a clean approach that does the job just fine. Otherwise if there are sticking points in the registries we will have problems. This is too much to do to solve this issue. Instead we need dynamic look ups of all the schema objects or we need a update pattern to inform of schema changes to swap out these objects.

I am thinking of the Observer or Listener notification patterns here. Otherwise we will have to use dynamic lookups every time which can cost us a lot.

Does it sound good to you, or do you have any better idea ?

No I think we either go with expensive dynamic lookups all over the place or we utilize a update notification mechanism via the Observer or Listener patterns.

Does this sound like a viable alternative?

Regards,

--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org

Re: [ApacheDS] Writing a custom partition

2009-11-23T09:59:54Z

Thomas Sahlin wrote:
> Given your advice, I removed my wrapper.java.classpath.6 modification
> and instead moved my partition JAR into lib/ext and voilà - it works
> like a charm :-D
>
> Not sure why the wrapper.java.classpath did not work but at least I can
> begin coding my partition now :-)

This is great news. Please note that I have started another example some
time ago. Unfortunately, it is not finished, but at least it does some
more and contains some data.

http://svn.apache.org/repos/asf/directory/sandbox/szoerner/syspropPartition

Basic idea is to present the system properties as a (read only)
partition. Hopefully it helps you with your own implementation.

Greetings from Hamburg,
StefanZ

Re: [ApacheDS] Writing a custom partition

2009-11-23T08:11:42Z

Stefan wrote:
> It is sufficient to copy the resulting jar file in the lib/ext directory
> of ApacheDS -- no modification of the classpath needed. Simply adjust

Given your advice, I removed my wrapper.java.classpath.6 modification and
instead moved my partition JAR into lib/ext and voilà - it works like a
charm :-D

Not sure why the wrapper.java.classpath did not work but at least I can
begin coding my partition now :-)

Thanks!

Thomas

Re: [ApacheDS] Writing a custom partition

2009-11-23T07:56:44Z

Thomas Sahlin wrote:
> Ok, thanks!
>
> I did compile my partition against the 1.5.5-JARs, but perhaps the API
> changes you mention cause problems at run time.

Strange. I have revisited the example and modified it to work with the
1.5.5 server. The WIKI page will take some time to get published on WWW,
but the main differences are in the source code anyway. Check them here:

http://svn.apache.org/viewvc?revision=883370&view=revision

The example, as committed here

http://svn.apache.org/repos/asf/directory/sandbox/szoerner/helloWorldPartition

compiles well in my environment and runs within a standard 1.5.5 download.

It is sufficient to copy the resulting jar file in the lib/ext directory
of ApacheDS -- no modification of the classpath needed. Simply adjust
your server.xml to use the partition, or use it embedded as demonstrated
here

http://svn.apache.org/repos/asf/directory/sandbox/szoerner/helloWorldPartition/src/main/java/org/apache/directory/samples/partition/hello/Main.java

Feel free to ask, if it still does not work as expected.
Greetings from Hamburg,
StefanZ

Re: [ApacheDS] Writing a custom partition

2009-11-23T07:27:49Z

> Stefan Zoerner wrote:
> The pom.xml of the example uses 1.5.4, and the artifact runs well with
> ApacheDS 1.5.4.
>
> But I can reproduce your problem with a current 1.5.5. The example jar, if
> used with this version simply does not work due to changes in the API.
>
> I will update the example to work with the 1.5.5 in the evening. Stay
> tunes ...

Ok, thanks!

I did compile my partition against the 1.5.5-JARs, but perhaps the API
changes you mention cause problems at run time.

Best regards,

Thomas

Re: [ApacheDS] Writing a custom partition

2009-11-23T06:44:41Z

Stefan Zoerner wrote:

> Hi Thomas!
>
> Thomas Sahlin wrote:
>> I'm trying out the example on how to write a simple custom partition
>> (it's at
>> http://directory.apache.org/apacheds/1.5/61-how-to-write-a-simple-custom-partition-for-apacheds.html).
>>
>>
>> What am I doing wrong?
>
> I am going to check. I'll be back later ...

The pom.xml of the example uses 1.5.4, and the artifact runs well with
ApacheDS 1.5.4.

But I can reproduce your problem with a current 1.5.5. The example jar,
if used with this version simply does not work due to changes in the API.

I will update the example to work with the 1.5.5 in the evening. Stay
tunes ...

Greetings from Hamburg,
StefanZ

Re: [ApacheDS] Writing a custom partition

2009-11-23T06:30:25Z

Hi Thomas!

Thomas Sahlin wrote:
> I'm trying out the example on how to write a simple custom partition
> (it's at
> http://directory.apache.org/apacheds/1.5/61-how-to-write-a-simple-custom-partition-for-apacheds.html).
>
>
> What am I doing wrong?

I am going to check. I'll be back later ...
Greetings from Hamburg,
Stefan

[ApacheDS] Writing a custom partition

2009-11-23T05:41:27Z

Hi everyone,

I'm trying out the example on how to write a simple custom partition (it's
at
http://directory.apache.org/apacheds/1.5/61-how-to-write-a-simple-custom-partition-for-apacheds.html).

I've created a class called TestPartition (pretty much identical to the
example HelloWorldPartition) and built it into a jar called LDAPTest.jar.

In /var/lib/apacheds-1.5.5/default/conf/server.xml I've added the following:

...
</jdbmPartition>

<s:bean id="testPartition" class="se.invented.apacheds.TestPartition">
<s:property name="suffix" value="ou=hello" />
</s:bean>
</partitions>

I've placed LDAPTest.jar inside /opt/apacheds-1.5.5/lib and added the
following to /opt/apacheds-1.5.5/conf/apacheds.conf:

wrapper.java.classpath.6=../lib/LDAPTest.jar

When I start the server it runs for a second and then dies with the attached
log message.

What am I doing wrong?

Thanks,

Thomas Sahlin

apacheds-rolling.log (7K) Download Attachment

Re: [Schema Refactoring] Serious side effect...

2009-11-23T02:36:43Z

the approach of 'no-swapping' sounds good to me

thanks for all the great work I now understand what a pain this schema refactoring is

Kiran Ayyagari

Emmanuel Lecharny wrote:

> Hi,
>
> when we modify the schema, for instance by adding a new AT, in order not
> to break the current schema, we apply the modification to a cloned
> Registries. So far, so good. And if the new registries is ok with the
> newly added SchemaObject, we swap the registries.
>
> Now, this create a dull issue : all the ServerEntry instances still
> point to the previous registries, and as we clean the previous
> registries to avoid memory leaks, all those instances now point to non
> existing SchemaObjects (more specifically, each instance has attributes
> which contain a reference to the AttributeType schemaObject they are
> associated with) !
>
> Question : how can we avoid this problem ? My idea is to apply the
> modification to the initial registries once it has been proven that the
> registries alteration leave the Regsitries consistent. We will just
> clean the cloned registries, and don't swap anymore.
>
> Does it sound good to you, or do you have any better idea ?
>

Re: [Schema Refactoring] Serious side effect...

2009-11-23T01:10:17Z

Hi Emmanuel,

I think you're right. It's definitely a better idea.

You probably have a lot of objects of the original registry in use in
other classes or data structures.

Swapping registries means updating all the schema objects values
contained in the original registry which is kind of unnecessary
because most of these objects have no been modified at all.

So I think it definitely makes sense. Especially when i have in mind
the use the schema manager to rewrite the schema editor plugin for
Studio.

Using the registry swap would force us to do a lot of refresh in the
UI for almost nothing.

Regards,
P-A

On 23 nov. 2009, at 09:31, Emmanuel Lecharny <elecharny@...>
wrote:

> Hi,
>
> when we modify the schema, for instance by adding a new AT, in order
> not to break the current schema, we apply the modification to a
> cloned Registries. So far, so good. And if the new registries is ok
> with the newly added SchemaObject, we swap the registries.
>
> Now, this create a dull issue : all the ServerEntry instances still
> point to the previous registries, and as we clean the previous
> registries to avoid memory leaks, all those instances now point to
> non existing SchemaObjects (more specifically, each instance has
> attributes which contain a reference to the AttributeType
> schemaObject they are associated with) !
>
> Question : how can we avoid this problem ? My idea is to apply the
> modification to the initial registries once it has been proven that
> the registries alteration leave the Regsitries consistent. We will
> just clean the cloned registries, and don't swap anymore.
>
> Does it sound good to you, or do you have any better idea ?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>

[Schema Refactoring] Serious side effect...

2009-11-23T00:31:34Z

Hi,

when we modify the schema, for instance by adding a new AT, in order not
to break the current schema, we apply the modification to a cloned
Registries. So far, so good. And if the new registries is ok with the
newly added SchemaObject, we swap the registries.

Now, this create a dull issue : all the ServerEntry instances still
point to the previous registries, and as we clean the previous
registries to avoid memory leaks, all those instances now point to non
existing SchemaObjects (more specifically, each instance has attributes
which contain a reference to the AttributeType schemaObject they are
associated with) !

Question : how can we avoid this problem ? My idea is to apply the
modification to the initial registries once it has been proven that the
registries alteration leave the Regsitries consistent. We will just
clean the cloned registries, and don't swap anymore.

Does it sound good to you, or do you have any better idea ?

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Schema Refactoring] Pb with AT, Collective and missing Usage

2009-11-22T17:40:00Z

I guess this finding in the rfc clarifies the issue for you. Any other implementation issues in your way?

On Nov 22, 2009 2:41 PM, "Emmanuel Lecharny" <elecharny@...> wrote:

Sorry, I was plain wrong. RFC 4512, par. 4.1.2 states that :

"Usage of userApplications, the default, indicates that attributes of this type represent user information. That is, they are user attributes."

So the userApplications value is the default, and this parameter is not inherited from a SUP :

"If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields, if not specified, take their value from the supertype."
Emmanuel Lecharny wrote: > > Hi, > > I had to remove the default initialization of the USAGE param...

Re: [Schema Refactoring] Pb with AT, Collective and missing Usage

2009-11-22T11:41:23Z

Sorry, I was plain wrong. RFC 4512, par. 4.1.2 states that :

"Usage of userApplications, the default, indicates that attributes of
this type represent user information. That is, they are user attributes."

So the userApplications value is the default, and this parameter is not
inherited from a SUP :

"If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields,
if not specified, take their value from the supertype."

Emmanuel Lecharny wrote:

> Hi,
>
> I had to remove the default initialization of the USAGE parameter for
> AttributeType, as we need to check that an injected AT is correct, and
> it might not be the case if it has a SUP which is not a
> UserApplications AT.
>
> Let me explain the problem with some example. Let's assume we have 2
> AT, 'parent' and 'child' :
>
> ( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
> ( 2.5.4.4 NAME 'child' SUP parent )
>
> as child inherit from parent, it must have the same Usage value. In
> this case, everything is fine, as we don't have a USAGE specified, as
> soon as the USAGE does not default to UserApplications, otherwise we
> have an error :
>
> ( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
> ( 2.5.4.4 NAME 'child' SUP parent USAGE userApplications ) /!\ Not
> allowed /!\
>
> Now, if we don't store the Usage with a default value (
> userApplications ), we can deal with the first case, as Usage will be
> null. If we don't have a SUP, we then can default to userApplications.
>
> Things get a bit muddier when the AT has a COLLECTIVE flag set, as now
> the USAGE *must* be userApplications.
>
> Sadly, the description parser for such a case throw an exception when
> trying to parse :
> ( 2.5.4.3 NAME 'cn' SUP name COLLECTIVE )
> as it does not know that the SUP has a userApplications Usage.
>
> IMO, we have to fix this by assuming that the SUP has necessarily a
> userApplications USAGE when we have a SUP *and* a COLLECTIVE
> parameters in the string. If we don't have a SUP, then we can default
> USAGE to userApplications.
>
> wdyt ?
>

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[Schema Refactoring] Pb with AT, Collective and missing Usage

2009-11-22T11:31:32Z

Hi,

I had to remove the default initialization of the USAGE parameter for
AttributeType, as we need to check that an injected AT is correct, and
it might not be the case if it has a SUP which is not a UserApplications AT.

Let me explain the problem with some example. Let's assume we have 2 AT,
'parent' and 'child' :

( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
( 2.5.4.4 NAME 'child' SUP parent )

as child inherit from parent, it must have the same Usage value. In this
case, everything is fine, as we don't have a USAGE specified, as soon as
the USAGE does not default to UserApplications, otherwise we have an error :

( 2.5.4.3 NAME 'parent' USAGE directoryOperation )
( 2.5.4.4 NAME 'child' SUP parent USAGE userApplications ) /!\ Not
allowed /!\

Now, if we don't store the Usage with a default value ( userApplications
), we can deal with the first case, as Usage will be null. If we don't
have a SUP, we then can default to userApplications.

Things get a bit muddier when the AT has a COLLECTIVE flag set, as now
the USAGE *must* be userApplications.

Sadly, the description parser for such a case throw an exception when
trying to parse :
( 2.5.4.3 NAME 'cn' SUP name COLLECTIVE )
as it does not know that the SUP has a userApplications Usage.

IMO, we have to fix this by assuming that the SUP has necessarily a
userApplications USAGE when we have a SUP *and* a COLLECTIVE parameters
in the string. If we don't have a SUP, then we can default USAGE to
userApplications.

wdyt ?

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[jira] Updated: (DIRSTUDIO-589) InvalidNameException: unexpected token for user ids starting with hash sign

2009-11-20T06:59:39Z

[ https://issues.apache.org/jira/browse/DIRSTUDIO-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre-Arnaud Marcelot updated DIRSTUDIO-589:
---------------------------------------------

Fix Version/s: 1.5.1

> InvalidNameException: unexpected token for user ids starting with hash sign
> ---------------------------------------------------------------------------
>
> Key: DIRSTUDIO-589
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-589
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.0
> Environment: z/OS LDAP Server
> Reporter: Jürgen Weber
> Assignee: Stefan Seelmann
> Priority: Critical
> Fix For: 1.5.1
>
> Attachments: DIRSTUDIO-589.patch
>
>
> In our LDAP server we have user ids starting with hash sign (e.g. #123456)
> On searching an existing user
> (uid=\#123456)
> DS throws this exception.
> The search works with Jarek Gawor's browser 2.8.2 I believe it also worked with DS 1.4
> !ENTRY org.apache.directory.studio.connection.core 4 4 2009-11-17 10:44:53.792
> !MESSAGE Error while performing search
> - unexpected token: 123456
> !SUBENTRY 1 org.apache.directory.studio.connection.core 4 4 2009-11-17 10:44:53.792
> !MESSAGE javax.naming.InvalidNameException: unexpected token: 123456 [Root exception is line 1:6: unexpected token: 123456]
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:55)
> at org.apache.directory.shared.ldap.name.LdapDnParser.parseInternal(LdapDnParser.java:97)
> at org.apache.directory.shared.ldap.name.LdapDN.<init>(LdapDN.java:205)
> at org.apache.directory.studio.ldapbrowser.core.utils.JNDIUtils.getDn(JNDIUtils.java:48)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.searchAndUpdateModel(SearchRunnable.java:331)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.run(SearchRunnable.java:184)
> at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:114)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: line 1:6: unexpected token: 123456
> at org.apache.directory.shared.ldap.name.AntlrDnParser.special(AntlrDnParser.java:1219)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.pair(AntlrDnParser.java:932)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.string(AntlrDnParser.java:777)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeValue(AntlrDnParser.java:517)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeTypeAndValue(AntlrDnParser.java:405)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedName(AntlrDnParser.java:229)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedNames(AntlrDnParser.java:307)
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:51)
> ... 7 more
> !STACK 0
> javax.naming.InvalidNameException: unexpected token: 123456 [Root exception is line 1:6: unexpected token: 123456]
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:55)
> at org.apache.directory.shared.ldap.name.LdapDnParser.parseInternal(LdapDnParser.java:97)
> at org.apache.directory.shared.ldap.name.LdapDN.<init>(LdapDN.java:205)
> at org.apache.directory.studio.ldapbrowser.core.utils.JNDIUtils.getDn(JNDIUtils.java:48)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.searchAndUpdateModel(SearchRunnable.java:331)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.run(SearchRunnable.java:184)
> at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:114)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: line 1:6: unexpected token: 123456
> at org.apache.directory.shared.ldap.name.AntlrDnParser.special(AntlrDnParser.java:1219)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.pair(AntlrDnParser.java:932)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.string(AntlrDnParser.java:777)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeValue(AntlrDnParser.java:517)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeTypeAndValue(AntlrDnParser.java:405)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedName(AntlrDnParser.java:229)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedNames(AntlrDnParser.java:307)
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:51)
> ... 7 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRSTUDIO-589) InvalidNameException: unexpected token for user ids starting with hash sign

2009-11-20T06:59:39Z

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRSTUDIO-591) Error reading objects with # in DN

2009-11-20T06:59:39Z

[ https://issues.apache.org/jira/browse/DIRSTUDIO-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pierre-Arnaud Marcelot updated DIRSTUDIO-591:
---------------------------------------------

Fix Version/s: 1.5.1

> Error reading objects with # in DN
> -----------------------------------
>
> Key: DIRSTUDIO-591
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-591
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.0
> Environment: WinXP SP3
> java version "1.6.0_14"
> Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
> Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
> Eclipse Galileo Build id: 20090920-1017
> Reporter: a-giza
> Assignee: Stefan Seelmann
> Priority: Minor
> Fix For: 1.5.1
>
>
> An error occurs when reading objects with # in DN. The DN looks like this: cn=#ACL_AD-Projects_Author,ou=Notes_Group,o=Contacts,c=DE
> The error occurs since version 1.5. Versions before 1.5 have no problems with this kind of DN's.
> The detailed error Message is:
> eclipse.buildId=M20090917-0800
> java.version=1.6.0_14
> java.vendor=Sun Microsystems Inc.
> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE
> Framework arguments: -product org.eclipse.epp.package.jee.product
> Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product
> Error
> Wed Nov 18 16:34:39 CET 2009
> Fehler beim Lesen des Eintrages
> - unexpected token: AC
> Error
> Wed Nov 18 16:34:39 CET 2009
> javax.naming.InvalidNameException: unexpected token: AC [Root exception is line 1:5: unexpected token: AC]
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:55)
> at org.apache.directory.shared.ldap.name.LdapDnParser.parseInternal(LdapDnParser.java:97)
> at org.apache.directory.shared.ldap.name.LdapDN.<init>(LdapDN.java:205)
> at org.apache.directory.studio.ldapbrowser.core.utils.JNDIUtils.getDn(JNDIUtils.java:48)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.searchAndUpdateModel(SearchRunnable.java:331)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.executeSearch(InitializeChildrenRunnable.java:361)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.initializeChildren(InitializeChildrenRunnable.java:212)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.run(InitializeChildrenRunnable.java:171)
> at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:114)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: line 1:5: unexpected token: AC
> at org.apache.directory.shared.ldap.name.AntlrDnParser.special(AntlrDnParser.java:1219)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.pair(AntlrDnParser.java:932)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.string(AntlrDnParser.java:777)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeValue(AntlrDnParser.java:517)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeTypeAndValue(AntlrDnParser.java:405)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedName(AntlrDnParser.java:229)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedNames(AntlrDnParser.java:307)
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:51)
> ... 9 more
> javax.naming.InvalidNameException: unexpected token: AC [Root exception is line 1:5: unexpected token: AC]
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:55)
> at org.apache.directory.shared.ldap.name.LdapDnParser.parseInternal(LdapDnParser.java:97)
> at org.apache.directory.shared.ldap.name.LdapDN.<init>(LdapDN.java:205)
> at org.apache.directory.studio.ldapbrowser.core.utils.JNDIUtils.getDn(JNDIUtils.java:48)
> at org.apache.directory.studio.ldapbrowser.core.jobs.SearchRunnable.searchAndUpdateModel(SearchRunnable.java:331)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.executeSearch(InitializeChildrenRunnable.java:361)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.initializeChildren(InitializeChildrenRunnable.java:212)
> at org.apache.directory.studio.ldapbrowser.core.jobs.InitializeChildrenRunnable.run(InitializeChildrenRunnable.java:171)
> at org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:114)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: line 1:5: unexpected token: AC
> at org.apache.directory.shared.ldap.name.AntlrDnParser.special(AntlrDnParser.java:1219)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.pair(AntlrDnParser.java:932)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.string(AntlrDnParser.java:777)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeValue(AntlrDnParser.java:517)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.attributeTypeAndValue(AntlrDnParser.java:405)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedName(AntlrDnParser.java:229)
> at org.apache.directory.shared.ldap.name.AntlrDnParser.relativeDistinguishedNames(AntlrDnParser.java:307)
> at org.apache.directory.shared.ldap.name.ComplexLdapDnParser.parseDn(ComplexLdapDnParser.java:51)
> ... 9 more

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRSTUDIO-591) Error reading objects with # in DN

2009-11-20T06:59:39Z

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRSTUDIO-599) Widget disposed too early

2009-11-20T06:03:39Z

[ https://issues.apache.org/jira/browse/DIRSTUDIO-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780560#action_12780560 ]

Giannis Kapetanakis commented on DIRSTUDIO-599:
-----------------------------------------------

Well this is strange:

In my previous post I used /usr/lib/xulrunner/xulrunner-1.9.1 which was not a valid path for xulrunner.

Running with random path also works

./ApacheDirectoryStudio -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/foo/bar

also worked (after the rm -rf)

Giannis

> Widget disposed too early
> -------------------------
>
> Key: DIRSTUDIO-599
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-599
> Project: Directory Studio
> Issue Type: Bug
> Affects Versions: 1.4.0, 1.5.0
> Environment: 2.6.31.5-127.fc12.i686.PAE
> Fedora 12
> Reporter: Giannis Kapetanakis
> Attachments: .log
>
>
> I've come to the same bug as in
> https://issues.apache.org/jira/browse/DIRSTUDIO-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> I'm attaching the log file.
> The fix is the same:
> rm -rf ~/.ApacheDirectoryStudio/
> cd /usr/local/ApacheDirectoryStudio-linux-x86-1.5.0.v20091102/
> ./ApacheDirectoryStudio -vmargs -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner/xulrunner-1.9.1
> Pierre I don't know what might be altering the 'org.eclipse.swt.browser.XULRunnerPath' property value on my setup.
> Could it be that I'm NOT using Fedora's shipped Java? I use Sun's version of JAVA.
> I've created sym links /usr/bin for this and set the JAVA_HOME appropriately.
> Regards,
> Giannis

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.