AS7 Naming URL resolution

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

AS7 Naming URL resolution

Bartosz Baranowski

Hi
Not quite sure if Im correct on this but Ive been digging a bit in naming code of AS7 and here is what Ive found(I might have missed something but..):

1. NamingContext appends Context.URL_PACKAGES_PREFIXES with "org.jboss.as.naming.interfaces"
2. The "org.jboss.as.naming.interfaces" has single interface for "java" URL - which it seems is never used.
3. InitialContext:50 has static variable which maps URL scheme to ObjectFactory. Mappings are added/removed upon Extension/Subsystem start. At runtime it holds mappings like "ejb", "corba", "iiop" and similar. This does not include handlers for URLs like 'rmi', 'ldap' etc, and this is a a glitch.

Trick here is that NamingManager and InitialContext from JDK use Context.URL_PACKAGES_PREFIXES only in case when NamingManager has no InitialContextFactoryBuilder set. So this is basically what happens when application tries lookup from AS7:

1. JDK InitialContext uses NamingManager to create default CTX - this is AS7 InitialContext impl. This step bypasses URL_PACKAGES_PREFIXES code
2. Parse lokup name - this includes some hack for "java:" prefix
3. AS7 InitialContext check if there is URL scheme and check InitialContext:50 if it contains this scheme
4. If not, use AS7 NamingContext lookup - which essentially performs lookup in ServiceBasedNamingStore.

Now this missing part which works with package prefixes makes for instance JMXConnector unusable without explicitly setting custom InitialContext factory in env. There is ofcourse AS7 wide ObjectFactory but its used only for inmodule lookups - that is in case that ServiceBasedNamingStore returns something meaningful and not throw exception. Now after this long intro:

1. org.jboss.as.naming.interfaces.java seems not to be used since "java:" is handled with some hacks - possibly this package can be removed?
2. Is there any policy against URL_PACKAGES to be used to lookup context factory ? Right now its not used, effectively removing support for code like:

            String urlString = "service:jmx:rmi:///jndi/rmi://any_host:1090/jmxrmi";
            JMXServiceURL serviceURL = new JMXServiceURL(urlString);
            Map<String, String> env = null;
            connector = JMXConnectorFactory.connect(serviceURL, env);

If not, AS7 can fallback, in case it does not find any locally cached instance of factory, to this property and try to find factory class?
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7 Naming URL resolution

Bartosz Baranowski
Anyone?

----- Original Message -----
From: "Bartosz Baranowski" <[hidden email]>
To: [hidden email]
Sent: Thursday, March 8, 2012 10:02:30 AM
Subject: AS7 Naming URL resolution


Hi
Not quite sure if Im correct on this but Ive been digging a bit in naming code of AS7 and here is what Ive found(I might have missed something but..):

1. NamingContext appends Context.URL_PACKAGES_PREFIXES with "org.jboss.as.naming.interfaces"
2. The "org.jboss.as.naming.interfaces" has single interface for "java" URL - which it seems is never used.
3. InitialContext:50 has static variable which maps URL scheme to ObjectFactory. Mappings are added/removed upon Extension/Subsystem start. At runtime it holds mappings like "ejb", "corba", "iiop" and similar. This does not include handlers for URLs like 'rmi', 'ldap' etc, and this is a a glitch.

Trick here is that NamingManager and InitialContext from JDK use Context.URL_PACKAGES_PREFIXES only in case when NamingManager has no InitialContextFactoryBuilder set. So this is basically what happens when application tries lookup from AS7:

1. JDK InitialContext uses NamingManager to create default CTX - this is AS7 InitialContext impl. This step bypasses URL_PACKAGES_PREFIXES code
2. Parse lokup name - this includes some hack for "java:" prefix
3. AS7 InitialContext check if there is URL scheme and check InitialContext:50 if it contains this scheme
4. If not, use AS7 NamingContext lookup - which essentially performs lookup in ServiceBasedNamingStore.

Now this missing part which works with package prefixes makes for instance JMXConnector unusable without explicitly setting custom InitialContext factory in env. There is ofcourse AS7 wide ObjectFactory but its used only for inmodule lookups - that is in case that ServiceBasedNamingStore returns something meaningful and not throw exception. Now after this long intro:

1. org.jboss.as.naming.interfaces.java seems not to be used since "java:" is handled with some hacks - possibly this package can be removed?
2. Is there any policy against URL_PACKAGES to be used to lookup context factory ? Right now its not used, effectively removing support for code like:

            String urlString = "service:jmx:rmi:///jndi/rmi://any_host:1090/jmxrmi";
            JMXServiceURL serviceURL = new JMXServiceURL(urlString);
            Map<String, String> env = null;
            connector = JMXConnectorFactory.connect(serviceURL, env);

If not, AS7 can fallback, in case it does not find any locally cached instance of factory, to this property and try to find factory class?
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7 Naming URL resolution

jtgreene
Administrator
On 3/9/12 12:17 PM, Bartosz Baranowski wrote:

