As Kishanthan has explained in his last reply, this is not something broken and this is how Tomcat is supposed to work. Therefore, I think we have to have a meeting on this and decide what to do.
Thanks, ~Isuru On Fri, Jul 6, 2012 at 11:44 PM, Dinusha Senanayaka <[email protected]>wrote: > Hi Kishanthan/ AS Team, > > Today App-factory team raised this issue again and they also need to have > same requirement. (The capability of accessing resources( inside a wep-app) > that registered with JNDI via carbon component using default InitialContext > of carbon ). We need to discuss and come-up with a solution for this. > > Regards, > Dinusha. > > > On Thu, May 31, 2012 at 3:51 PM, Kishanthan Thangarajah < > [email protected]> wrote: > >> >> >> On Wed, May 30, 2012 at 1:44 PM, Dinusha Senanayaka <[email protected]>wrote: >> >>> Here, what we want is to use the same transaction-manager that has >>> expose by the transaction-manager component inside the web-app. But by >>> defining it as a resource in server.xml or context.xml , it register a new >>> transaction manager to use in wep-app rather using it from >>> transaction-manager component. So we loss the need of having >>> transaction-manager carbon component. >>> >> >> AFAIK, in previous releases, these resources (TransactionManager, etc) >> are registered with tomcat via the context descriptor file >> (CARBON_HOME/lib/tomcat/conf/context.xml). >> >> But according to the current implementation in trunk, we are registering >> those resources to Carbon's InitialContext via a carbon component >> (transaction-manager) and we want those resources to be accessible >> everywhere including webapps also. This is the requirement. But as I said >> earlier, this will not work as we can see that we are trying to access a >> resource which is not registered with tomcat. >> >> So I think the solution for this would be, when registering the resource >> via carbon, we have to somehow make those available to tomcat global >> resources. >> >> Kishanthan. >> >>> >>> Regards, >>> Dinusha. >>> >>> >>> On Tue, May 29, 2012 at 11:36 AM, Isuru Suriarachchi <[email protected]>wrote: >>> >>>> >>>> According to this, all our global resources can be registered in the >>>> tomcat server.xml and can be looked up from anywhere. So we can make the >>>> above resources work by doing this. >>>> >>>> But if we want to allow users to register and look up resources through >>>> the carbon context, we have to register those resources in the same context >>>> as the server.xml resources. Then only those can be made global. >>>> >>>> Thanks, >>>> ~Isuru >>>> >>>> >>>> On Tue, May 29, 2012 at 10:44 AM, Kishanthan Thangarajah < >>>> [email protected]> wrote: >>>> >>>>> This can be done. We have to first register JNDI resources for webapps >>>>> context. Then we can lookup for them. As Paul mentioned, registering those >>>>> resources can done in two ways. They can be either global or per webapp. >>>>> If >>>>> it is global, you have place them under <GlobalNamingResources> tag in >>>>> tomcat's server.xml (catalina-server.xml in our case) file. Then they can >>>>> be referenced in webapp via linking them in the context.xml file of >>>>> webapp. >>>>> >>>>> Eg - <ResourceLink name="jdbc/MyDataSource" >>>>> global="jdbc/MyDataSource" >>>>> type="com.atomikos.jdbc.AtomikosDataSourceBean"/> >>>>> >>>>> If it is per webapp, then they can be registered by placing them in >>>>> the context.xml file of the webapp it self. >>>>> >>>>> Eg - <Resource name="TransactionManager" auth="Container" >>>>> type="com.atomikos.icatch.jta.UserTransactionManager" >>>>> factory="org.apache.naming.factory.BeanFactory" /> >>>>> >>>>> Other properties for these resources should go inside each respective >>>>> Resource tags. Make sure those classes used to define resource-type are in >>>>> the classpath. Then have a reference for those resources in the web.xml of >>>>> the webapp. >>>>> >>>>> Eg - <resource-ref> >>>>> <description>Your Description</description> >>>>> <res-ref-name>jdbc/MyDataSource</res-ref-name> >>>>> <res-type>com.atomikos.jdbc.AtomikosDataSourceBean</res-type> >>>>> <res-auth>Container</res-auth> >>>>> </resource-ref> >>>>> >>>>> I'm currently writing an article on recent tomcat improvements, so >>>>> it's better to include these details in there as-well. >>>>> >>>>> Thanks, >>>>> Kishanthan. >>>>> Ref - >>>>> http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html >>>>> >>>>> On Mon, May 28, 2012 at 3:55 PM, Kishanthan Thangarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, May 28, 2012 at 2:51 PM, Isuru Suriarachchi >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, May 28, 2012 at 2:45 PM, Paul Fremantle <[email protected]>wrote: >>>>>>> >>>>>>>> If that is the way its "meant" to work, then we need a way to >>>>>>>> register things like DataSources and Transaction context into the >>>>>>>> webapps >>>>>>>> JNDI. >>>>>>>> >>>>>>>> There is some good docs on how this works in Tomcat here: >>>>>>>> >>>>>>>> http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#context.xml_configuration >>>>>>>> >>>>>>>> In Tomcat it seems you can define JNDI entries either locally in >>>>>>>> the web.xml or globally and then "link" to them. >>>>>>>> >>>>>>> >>>>>>> +1. This should work for us and looks like it's the correct way of >>>>>>> doing this. Kishanthan, please look into this.. >>>>>>> >>>>>> >>>>>> I will have a look at this and provide an update. Created a jira to >>>>>> track this [1]. >>>>>> >>>>>> Kishanthan. >>>>>> [1] https://wso2.org/jira/browse/CARBON-13277 >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> ~Isuru >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>> >>>>>>>> On 28 May 2012 10:03, Isuru Suriarachchi <[email protected]> wrote: >>>>>>>> >>>>>>>>> I had a discussion on this with Kicha and looks like the way it >>>>>>>>> works is correct. When jndi resources are registered in the webapp >>>>>>>>> itself, >>>>>>>>> those get registered in it's own context and can be loaded anywhere >>>>>>>>> within >>>>>>>>> the webapp. But when resources are registered in the initial context, >>>>>>>>> those >>>>>>>>> are not visible to the webapps. Looks like this is the correct >>>>>>>>> behavior. >>>>>>>>> >>>>>>>>> Can we please check whether this webapp works in previous >>>>>>>>> releases? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> ~Isuru >>>>>>>>> >>>>>>>>> On Mon, May 28, 2012 at 1:00 PM, Kishanthan Thangarajah < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Here are the findings on this issue so far. >>>>>>>>>> >>>>>>>>>> In trunk, TransactionManager, UserTransaction etc, are getting >>>>>>>>>> bind with InitialContext of javaUrlContextFactory[1] which handles >>>>>>>>>> the >>>>>>>>>> “java:” namespace. This context is not bound to any thread or >>>>>>>>>> classloader. >>>>>>>>>> But in a webapp case, their context are isolated from each other and >>>>>>>>>> the >>>>>>>>>> classloaders are bound to each webapps naming context. But the >>>>>>>>>> initialContext from javaUrlContextFactory will not be accessible for >>>>>>>>>> them. >>>>>>>>>> This is why it fails when doing lookup within a webapp. >>>>>>>>>> >>>>>>>>>> The javaUrlContextFactory first checks whether current thread or >>>>>>>>>> classloader is bound to any context. If not, it will return the >>>>>>>>>> intialContext. This is why the lookup within a service is successful >>>>>>>>>> since >>>>>>>>>> its class loader is not bound to any naming context. The lookup from >>>>>>>>>> any BE >>>>>>>>>> component also works fine. >>>>>>>>>> >>>>>>>>>> So we have to think of a way to handle this issue. >>>>>>>>>> >>>>>>>>>> @Dinusha, can you try whether this webapp works in previous >>>>>>>>>> releases? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Kishanthan. >>>>>>>>>> [1] >>>>>>>>>> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.26/org/apache/naming/java/javaURLContextFactory.java#javaURLContextFactory.getInitialContext%28java.util.Hashtable%29 >>>>>>>>>> >>>>>>>>>> On Sun, May 27, 2012 at 11:47 AM, Dinusha Senanayaka < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Kishanthan, >>>>>>>>>>> >>>>>>>>>>> On Sun, May 27, 2012 at 12:07 AM, Kishanthan Thangarajah < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sat, May 26, 2012 at 3:05 PM, Dinusha Senanayaka < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Kishanthan, >>>>>>>>>>>>> >>>>>>>>>>>>> The way you suggested also didn't work for me. I guess, in >>>>>>>>>>>>> your sample wep-app, JNDI lookup has done for some data-source >>>>>>>>>>>>> created >>>>>>>>>>>>> within Tomcat itself. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Can you share the webapp? I'll have a look into this. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please find the attached web-app. It refers to the >>>>>>>>>>> transaction-manager, which has bind with JNDI, while >>>>>>>>>>> transaction-manger >>>>>>>>>>> bundle get start in carbon sever. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Dinusha. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Kishanthan. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Dinusha. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, May 26, 2012 at 12:50 PM, Supun Malinga < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Kishanthan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any idea why 'normal' jndi lookup doesn't work? >>>>>>>>>>>>>> If I'm a user and want to do some jndi lookup insid ea webapp >>>>>>>>>>>>>> I would follow the standard way. If that's not going to work I >>>>>>>>>>>>>> think we >>>>>>>>>>>>>> better at least document this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, May 26, 2012 at 11:31 AM, Kishanthan Thangarajah < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> This was one the issue I encountered when trying to write >>>>>>>>>>>>>>> some webapps with webapp specific contextXml configuration >>>>>>>>>>>>>>> where I store >>>>>>>>>>>>>>> some JNDI resources in it. Normal lookup is as follow, which >>>>>>>>>>>>>>> gives the >>>>>>>>>>>>>>> exception when trying within a webapp, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Context initCtx = new InitialContext(); >>>>>>>>>>>>>>> Context envCtx = (Context) >>>>>>>>>>>>>>> initCtx.lookup("java:comp/env"); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But after some debugging at tomcat code level, I found a way >>>>>>>>>>>>>>> to overcome this. We have to use the catalina jndi context >>>>>>>>>>>>>>> implementation. >>>>>>>>>>>>>>> Let me give some insight. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Context initCtx = new InitialContext(); >>>>>>>>>>>>>>> SelectorContext selectorContext = new >>>>>>>>>>>>>>> SelectorContext((Hashtable<String, Object>) >>>>>>>>>>>>>>> initCtx.getEnvironment(), >>>>>>>>>>>>>>> false); >>>>>>>>>>>>>>> Context envCtx = (Context) >>>>>>>>>>>>>>> selectorContext.lookup("java:comp/env"); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here the SelectorContext is the Catalina JNDI Context >>>>>>>>>>>>>>> implementation. First using the IntialContext environment we >>>>>>>>>>>>>>> have to build >>>>>>>>>>>>>>> the Catalina selector context, and then we can lookup from >>>>>>>>>>>>>>> that. Can you >>>>>>>>>>>>>>> please try this and let me know if it fails? You can take a >>>>>>>>>>>>>>> look at the >>>>>>>>>>>>>>> webapp samples here [1]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Kishanthan. >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/products/as/modules/samples/product/TomcatWebApps/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, May 25, 2012 at 5:45 PM, Dinusha Senanayaka < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have registered a object with JNDI and try to access it >>>>>>>>>>>>>>>> within a web-app. But JNDI lookup get fails saying >>>>>>>>>>>>>>>> "javax.naming.NameNotFoundException: Name >>>>>>>>>>>>>>>> [java:comp/TransactionManager] is >>>>>>>>>>>>>>>> not bound in this Context. Unable to find [java:comp]". Even >>>>>>>>>>>>>>>> I tried to >>>>>>>>>>>>>>>> lookup a Carbon JNDI data-source, it also fails by giving >>>>>>>>>>>>>>>> similar type >>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But same JNDI lookups work inside a Axis2 service(AAR). Any >>>>>>>>>>>>>>>> idea why this can be happened ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Dinusha. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Dev mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> *Kishanthan Thangarajah* >>>>>>>>>>>>>>> Software Engineer, >>>>>>>>>>>>>>> Development Technologies Team, >>>>>>>>>>>>>>> WSO2, Inc. >>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mobile - +94773426635 >>>>>>>>>>>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>>>>>>>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Dev mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Supun Malinga, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Software Engineer, >>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>> http://wso2.com >>>>>>>>>>>>>> http://wso2.org >>>>>>>>>>>>>> email - [email protected] <[email protected]> >>>>>>>>>>>>>> mobile - 071 56 91 321 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Kishanthan Thangarajah* >>>>>>>>>>>> Software Engineer, >>>>>>>>>>>> Development Technologies Team, >>>>>>>>>>>> WSO2, Inc. >>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>> >>>>>>>>>>>> Mobile - +94773426635 >>>>>>>>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>>>>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Kishanthan Thangarajah* >>>>>>>>>> Software Engineer, >>>>>>>>>> Development Technologies Team, >>>>>>>>>> WSO2, Inc. >>>>>>>>>> lean.enterprise.middleware >>>>>>>>>> >>>>>>>>>> Mobile - +94773426635 >>>>>>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Isuru Suriarachchi >>>>>>>>> Senior Technical Lead >>>>>>>>> WSO2 Inc. http://wso2.com >>>>>>>>> email : [email protected] >>>>>>>>> blog : http://isurues.wordpress.com/ >>>>>>>>> >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Dev mailing list >>>>>>>>> [email protected] >>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Paul Fremantle >>>>>>>> CTO and Co-Founder, WSO2 >>>>>>>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >>>>>>>> >>>>>>>> UK: +44 207 096 0336 >>>>>>>> US: +1 646 595 7614 >>>>>>>> >>>>>>>> blog: http://pzf.fremantle.org >>>>>>>> twitter.com/pzfreo >>>>>>>> [email protected] >>>>>>>> >>>>>>>> wso2.com Lean Enterprise Middleware >>>>>>>> >>>>>>>> Disclaimer: This communication may contain privileged or other >>>>>>>> confidential information and is intended exclusively for the >>>>>>>> addressee/s. >>>>>>>> If you are not the intended recipient/s, or believe that you may have >>>>>>>> received this communication in error, please reply to the sender >>>>>>>> indicating >>>>>>>> that fact and delete the copy you received and in addition, you should >>>>>>>> not >>>>>>>> print, copy, retransmit, disseminate, or otherwise use the information >>>>>>>> contained in this communication. Internet communications cannot be >>>>>>>> guaranteed to be timely, secure, error or virus-free. The sender does >>>>>>>> not >>>>>>>> accept liability for any errors or omissions. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Isuru Suriarachchi >>>>>>> Senior Technical Lead >>>>>>> WSO2 Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> blog : http://isurues.wordpress.com/ >>>>>>> >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Kishanthan Thangarajah* >>>>>> Software Engineer, >>>>>> Development Technologies Team, >>>>>> WSO2, Inc. >>>>>> lean.enterprise.middleware >>>>>> >>>>>> Mobile - +94773426635 >>>>>> Blog - *http://kishanthan.wordpress.com* >>>>>> Twitter - *http://twitter.com/kishanthan* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Kishanthan Thangarajah* >>>>> Software Engineer, >>>>> Development Technologies Team, >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - +94773426635 >>>>> Blog - *http://kishanthan.wordpress.com* >>>>> Twitter - *http://twitter.com/kishanthan* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Isuru Suriarachchi >>>> Senior Technical Lead >>>> WSO2 Inc. http://wso2.com >>>> email : [email protected] >>>> blog : http://isurues.wordpress.com/ >>>> >>>> lean . enterprise . middleware >>>> >>>> >>> >> >> >> -- >> *Kishanthan Thangarajah* >> Software Engineer, >> Development Technologies Team, >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - +94773426635 >> Blog - *http://kishanthan.wordpress.com* >> Twitter - *http://twitter.com/kishanthan* >> >> > -- Isuru Suriarachchi Senior Technical Lead WSO2 Inc. http://wso2.com email : [email protected] blog : http://isurues.wordpress.com/ lean . enterprise . middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
