Skip to content
This repository has been archived by the owner on Nov 16, 2021. It is now read-only.

[JNDI] Services Specification issues #11

Open
bjhargrave opened this issue Jan 17, 2011 · 1 comment
Open

[JNDI] Services Specification issues #11

bjhargrave opened this issue Jan 17, 2011 · 1 comment
Labels
publiccomment Public comment

Comments

@bjhargrave
Copy link
Member

Original bug ID: BZ#112
From: Ivan Dubrov <[email protected]>
Reported version: R4 V4.2

@bjhargrave
Copy link
Member Author

Comment author: Ivan Dubrov <[email protected]>

The full issue in question is at https://mail.osgi.org/pipermail/osgi-dev/2010-September/002638.html

Sometimes JNDI provider calls getObjectInstance providing "resolved"
object (not a reference, javax.naming.Reference), for example instance
of JMS javax.jms.ConnectionFactory. According to the 126.4/6 [1], my
implementation of JNDIProviderAdmin tries to convert object with all
possible factories. The problem is that most JBoss factories expect
object passed to be javax.naming.Reference, so ClassCastException is
thrown. According to the specification (see the end of the 126.4 [2]),
the exception must be propagated to the caller, breaking the JNDI
resolution.

[1] Snippet from the OSGi Service Platform Release 4, Enterprise
Specification 4.2, section 126.4/6:

If the description was a Reference and without a factory class name
specified, or if the description was not of type Reference, then
attempt to convert the object with each Object Factory service (or Dir
Object Factory service for directories) service in ranking order until a
non-null value is returned.

[2] Exceptions handling:

If an Exception occurs during the use of an Object Factory Builder
service then this exception should be logged but must be ignored. If,
however, an Exception occurs during the calling of a found ObjectFactory
or DirObjecFactory object then this Exception must be re-thrown to the
caller of the JNDI Provider Admin service
.

To sum up:

Faulty ObjectFactory can break JNDI resolution completely, even when client tries to resolve completely valid references implemented by different provider.

@bjhargrave bjhargrave added the publiccomment Public comment label May 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
publiccomment Public comment
Projects
None yet
Development

No branches or pull requests

1 participant