> Anyone?
>
> ----- Original Message -----
> From: "Bartosz Baranowski"<[hidden email]>
> To: [hidden email]
> Sent: Thursday, March 8, 2012 10:02:30 AM
> Subject: AS7 Naming URL resolution
>
>
> Hi
> Not quite sure if Im correct on this but Ive been digging a bit in naming code of AS7 and here is what Ive found(I might have missed something but..):
>
> 1. NamingContext appends Context.URL_PACKAGES_PREFIXES with "org.jboss.as.naming.interfaces"
> 2. The "org.jboss.as.naming.interfaces" has single interface for "java" URL - which it seems is never used.
> 3. InitialContext:50 has static variable which maps URL scheme to ObjectFactory. Mappings are added/removed upon Extension/Subsystem start. At runtime it holds mappings like "ejb", "corba", "iiop" and similar. This does not include handlers for URLs like 'rmi', 'ldap' etc, and this is a a glitch.
>
> Trick here is that NamingManager and InitialContext from JDK use Context.URL_PACKAGES_PREFIXES only in case when NamingManager has no InitialContextFactoryBuilder set. So this is basically what happens when application tries lookup from AS7:
>
> 1. JDK InitialContext uses NamingManager to create default CTX - this is AS7 InitialContext impl. This step bypasses URL_PACKAGES_PREFIXES code
> 2. Parse lokup name - this includes some hack for "java:" prefix
> 3. AS7 InitialContext check if there is URL scheme and check InitialContext:50 if it contains this scheme
> 4. If not, use AS7 NamingContext lookup - which essentially performs lookup in ServiceBasedNamingStore.
>
> Now this missing part which works with package prefixes makes for instance JMXConnector unusable without explicitly setting custom InitialContext factory in env. There is ofcourse AS7 wide ObjectFactory but its used only for inmodule lookups - that is in case that ServiceBasedNamingStore returns something meaningful and not throw exception. Now after this long intro:
>
> 1. org.jboss.as.naming.interfaces.java seems not to be used since "java:" is handled with some hacks - possibly this package can be removed?
> 2. Is there any policy against URL_PACKAGES to be used to lookup context factory ? Right now its not used, effectively removing support for code like:
>
>              String urlString = "service:jmx:rmi:///jndi/rmi://any_host:1090/jmxrmi";
>              JMXServiceURL serviceURL = new JMXServiceURL(urlString);
>              Map<String, String>  env = null;
>              connector = JMXConnectorFactory.connect(serviceURL, env);

We no longer use RMI for JMX access for security reasons:

https://community.jboss.org/wiki/UsingJconsoleToConnectToJMXOnAS7

The intention of the java url package was to allow an alternative
INITIAL_CONTEXT_FACTORY, although it's recommend to just use our
initial_context_factory, but we set that up automatically if you are in
an EE context.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: AS7 Naming URL resolution

Bartosz Baranowski


----- Original Message -----
From: "Jason T. Greene" <[hidden email]>
To: "Bartosz Baranowski" <[hidden email]>
Cc: [hidden email]
Sent: Tuesday, March 13, 2012 11:31:18 AM
Subject: Re: [jboss-as7-dev] AS7 Naming URL resolution

On 3/9/12 12:17 PM, Bartosz Baranowski wrote:

> Anyone?
>
> ----- Original Message -----
> From: "Bartosz Baranowski"<[hidden email]>
> To: [hidden email]
> Sent: Thursday, March 8, 2012 10:02:30 AM
> Subject: AS7 Naming URL resolution
>
>
> Hi
> Not quite sure if Im correct on this but Ive been digging a bit in naming code of AS7 and here is what Ive found(I might have missed something but..):
>
> 1. NamingContext appends Context.URL_PACKAGES_PREFIXES with "org.jboss.as.naming.interfaces"
> 2. The "org.jboss.as.naming.interfaces" has single interface for "java" URL - which it seems is never used.
> 3. InitialContext:50 has static variable which maps URL scheme to ObjectFactory. Mappings are added/removed upon Extension/Subsystem start. At runtime it holds mappings like "ejb", "corba", "iiop" and similar. This does not include handlers for URLs like 'rmi', 'ldap' etc, and this is a a glitch.
>
> Trick here is that NamingManager and InitialContext from JDK use Context.URL_PACKAGES_PREFIXES only in case when NamingManager has no InitialContextFactoryBuilder set. So this is basically what happens when application tries lookup from AS7:
>
> 1. JDK InitialContext uses NamingManager to create default CTX - this is AS7 InitialContext impl. This step bypasses URL_PACKAGES_PREFIXES code
> 2. Parse lokup name - this includes some hack for "java:" prefix
> 3. AS7 InitialContext check if there is URL scheme and check InitialContext:50 if it contains this scheme
> 4. If not, use AS7 NamingContext lookup - which essentially performs lookup in ServiceBasedNamingStore.
>
> Now this missing part which works with package prefixes makes for instance JMXConnector unusable without explicitly setting custom InitialContext factory in env. There is ofcourse AS7 wide ObjectFactory but its used only for inmodule lookups - that is in case that ServiceBasedNamingStore returns something meaningful and not throw exception. Now after this long intro:
>
> 1. org.jboss.as.naming.interfaces.java seems not to be used since "java:" is handled with some hacks - possibly this package can be removed?
> 2. Is there any policy against URL_PACKAGES to be used to lookup context factory ? Right now its not used, effectively removing support for code like:
>
>              String urlString = "service:jmx:rmi:///jndi/rmi://any_host:1090/jmxrmi";
>              JMXServiceURL serviceURL = new JMXServiceURL(urlString);
>              Map<String, String>  env = null;
>              connector = JMXConnectorFactory.connect(serviceURL, env);

We no longer use RMI for JMX access for security reasons:

https://community.jboss.org/wiki/UsingJconsoleToConnectToJMXOnAS7

The intention of the java url package was to allow an alternative
INITIAL_CONTEXT_FACTORY, although it's recommend to just use our
initial_context_factory, but we set that up automatically if you are in
an EE context.


Yes, I know, Khabir already mentioned that. However trick here is that it does not allow to connect to other containers. So if I have standalone RMI server runing, I wont be able to connect to it with above code.

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev