This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 27494 - [core/naming] JNDI problems when names >= 50 chars or contain nonalphanumeric chars
Summary: [core/naming] JNDI problems when names >= 50 chars or contain nonalphanumeric...
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords:
Depends on: 17142
Blocks:
  Show dependency tree
 
Reported: 2002-09-21 00:06 UTC by Torbjorn Norbye
Modified: 2008-12-22 20:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Torbjorn Norbye 2002-09-21 00:06:53 UTC
The projects module is using core naming JNDI to store
and retrieve its context settings.

When the context settings names get long - e.g. 50
characters
or more, or when they contain "troublesome"
characters,
such as ".", InstanceDataObject changes the names
of the
.settings files (see its escape and escapeAndCut)
methods.
When we search for settings by a particular name
we therefore
don't find these.

The reason names may easily get 50 characters is
that to prevent
module conflicts prefixes for settings are used.
By default
we tried the settings object's classname - but
that's not
only long, it contains dots as well :)

For now we're working around this by truncating
the property
names the same way you're doing it (by duplicating
the code
on our side) but a general solution would be better.
Comment 1 Marian Mirilovic 2002-10-09 09:40:30 UTC
reassigne to pzavadsky , our new naming guru.
Comment 2 Peter Zavadsky 2002-11-08 08:28:33 UTC
Fixed in [trunk].

openide/../loaders/InstanceDataObject.java 1.137
core/naming/../Utils.java 1.3
           /test/unit/../JndiBindTest.java 1.7
Comment 3 Marian Mirilovic 2004-03-15 15:00:39 UTC
fixed long time ago.....
...verified....
reopen if disagree