Hi, see my comments inline
regards, Achim 2017-03-02 7:58 GMT+01:00 Stephan Siano <stephan.si...@sap.com>: > Hi Achim, > > ok, but we are talking about two different things here. Maybe I elaborate > this a bit: > > The OSGi compendium spec contains a JNDI services specification chapter > (126) that describes how OSGi services can be made available as a global > JNDI reference. That is what you describe (and what is implemented by > aries-jndi and is working just fine). > > The Web Application is specifid in chapter 128 (and pax-web is the > reference implementation for that). That section does not say anything > about JNDI contexts, but is referring to the Servlet 2.5 specification > about the functionaltiy the WAB can use. The servle specification specifies > that some tags from the web.xml (like env-entry) should be registered in > the JNDI namespace of the web application. These java:comp/env JNDI > subtrees should be local to the component (in case of web applications that > is the whole war for historical reasons). > afaik this part was never considered, as in an OSGi env you usually reference services from the outside. > > This functionality of having a war specific JNDI tree available under > java:comp/env seems to be not there. Now the questions are: > Is the functionality of component specific JNDI contexts available but I > am doing something wrong? > Should the this functionality be there? > not to my knowledge. > If it is not but should be there, where would that needed to be > implemented? In aries-jndi, in pax-web or in the integration code of the > web container? > > that's a good question, right now my gut feeling tells me it would be part of the aries-jndi thing, as with an JEE server, a webcontainer always uses the surrounding JNDI environment. > To come back to the use of the tomcat-server.xml: what would be the > expected funtionality of the GlobalNamingResources element then? Normally > it's supposed to define resources that are included in all WAR's component > specific JNDI contexts (but these don't seem to exist at all). > > we never had this requirement before. > Best regards > Stephan > S > > Am Mittwoch, 1. März 2017 20:05:32 UTC+1 schrieb Achim Nierbeck: >> >> Hi Stephan, >> >> it's been some time, but yes I've been able to use JNDI as lookups for >> services. >> Though the trick is you need to have the according service as JNDI >> available. >> >> If you want to reference a datasource via JNDI for example, you need to >> have the datasource service available as JNDI resource >> so you need to add a service property to the service declaring the >> osgi.jndi.service.name [1]. >> >> When referencing a JNDI resource make sure you have the OSGi service >> lookup with it. >> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=YourJNDILookup >> [2] >> >> regards, Achim >> >> [1] - https://github.com/ANierbeck/karaf-enterprise-sample/blob/ >> master/datasource-cookbook/src/main/resources/OSGI-INF/ >> blueprint/datasource-cookbook.xml#L14-L18 >> [2] - https://github.com/ANierbeck/karaf-enterprise-sample/blob/ >> master/sample-persistence/src/main/resources/META-INF/persistence.xml#L26 >> >> 2017-03-01 14:40 GMT+01:00 Stephan Siano <stepha...@sap.com>: >> >>> Hi, >>> >>> I am currently working on PAXWEB-630 (interpret and use the >>> tomcat-server.xml). One of the entities that can be configured are >>> GlobalNamingResources. With my changes, I can see the configured options in >>> the MBean tree, but when I tried to test them in an integration test it did >>> not work. On further investigation I also did not manage to reference JNDI >>> resources configured in the web.xml, neither with the tomcat container nor >>> with the web container. I also tried a life karaf container, but this also >>> did not work. >>> >>> What I did: >>> 1. I added the following coding to the web.xml of the servlet war: >>> >>> <env-entry> >>> <env-entry-name>envEntryName</env-entry-name> >>> <env-entry-value>envEntryValue</env-entry-value> >>> <env-entry-type>java.lang.String</env-entry-type> >>> </env-entry> >>> >>> >>> 2. I added the following coding to my servlet coding: >>> >>> Context env = (Context)new InitialContext().lookup("java: >>> comp/env"); >>> String value = (String)env.lookup("envEntryName"); >>> >>> In the integration test and on the normal karaf instance, i received the >>> following error: >>> javax.naming.NoInitialContextException: Need to specify class name in >>> environment or system property, or as an applet parameter, or in an >>> application resource file: java.naming.factory.initial >>> at javax.naming.spi.NamingManager.getInitialContext(NamingManag >>> er.java:662)[:1.8.0_121] >>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext >>> .java:313)[:1.8.0_121] >>> at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialCo >>> ntext.java:350)[:1.8.0_121] >>> at javax.naming.InitialContext.lookup(InitialContext.java:417)[ >>> :1.8.0_121] >>> >>> If I add the JNDI feature into the karaf installation, I got the >>> following error: >>> javax.naming.NotContextException: java:comp/env >>> at org.apache.xbean.naming.context.AbstractContext.lookup( >>> AbstractContext.java:165)[85:org.apache.xbean.naming:3.18.0] >>> at org.apache.xbean.naming.context.AbstractContext.lookup( >>> AbstractContext.java:605)[85:org.apache.xbean.naming:3.18.0] >>> at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext >>> .java:161)[30:org.apache.aries.jndi.core:1.0.2] >>> at javax.naming.InitialContext.lookup(InitialContext.java:417)[ >>> :1.8.0_121] >>> >>> These errors were independent from whether I was using tomcat or jetty >>> as the web container. >>> If I deploy the same servlet into a plain tomcat container, the lookup >>> will work (and return envEntryValue) as the result. >>> >>> So the aries-jndi stuff seems to do something, but the context defined >>> in the web.xml are not honored. >>> >>> Has anybody managed to get JNDI lookups from the web container >>> environment running with pax-web? Is there something I missed there? I >>> could not find any context lookups anywhere in the Pax-Web coding >>> (including the tests). Is it possible that this feature is not available at >>> all? >>> >>> Best regards >>> Stephan >>> >>> -- >>> -- >>> ------------------ >>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OPS4J" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ops4j+un...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >> & Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> >> -- > -- > ------------------ > OPS4J - http://www.ops4j.org - ops4j@googlegroups.com > > --- > You received this message because you are subscribed to the Google Groups > "OPS4J" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ops4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
