Can I configure a global jndi environment entry in JBoss 3.2

[mwomack]

Similar to something I have done in Tomcat 5.5.4, I want to define a jndi environment entry. In a web.xml, it would look something like this:

<web-app>
<env-entry>
<env-entry-name>MaxValue<env-entry-name>
<env-entry-type>java.lang.Float</env-entry-type>
<env-entry-value>45.4</env-entry-value>
</env-entry>
</web-app>

And I would access it via java code like this:

InitialContext ctx = new InitialContext();
Float oValue = (Float)ctx.lookup("java:comp/env/MaxValue");
float value = oValue.floatValue();

Tomcat 5.5.4 lets me define this jndi entry by modifying the server.xml and context.xml files to define a global named resource. It defines and maintaines this jndi entry at the server context. I don't have to modify the web.xml of my web application or add any different/new files at deployment time.

Is there a similar way to configure this in JBoss 3.2.5? I see a lot of examples for jdbc or data sources, but I cannot seem to find anything about entries.

thanks,
-Mark

[idmilton]

> Negative.

negative on the negative.

> JMX is our component layer. Although AOP objects may

Yes.

AOP for me is just a way to add interfaces and interceptors to an existing object.

> not go through a JMX "Invoker" (whether that be a
> connector or JBoss Invoker), we still want things
> like EJB to go through the JMX layer. This is

EJB is a particular case as it does have an mbean. Many objects will want the remoteness and not necessarily be mbeans. I think it is a mistake to say "only mbeans are remote". Many many objects will want remoteness.

Look at the end of the day there isn't much in this discussion. The logical name and the signature is what counts. We all pretty much agree on the signature (we are all already close to the detyped signature) the only difference would be the object name (JMX or purely logical) that gets embedded in client proxies and added to the invocation. In fact when I wrote the first implementation I remember allowing purely logical names.

In the case of JMX the logical name is pointing to an adapter that takes the generic Invocation, extracts the JMX name from it and call the JMX bus with the equivalent invoke() signature from the dynamic MBean. This is all bundled in the invokers today and in fact they are tied to JMX in that fashion. Adrian and I are steady on the fact that many invocation paths will still go without mbean stuff.

> because of redeployment. To provide 24/7, we need
> invocations to be blocked while a component is being
> cycled. In fact, maybe AOP invocations should go
> through JMX as well.

wow... no no no please.

it is a mistake. So you want to leverage the 24.7 idea? there are 2 ways with the EJB and generic

1- Make the 24x7 stuff an interceptor that reads a 'state' of the target. In the case the component has a JMX state associated to it then we are all set. Today it will be tied to it.

2- Do the move we are talking about. Make the invokers generic "Unified Invokers". Unified Invokers are still MBeans themselves they are components. But they only look up logical names and delegate to a real invoker. JMX ones will go through the same chain of command and you still leverage the existing code.

> P.S. Please move this discussion to forums....

done,

marcf

[starksm64]

The only support for this is at the ejb-jar.xml descriptor level. There is no notion of default environments that should apply. You can write an mbean service that parsed such entries and made them available in the global jndi namespace. The bindings cannot be under the java:comp name as this is a component local namespace by spec definition.

[mwomack]

Scott, thanks for the reply. So, instead of jndi, is it possible to create a container-wide context-param setting available to the web apps? Or is the idea of default, container-side environment settings just not supported in JBoss?

thanks again,
-Mark

[mwomack]

If I can't set up a JNDI value available to all the web apps, can I somehow setup context-param overrides for each individual web application?

What I am really trying to acheive is the setting of some context-param values in the container so that the deployer does not need to go into the web.xml and make changes there.

-Mark

[starksm64]

Try setting the context-param in the DefaultContext of the jbossweb-tomcat50.sar/server.xml

[idmilton]

Scott,

"The only support for this is at the ejb-jar.xml descriptor level"

Does this mean there is no support for the following example ?

(allowing different values to be provided per context per application server instance)

With Tomcat an Environment context entry in server.xml can be accessed via the Web Application Component (say webapp1). An example might be;

<Context path="/webApp1" docBase="webApp1" debug="4" reloadable="true" crossContext="false">
 <Environment description="Server specific port"
 name="port/myServicePort" type="java.lang.String"
 value="9999"
 override="false"/>
</Context>

a second context for say webApp2 might be;

<Context path="/webApp2" docBase="webApp2" debug="4" reloadable="true" crossContext="false">
 <Environment description="Server specific port"
 name="port/myServicePort" type="java.lang.String"
 value="8888"
 override="false"/>
</Context>

This provides seperate ENC's for both webApp1 and webApp2 neither of which use EJB's.

The Application components (webApp1 & webApp2) have the following defined in their own web.xml deployment descriptors.

<env-entry>
 <description>Server specific port</description>
 <env-entry-name>port/myServicePort</env-entry-name>
 <env-entry-value>8899</env-entry-value>
 <env-entry-type>java.lang.String</env-entry-type>
 </env-entry>

"The bindings cannot be under the java:comp name as this is a component local namespace by spec definition."

I don't know but shouldn't both Web components and EJB components be accessed under java:comp ? If so the spec suggests that the J2EE product provider supplies a tool to set and modify the values.

Any help answering these questions would be greatly appreciated.

[starksm64]

web app specific entries should be in the web.xml descriptor. The bindings of some global jndi service cannot be under java:comp. The web.xml settings always are.

[idmilton]

Scott, thanks for the reply.

I see where you are coming from but my issue is the following wording in the JNDI specification;

The environment entries are declared using the env-entry elements in the deployment descriptor

web.xml in this case

Each env-entry element describes a single environment entry. The env-entry element consists of an optional description of the environment entry name relative to the java:comp/env context, the expected java programming language type of the environment entry value (the type of the object returned from the JNDI lookup method), and an optional environment entry value.

Testing under both Tomcat and Oracle OC4J this rule seems to apply.

Additionally under Tomcat it seems that each Web Application has it's own context with env-entry pairs scoped only within that Web Application and it's instances, other Web Applications do not have access to those env-entry pairs. (i.e. Tomcat would seem to treat webapps themselves as application components).

[starksm64]

jboss and jboss/tomcat do the same. What is the descrepency here?

[starksm64]

And jboss certainly does create a java:comp/env context that is unique per web application with the contents of the web.xml entries, so I'm not sure what that is being discussed. We do not support specification of defaults at the server.xml level. We do support a war/WEB-INF/context.xml, but its rather pointless to have a war specific non-standard descriptor specify the java:comp/env context values.

Create a feature request for the server level default entries in jira:
http://jira.jboss.com/jira/browse/JBAS

[idmilton]

Thanks for your patience Scott.

May be a silly question but should I expect to see the java:/comp/env entry via the JNDIViewer list option for the env-entry value specified in the web.xml.

And yes I can understand the confusion about server.xml entries that can reside either within server.xml or within context.xml (same meaning to Tomcat when it merges them).

Within the Tomcat server.xml configuration file tags can be defined either under the scope of but also under the scope of . However if you dont support server.xml level defaults then by the sound of it neither is supported, will raise a feature request as per your suggestion.

[starksm64]

JNDIView is not the defining service of the java:comp/env component environment. It does not access the web tier bindings due to an implementation detail of how how the enc is scoped to the web deployment class loader.

[skull]

hello, i have a similar problem, how to resolve that?

need to create a env-entry for all web-apps, and dont know how to begin, i was try somethings that no one work, ejb-jar.xml without ejb dont work.

can someone post complet config for that?