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*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
