webapp spring roots

[Fernando Padilla]

I want to run my webapp through tomcat, jetty and mvn jetty:run, but
when I did, I noticed that terracotta was generating unique roots for
different ways that I launch the web application; and for each different
context path that I launch my webapp under.. ( so developers can't share
roots )

This is very disappointing.  How can I get this working?


-------

tc:spring_info.appName is coming up with different things:

fbracket
Jetty.path=/fbracket
Jetty.path=/fannetwork

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Eugene Kuleshov-6]

Hi Fernando,

  By default Terracotta for Spring is naming those roots using synthetic
name derived from the matching web application name and matching spring
config names. There is a FAQ entry about that in the "Troubleshooting
Guide" linked from the on Terracotta home page. See
https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#TroubleshootingGuide-TerracottaforSpring...

  So you can override that root name in your tc-config.xml using
<root-name> element:

...
<application>
   <spring>
     <jee-application>
       <application-contexts>
         <application-context>
           <root-name>myClusteredSpringContext</root-name>
             ...

  regards,
  Eugene Kuleshov

PS: it feels like I am the only one answering all the questions today,
but by strange coincidence those happens to be from my area of expertise


Fernando Padilla wrote:

> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
> when I did, I noticed that terracotta was generating unique roots for
> different ways that I launch the web application; and for each different
> context path that I launch my webapp under.. ( so developers can't share
> roots )
>
> This is very disappointing.  How can I get this working?
>
> -------
> tc:spring_info.appName is coming up with different things:
>
> fbracket
> Jetty.path=/fbracket
> Jetty.path=/fannetwork
>  

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Fernando Padilla]

I did as you suggested.  I loaded the app under tomcat, and it works as
usual.  Then I shutdown tomcat and ran it under jetty and got this
exception:

7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
registering transient fields for tc-cache-map-factory
com.protrade.common.cache.CacheFactory
com.tc.exception.TCClassNotFoundException:
java.lang.ClassNotFoundException: No registered loader for description:
Tomcat.Catalina:localhost:/fbracket, trying to load
com.tcspring.ComplexBeanId
         at
com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManagerImpl.java:600)
         at
com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287)
         at
com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266)
         at
com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130)
         at
com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOrCreateRoot(DistributableBeanFactoryMixin.java:419)
         at
com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(DistributableBeanFactoryMixin.java:221)
         at
org.springframework.beans.factory.support.AbstractBeanFactory.registerBeanDefinitions(AbstractBeanFactory.java)
....
...




Eugene Kuleshov wrote:

> Hi Fernando,
>
>   By default Terracotta for Spring is naming those roots using synthetic
> name derived from the matching web application name and matching spring
> config names. There is a FAQ entry about that in the "Troubleshooting
> Guide" linked from the on Terracotta home page. See
> https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#TroubleshootingGuide-TerracottaforSpring...
>
>   So you can override that root name in your tc-config.xml using
> <root-name> element:
>
> ...
> <application>
>    <spring>
>      <jee-application>
>        <application-contexts>
>          <application-context>
>            <root-name>myClusteredSpringContext</root-name>
>              ...
>
>   regards,
>   Eugene Kuleshov
>
> PS: it feels like I am the only one answering all the questions today,
> but by strange coincidence those happens to be from my area of expertise
>
>
> Fernando Padilla wrote:
>> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
>> when I did, I noticed that terracotta was generating unique roots for
>> different ways that I launch the web application; and for each different
>> context path that I launch my webapp under.. ( so developers can't share
>> roots )
>>
>> This is very disappointing.  How can I get this working?
>>
>> -------
>> tc:spring_info.appName is coming up with different things:
>>
>> fbracket
>> Jetty.path=/fbracket
>> Jetty.path=/fannetwork
>>  
>
>
>
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Fernando Padilla]

attached is my tc-config.xml


Fernando Padilla wrote:

> I did as you suggested.  I loaded the app under tomcat, and it works as
> usual.  Then I shutdown tomcat and ran it under jetty and got this
> exception:
>
> 7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
> registering transient fields for tc-cache-map-factory
> com.protrade.common.cache.CacheFactory
> com.tc.exception.TCClassNotFoundException:
> java.lang.ClassNotFoundException: No registered loader for description:
> Tomcat.Catalina:localhost:/fbracket, trying to load
> com.tcspring.ComplexBeanId
>          at
> com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManagerImpl.java:600)
>          at
> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287)
>          at
> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266)
>          at
> com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130)
>          at
> com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOrCreateRoot(DistributableBeanFactoryMixin.java:419)
>          at
> com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(DistributableBeanFactoryMixin.java:221)
>          at
> org.springframework.beans.factory.support.AbstractBeanFactory.registerBeanDefinitions(AbstractBeanFactory.java)
> ....
> ...
>
>
>
>
> Eugene Kuleshov wrote:
>> Hi Fernando,
>>
>>   By default Terracotta for Spring is naming those roots using synthetic
>> name derived from the matching web application name and matching spring
>> config names. There is a FAQ entry about that in the "Troubleshooting
>> Guide" linked from the on Terracotta home page. See
>> https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#TroubleshootingGuide-TerracottaforSpring...
>>
>>   So you can override that root name in your tc-config.xml using
>> <root-name> element:
>>
>> ...
>> <application>
>>    <spring>
>>      <jee-application>
>>        <application-contexts>
>>          <application-context>
>>            <root-name>myClusteredSpringContext</root-name>
>>              ...
>>
>>   regards,
>>   Eugene Kuleshov
>>
>> PS: it feels like I am the only one answering all the questions today,
>> but by strange coincidence those happens to be from my area of expertise
>>
>>
>> Fernando Padilla wrote:
>>> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
>>> when I did, I noticed that terracotta was generating unique roots for
>>> different ways that I launch the web application; and for each different
>>> context path that I launch my webapp under.. ( so developers can't share
>>> roots )
>>>
>>> This is very disappointing.  How can I get this working?
>>>
>>> -------
>>> tc:spring_info.appName is coming up with different things:
>>>
>>> fbracket
>>> Jetty.path=/fbracket
>>> Jetty.path=/fannetwork
>>>  
>>
>>
>> _______________________________________________
>> tc-users mailing list
>> tc-users@...
>> http://lists.terracotta.org/mailman/listinfo/tc-users
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users

<?xml version="1.0" encoding="UTF-8" ?>
<tc:tc-config xmlns:tc="http://www.terracotta.org/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-4.xsd">

  <!-- Tell DSO where the Terracotta server can be found. -->
  <servers>
    <server host="%h">
      <data>%(user.home)/terracotta/server-data</data>
      <logs>%(user.home)/terracotta/server-logs</logs>
<!--
      <dso>
        <persistence>permanent-store</persistence>
      </dso>
-->
    </server>
  </servers>

  <!-- Tell DSO where to put the generated client logs -->  
  <clients>
    <logs>%(user.home)/terracotta/client-logs</logs>
    <modules>
      <module name="clustered-commons-collections-3.1" version="2.5.2"/>
      <module name="clustered-jetty-6.1" version="2.5.2"/>
    </modules>
  </clients>

  <application>
    <spring>

      <!-- The JEE application name is in most cases the name of the WAR, EAR
           or JAR file in which the Spring application resides. If you are
           using Spring in a stand-alone application then you can use "*" as
           the name. The pattern matching supports wildcards of leading and
           ending asterisk (*), which matches an arbitrary number of
           characters. -->
      <jee-application name="*">

        <!-- Turns on clustering of the HTTP session. Needed for f.e. Spring
             WebFlow clustering. -->
        <session-support>false</session-support>

        <application-contexts>
          <application-context>
            <root-name>ptAppsRoot</root-name>

            <!-- Specifies the bean definition resource patterns; The matching
                 applys OR logic for individual path element. -->
            <paths>
              <path>common-conf-props.xml</path>
              <path>terracotta-on-conf.xml</path>
            </paths>

            <!-- Specifies the Spring beans to cluster/share; The bean name
                 should be the same name that the bean has in the Spring bean
                 config file. Matching has to be exact; -->
            <beans>
              <bean name="tc-cache-map-factory"/>
              <bean name="tc-kodo-data-cache-mapfactory"/>
              <bean name="tc-kodo-query-cache-mapfactory"/>
              <bean name="tc-lockCache"/>
            </beans>

          </application-context>
        </application-contexts>

      </jee-application>
    </spring>
    <dso>
      <roots>
        <root>
          <field-name>com.protrade.terracotta.MasterRoot.masterRoot</field-name>
          <root-name>masterRoot</root-name>
        </root>
      </roots>
        <instrumented-classes>
<!-- master-root -->
          <include>
            <class-expression>com.protrade.terracotta.MasterRoot</class-expression>
          </include>

<!-- base -->
          <include>
            <class-expression>com.protrade.common.base.BaseObject</class-expression>
          </include>
          <include>
            <class-expression>org.apache.commons.collections.map.LazyMap</class-expression>
          </include>
          <include>
            <class-expression>org.apache.commons.collections.map.AbstractMapDecorator</class-expression>
          </include>
          <include>
            <class-expression>org.apache.commons.collections.functors.FactoryTransformer</class-expression>
          </include>
          <include>
            <class-expression>com.protrade.common.cache.CacheFactory$1</class-expression>
          </include>
          <include>
            <class-expression>com.protrade.common.util.LockCache$1</class-expression>
          </include>
 
<!-- kodo -->
          <include>
            <class-expression>kodo.util.Id</class-expression>
          </include>
          <include>
            <class-expression>kodo.datacache.DataCachePCDataImpl</class-expression>
          </include>
          <include>
            <class-expression>kodo.runtime.PCDataImpl</class-expression>
          </include>
          <include>
            <class-expression>kodo.runtime.AbstractPCData</class-expression>
          </include>
          <include>
            <class-expression>com.protrade.common.cache.MapDataCache$1</class-expression>
          </include>
          <include>
            <class-expression>com.protrade.common.cache.MapQueryCache$1</class-expression>
          </include>
 
<!-- protrade id -->
          <include>
            <class-expression>com.protrade.common.persistence.ProtradeId+</class-expression>
          </include>

<!-- buffer -->
          <include>
            <class-expression>com.protrade.tapestry5.base.services.BufferServices$CacheValue</class-expression>
          </include>
          <include>
            <class-expression>com.protrade.tapestry5.base.services.BufferServices$BufferValue</class-expression>
          </include>
        </instrumented-classes>

        <locks>
<!-- kodo -->
          <autolock>
            <method-expression>* kodo.datacache.DataCachePCDataImpl.get*(..)</method-expression>
            <lock-level>read</lock-level>
          </autolock>
          <autolock>
            <method-expression>* kodo.datacache.DataCachePCDataImpl.is*(..)</method-expression>
            <lock-level>read</lock-level>
          </autolock>
          <autolock>
            <method-expression>* kodo.datacache.DataCachePCDataImpl.load*(..)</method-expression>
            <lock-level>write</lock-level>
          </autolock>
          <autolock>
            <method-expression>* kodo.datacache.DataCachePCDataImpl.set*(..)</method-expression>
            <lock-level>write</lock-level>
          </autolock>
          <autolock>
            <method-expression>* kodo.datacache.DataCachePCDataImpl.store*(..)</method-expression>
            <lock-level>write</lock-level>
          </autolock>
        </locks>
    </dso>

  </application>

</tc:tc-config>

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Tim Eck]

I apologize I haven't been following every message in this conversation,
but this looks like a known limitation in terracotta. Every object that is
clustered carries information that describes which class loader created
(such that we can locate the same logical loader on other nodes). This
makes for issue fore sharing between different app servers (or an app
server and a standalone vanilla java process for that matter).

There a few workarounds, but nothing too pretty really. One is to use a
class loader that is guaranteed to be available on both VMs (ie.
CLASSPATH).

One thing we've thought about doing (but is yet to be implemented) is to
name web application class loaders in the same manner no matter which app
server is being used. This would probably enable your use case to work
(assuming you're using the same context paths on both jetty and tomcat)

> -----Original Message-----
> From: tc-users-bounces@... [mailto:tc-users-
> bounces@...] On Behalf Of Fernando Padilla
> Sent: Tuesday, February 26, 2008 2:10 PM
> To: tc-users@...
> Subject: Re: [tc-users] webapp spring roots
>
> I did as you suggested.  I loaded the app under tomcat, and it works as
> usual.  Then I shutdown tomcat and ran it under jetty and got this
> exception:
>
> 7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
> registering transient fields for tc-cache-map-factory
> com.protrade.common.cache.CacheFactory
> com.tc.exception.TCClassNotFoundException:
> java.lang.ClassNotFoundException: No registered loader for description:
> Tomcat.Catalina:localhost:/fbracket, trying to load
> com.tcspring.ComplexBeanId
>          at
>

com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManag
> erImpl.java:600)
>          at
>
com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287
> )
>          at
>
com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266
> )
>          at
>
com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130
> )
>          at
>
com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOr
> CreateRoot(DistributableBeanFactoryMixin.java:419)
>          at
>
com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(Distrib
> utableBeanFactoryMixin.java:221)
>          at
>
org.springframework.beans.factory.support.AbstractBeanFactory.registerBean

> Definitions(AbstractBeanFactory.java)
> ....
> ...
>
>
>
>
> Eugene Kuleshov wrote:
> > Hi Fernando,
> >
> >   By default Terracotta for Spring is naming those roots using

synthetic
> > name derived from the matching web application name and matching
spring
> > config names. There is a FAQ entry about that in the "Troubleshooting
> > Guide" linked from the on Terracotta home page. See
> >
>
https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#Troub

> leshootingGuide-TerracottaforSpring...
> >
> >   So you can override that root name in your tc-config.xml using
> > <root-name> element:
> >
> > ...
> > <application>
> >    <spring>
> >      <jee-application>
> >        <application-contexts>
> >          <application-context>
> >            <root-name>myClusteredSpringContext</root-name>
> >              ...
> >
> >   regards,
> >   Eugene Kuleshov
> >
> > PS: it feels like I am the only one answering all the questions today,
> > but by strange coincidence those happens to be from my area of

expertise

> >
> >
> > Fernando Padilla wrote:
> >> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
> >> when I did, I noticed that terracotta was generating unique roots for
> >> different ways that I launch the web application; and for each
> different
> >> context path that I launch my webapp under.. ( so developers can't
> share
> >> roots )
> >>
> >> This is very disappointing.  How can I get this working?
> >>
> >> -------
> >> tc:spring_info.appName is coming up with different things:
> >>
> >> fbracket
> >> Jetty.path=/fbracket
> >> Jetty.path=/fannetwork
> >>
> >
> >
> >
> > _______________________________________________
> > tc-users mailing list
> > tc-users@...
> > http://lists.terracotta.org/mailman/listinfo/tc-users
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Fernando Padilla]

This is disappointing.  So I might be a little miffed, since I was so
close to properly test and roll out terracotta, but there seem to be
hacks and obstacles on every step.


So what is the point of having the "same logical classloader", when I
already told you that they are the "same logical root"?

So do you guys have any plans on fixing this? eta?

The whole selling point of terracotta is supposed to be the mythical
"zero modification", having to hack up my classloader configurations on
each server doesn't match up with that..

and by the way, I want you to support the option where different
"context roots" can still map to the same root object please!  Each of
our developers usually have different context roots, but they might
share the same database ( thus the same database cache ).



Tim Eck wrote:

> I apologize I haven't been following every message in this conversation,
> but this looks like a known limitation in terracotta. Every object that is
> clustered carries information that describes which class loader created
> (such that we can locate the same logical loader on other nodes). This
> makes for issue fore sharing between different app servers (or an app
> server and a standalone vanilla java process for that matter).
>
> There a few workarounds, but nothing too pretty really. One is to use a
> class loader that is guaranteed to be available on both VMs (ie.
> CLASSPATH).
>
> One thing we've thought about doing (but is yet to be implemented) is to
> name web application class loaders in the same manner no matter which app
> server is being used. This would probably enable your use case to work
> (assuming you're using the same context paths on both jetty and tomcat)
>
>> -----Original Message-----
>> From: tc-users-bounces@... [mailto:tc-users-
>> bounces@...] On Behalf Of Fernando Padilla
>> Sent: Tuesday, February 26, 2008 2:10 PM
>> To: tc-users@...
>> Subject: Re: [tc-users] webapp spring roots
>>
>> I did as you suggested.  I loaded the app under tomcat, and it works as
>> usual.  Then I shutdown tomcat and ran it under jetty and got this
>> exception:
>>
>> 7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
>> registering transient fields for tc-cache-map-factory
>> com.protrade.common.cache.CacheFactory
>> com.tc.exception.TCClassNotFoundException:
>> java.lang.ClassNotFoundException: No registered loader for description:
>> Tomcat.Catalina:localhost:/fbracket, trying to load
>> com.tcspring.ComplexBeanId
>>          at
>>
> com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManag
>> erImpl.java:600)
>>          at
>>
> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287
>> )
>>          at
>>
> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266
>> )
>>          at
>>
> com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130
>> )
>>          at
>>
> com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOr
>> CreateRoot(DistributableBeanFactoryMixin.java:419)
>>          at
>>
> com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(Distrib
>> utableBeanFactoryMixin.java:221)
>>          at
>>
> org.springframework.beans.factory.support.AbstractBeanFactory.registerBean
>> Definitions(AbstractBeanFactory.java)
>> ....
>> ...
>>
>>
>>
>>
>> Eugene Kuleshov wrote:
>>> Hi Fernando,
>>>
>>>   By default Terracotta for Spring is naming those roots using
> synthetic
>>> name derived from the matching web application name and matching
> spring
>>> config names. There is a FAQ entry about that in the "Troubleshooting
>>> Guide" linked from the on Terracotta home page. See
>>>
> https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#Troub
>> leshootingGuide-TerracottaforSpring...
>>>   So you can override that root name in your tc-config.xml using
>>> <root-name> element:
>>>
>>> ...
>>> <application>
>>>    <spring>
>>>      <jee-application>
>>>        <application-contexts>
>>>          <application-context>
>>>            <root-name>myClusteredSpringContext</root-name>
>>>              ...
>>>
>>>   regards,
>>>   Eugene Kuleshov
>>>
>>> PS: it feels like I am the only one answering all the questions today,
>>> but by strange coincidence those happens to be from my area of
> expertise
>>>
>>> Fernando Padilla wrote:
>>>> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
>>>> when I did, I noticed that terracotta was generating unique roots for
>>>> different ways that I launch the web application; and for each
>> different
>>>> context path that I launch my webapp under.. ( so developers can't
>> share
>>>> roots )
>>>>
>>>> This is very disappointing.  How can I get this working?
>>>>
>>>> -------
>>>> tc:spring_info.appName is coming up with different things:
>>>>
>>>> fbracket
>>>> Jetty.path=/fbracket
>>>> Jetty.path=/fannetwork
>>>>
>>>
>>>
>>> _______________________________________________
>>> tc-users mailing list
>>> tc-users@...
>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>> _______________________________________________
>> tc-users mailing list
>> tc-users@...
>> http://lists.terracotta.org/mailman/listinfo/tc-users
>
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Fernando Padilla]

actually.  multiple context roots sharing the same dso root is a
requirement for production as well!!

we have many different web applications all sharing different databases,
which we want to use terracotta to implement the shared database cache.

this is a no go for terracotta :( :( :( :(

please help :) :) :)


Fernando Padilla wrote:

> This is disappointing.  So I might be a little miffed, since I was so
> close to properly test and roll out terracotta, but there seem to be
> hacks and obstacles on every step.
>
>
> So what is the point of having the "same logical classloader", when I
> already told you that they are the "same logical root"?
>
> So do you guys have any plans on fixing this? eta?
>
> The whole selling point of terracotta is supposed to be the mythical
> "zero modification", having to hack up my classloader configurations on
> each server doesn't match up with that..
>
> and by the way, I want you to support the option where different
> "context roots" can still map to the same root object please!  Each of
> our developers usually have different context roots, but they might
> share the same database ( thus the same database cache ).
>
>
>
> Tim Eck wrote:
>> I apologize I haven't been following every message in this conversation,
>> but this looks like a known limitation in terracotta. Every object that is
>> clustered carries information that describes which class loader created
>> (such that we can locate the same logical loader on other nodes). This
>> makes for issue fore sharing between different app servers (or an app
>> server and a standalone vanilla java process for that matter).
>>
>> There a few workarounds, but nothing too pretty really. One is to use a
>> class loader that is guaranteed to be available on both VMs (ie.
>> CLASSPATH).
>>
>> One thing we've thought about doing (but is yet to be implemented) is to
>> name web application class loaders in the same manner no matter which app
>> server is being used. This would probably enable your use case to work
>> (assuming you're using the same context paths on both jetty and tomcat)
>>
>>> -----Original Message-----
>>> From: tc-users-bounces@... [mailto:tc-users-
>>> bounces@...] On Behalf Of Fernando Padilla
>>> Sent: Tuesday, February 26, 2008 2:10 PM
>>> To: tc-users@...
>>> Subject: Re: [tc-users] webapp spring roots
>>>
>>> I did as you suggested.  I loaded the app under tomcat, and it works as
>>> usual.  Then I shutdown tomcat and ran it under jetty and got this
>>> exception:
>>>
>>> 7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
>>> registering transient fields for tc-cache-map-factory
>>> com.protrade.common.cache.CacheFactory
>>> com.tc.exception.TCClassNotFoundException:
>>> java.lang.ClassNotFoundException: No registered loader for description:
>>> Tomcat.Catalina:localhost:/fbracket, trying to load
>>> com.tcspring.ComplexBeanId
>>>          at
>>>
>> com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManag
>>> erImpl.java:600)
>>>          at
>>>
>> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287
>>> )
>>>          at
>>>
>> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266
>>> )
>>>          at
>>>
>> com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130
>>> )
>>>          at
>>>
>> com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOr
>>> CreateRoot(DistributableBeanFactoryMixin.java:419)
>>>          at
>>>
>> com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(Distrib
>>> utableBeanFactoryMixin.java:221)
>>>          at
>>>
>> org.springframework.beans.factory.support.AbstractBeanFactory.registerBean
>>> Definitions(AbstractBeanFactory.java)
>>> ....
>>> ...
>>>
>>>
>>>
>>>
>>> Eugene Kuleshov wrote:
>>>> Hi Fernando,
>>>>
>>>>   By default Terracotta for Spring is naming those roots using
>> synthetic
>>>> name derived from the matching web application name and matching
>> spring
>>>> config names. There is a FAQ entry about that in the "Troubleshooting
>>>> Guide" linked from the on Terracotta home page. See
>>>>
>> https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#Troub
>>> leshootingGuide-TerracottaforSpring...
>>>>   So you can override that root name in your tc-config.xml using
>>>> <root-name> element:
>>>>
>>>> ...
>>>> <application>
>>>>    <spring>
>>>>      <jee-application>
>>>>        <application-contexts>
>>>>          <application-context>
>>>>            <root-name>myClusteredSpringContext</root-name>
>>>>              ...
>>>>
>>>>   regards,
>>>>   Eugene Kuleshov
>>>>
>>>> PS: it feels like I am the only one answering all the questions today,
>>>> but by strange coincidence those happens to be from my area of
>> expertise
>>>> Fernando Padilla wrote:
>>>>> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
>>>>> when I did, I noticed that terracotta was generating unique roots for
>>>>> different ways that I launch the web application; and for each
>>> different
>>>>> context path that I launch my webapp under.. ( so developers can't
>>> share
>>>>> roots )
>>>>>
>>>>> This is very disappointing.  How can I get this working?
>>>>>
>>>>> -------
>>>>> tc:spring_info.appName is coming up with different things:
>>>>>
>>>>> fbracket
>>>>> Jetty.path=/fbracket
>>>>> Jetty.path=/fannetwork
>>>>>
>>>>
>>>> _______________________________________________
>>>> tc-users mailing list
>>>> tc-users@...
>>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>>> _______________________________________________
>>> tc-users mailing list
>>> tc-users@...
>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>> _______________________________________________
>> tc-users mailing list
>> tc-users@...
>> http://lists.terracotta.org/mailman/listinfo/tc-users
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Eugene Kuleshov-6]

Fernando,

  Can you please clarify the following questions:

- is your production environment is using mixture of application servers
that need to share the same data?
- do you have requirement to share the same data between different web
applications?

  For the second scenario, assuming that there is a common jar contain
classes used for that shared data, the work around is to put that jar
into a shared or common class loader or Tomcat (i.e. deploy it outside
of your web applications, which would give additional memory benefits if
more then one web application on the same server is using those
classes). Those classloaders will have the same names across Terracotta
clister, when all clustered web apps are running on Tomcat. See [1] for
more details about Tomcat classloaders.

  regards,
  Eugene

[1] http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html


Fernando Padilla wrote:

> actually.  multiple context roots sharing the same dso root is a
> requirement for production as well!!
>
> we have many different web applications all sharing different databases,
> which we want to use terracotta to implement the shared database cache.
>
> this is a no go for terracotta :( :( :( :(
>
> please help :) :) :)
>
>
> Fernando Padilla wrote:
>  
>> This is disappointing.  So I might be a little miffed, since I was so
>> close to properly test and roll out terracotta, but there seem to be
>> hacks and obstacles on every step.
>>
>>
>> So what is the point of having the "same logical classloader", when I
>> already told you that they are the "same logical root"?
>>
>> So do you guys have any plans on fixing this? eta?
>>
>> The whole selling point of terracotta is supposed to be the mythical
>> "zero modification", having to hack up my classloader configurations on
>> each server doesn't match up with that..
>>
>> and by the way, I want you to support the option where different
>> "context roots" can still map to the same root object please!  Each of
>> our developers usually have different context roots, but they might
>> share the same database ( thus the same database cache ).
>>
>>
>>
>> Tim Eck wrote:
>>    
>>> I apologize I haven't been following every message in this conversation,
>>> but this looks like a known limitation in terracotta. Every object that is
>>> clustered carries information that describes which class loader created
>>> (such that we can locate the same logical loader on other nodes). This
>>> makes for issue fore sharing between different app servers (or an app
>>> server and a standalone vanilla java process for that matter).
>>>
>>> There a few workarounds, but nothing too pretty really. One is to use a
>>> class loader that is guaranteed to be available on both VMs (ie.
>>> CLASSPATH).
>>>
>>> One thing we've thought about doing (but is yet to be implemented) is to
>>> name web application class loaders in the same manner no matter which app
>>> server is being used. This would probably enable your use case to work
>>> (assuming you're using the same context paths on both jetty and tomcat)
>>>
>>>      
>>>> -----Original Message-----
>>>> From: tc-users-bounces@... [mailto:tc-users-
>>>> bounces@...] On Behalf Of Fernando Padilla
>>>> Sent: Tuesday, February 26, 2008 2:10 PM
>>>> To: tc-users@...
>>>> Subject: Re: [tc-users] webapp spring roots
>>>>
>>>> I did as you suggested.  I loaded the app under tomcat, and it works as
>>>> usual.  Then I shutdown tomcat and ran it under jetty and got this
>>>> exception:
>>>>
>>>> 7233 [main] INFO com.tcspring.DistributableBeanFactoryMixin - ptAppsRoot
>>>> registering transient fields for tc-cache-map-factory
>>>> com.protrade.common.cache.CacheFactory
>>>> com.tc.exception.TCClassNotFoundException:
>>>> java.lang.ClassNotFoundException: No registered loader for description:
>>>> Tomcat.Catalina:localhost:/fbracket, trying to load
>>>> com.tcspring.ComplexBeanId
>>>>          at
>>>>
>>>>        
>>> com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManag
>>>      
>>>> erImpl.java:600)
>>>>          at
>>>>
>>>>        
>>> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:287
>>>      
>>>> )
>>>>          at
>>>>
>>>>        
>>> com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:266
>>>      
>>>> )
>>>>          at
>>>>
>>>>        
>>> com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:130
>>>      
>>>> )
>>>>          at
>>>>
>>>>        
>>> com.tcspring.DistributableBeanFactoryMixin$ManagerUtilWrapperImpl.lookupOr
>>>      
>>>> CreateRoot(DistributableBeanFactoryMixin.java:419)
>>>>          at
>>>>
>>>>        
>>> com.tcspring.DistributableBeanFactoryMixin.registerBeanDefinitions(Distrib
>>>      
>>>> utableBeanFactoryMixin.java:221)
>>>>          at
>>>>
>>>>        
>>> org.springframework.beans.factory.support.AbstractBeanFactory.registerBean
>>>      
>>>> Definitions(AbstractBeanFactory.java)
>>>> ....
>>>> ...
>>>>
>>>>
>>>>
>>>>
>>>> Eugene Kuleshov wrote:
>>>>        
>>>>> Hi Fernando,
>>>>>
>>>>>   By default Terracotta for Spring is naming those roots using
>>>>>          
>>> synthetic
>>>      
>>>>> name derived from the matching web application name and matching
>>>>>          
>>> spring
>>>      
>>>>> config names. There is a FAQ entry about that in the "Troubleshooting
>>>>> Guide" linked from the on Terracotta home page. See
>>>>>
>>>>>          
>>> https://terracotta.org/confluence/display/wiki/Troubleshooting+Guide#Troub
>>>      
>>>> leshootingGuide-TerracottaforSpring...
>>>>        
>>>>>   So you can override that root name in your tc-config.xml using
>>>>> <root-name> element:
>>>>>
>>>>> ...
>>>>> <application>
>>>>>    <spring>
>>>>>      <jee-application>
>>>>>        <application-contexts>
>>>>>          <application-context>
>>>>>            <root-name>myClusteredSpringContext</root-name>
>>>>>              ...
>>>>>
>>>>>   regards,
>>>>>   Eugene Kuleshov
>>>>>
>>>>> PS: it feels like I am the only one answering all the questions today,
>>>>> but by strange coincidence those happens to be from my area of
>>>>>          
>>> expertise
>>>      
>>>>> Fernando Padilla wrote:
>>>>>          
>>>>>> I want to run my webapp through tomcat, jetty and mvn jetty:run, but
>>>>>> when I did, I noticed that terracotta was generating unique roots for
>>>>>> different ways that I launch the web application; and for each
>>>>>>            
>>>> different
>>>>        
>>>>>> context path that I launch my webapp under.. ( so developers can't
>>>>>>            
>>>> share
>>>>        
>>>>>> roots )
>>>>>>
>>>>>> This is very disappointing.  How can I get this working?
>>>>>>
>>>>>> -------
>>>>>> tc:spring_info.appName is coming up with different things:
>>>>>>
>>>>>> fbracket
>>>>>> Jetty.path=/fbracket
>>>>>> Jetty.path=/fannetwork
>>>>>>
>>>>>>            
>>>>> _______________________________________________
>>>>> tc-users mailing list
>>>>> tc-users@...
>>>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>>>>>          
>>>> _______________________________________________
>>>> tc-users mailing list
>>>> tc-users@...
>>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>>>>        
>>> _______________________________________________
>>> tc-users mailing list
>>> tc-users@...
>>> http://lists.terracotta.org/mailman/listinfo/tc-users
>>>      
>> _______________________________________________
>> tc-users mailing list
>> tc-users@...
>> http://lists.terracotta.org/mailman/listinfo/tc-users
>>    
> _______________________________________________
> tc-users mailing list
> tc-users@...
> http://lists.terracotta.org/mailman/listinfo/tc-users
>  

_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Fernando Padilla]

Thank you for replying.

> - is your production environment is using mixture of application servers
> that need to share the same data?

Not at the moment, but I would like to start testing Jetty instead of
Tomcat.  And having terracotta block this experimentation, and not allow
me to do a gradual switch over, testing at every step.. not good at all.


> - do you have requirement to share the same data between different web
> applications?

Yes.

>   For the second scenario, assuming that there is a common jar contain
> classes used for that shared data, the work around is to put that jar
> into a shared or common class loader or Tomcat (i.e. deploy it outside
> of your web applications, which would give additional memory benefits if
> more then one web application on the same server is using those
> classes). Those classloaders will have the same names across Terracotta
> clister, when all clustered web apps are running on Tomcat. See [1] for
> more details about Tomcat classloaders.

OK.  Now I understand what you guys were talking about.  We do not have
more than one app per server, but we do have many different web apps.
And this is still a major pain because it would totally screw with a
clean war file deploy wouldn't it?  You would then have to figure out
where the shared classes are and make sure that they aren't using any
static variable, and lots of testing.. etc etc etc...  I would love to
avoid that if possible.  Since packaging up a webapp would require many
extra steps to break it up into the app specific and the
sharable/distributes parts...



_______________________________________________
tc-users mailing list
tc-users@...
http://lists.terracotta.org/mailman/listinfo/tc-users

[Tim Eck]

I wish we had a better answer here. I completely agree that reshuffling
classes out of a WAR, and adding constraints around environment homogeny
(common app server, context paths, etc) are annoying at best and can
easily be too severe.

This mail might get a little long, but I'm going to spend a little time
discussing the problem of classloading as it applies to Terracotta. Mostly
I want to get a place where perhaps we can explore differing approaches
that might better work in your context. After that I'll offer up two more
workarounds, though I won't try to claim that they are pretty or even
palatable, but they could work.

The terracotta client that resides in each VM in your cluster applies to
the entire VM. The point here is the relationship is 1:1 between the VM
and the terracotta client. Another way to make that point is that the
terracotta client is not bound to a single web application (or that each
web application gets its own terracotta client instance). Given this
relationship, and that we want to accept objects for clustering no matter
which loader defined has led to the current implementation of assigning
identity/names to loaders. Each terracotta client has a local registry
where loaders can be found by name. I guess at the most basic level, the
issue is that when previously clustered objects are accessed in another
node, there must be some way to resolve a classloader to use to
manufacture the object (other ideas about how to do loader resolving
welcome).

So the other workarounds that can operate in scheme of loader naming are
(and can stay within the WAR):
1) Override the terracotta names assigned to tomcat/jetty/etc loaders to
manually force the desired equivalence. This implies calling
__tc_setClassLoaderName(String) on the loaders you want to rename and then
re-registering them with Terracotta.

2) Create and use your own classloader for accessing your shared cache.
Again, the classloader name would be in your control so that it can be
made common across differing app servers and/or context paths, virtual
hosts, etc

The two options are pretty similar (ie. take control of the loader name in
your code), they just differ on which class loader is operated on.

The APIs to rename and register loaders are pretty simple. The code
snippet in the middle of this forum post is an example:

http://forums.terracotta.org/forums/posts/list/505.page

Essentially the calls are:
((NamedClassLoader)loader).__tc_setClassLoaderName("name");
ClassProcessorHelper.registerGlobalLoader((NamedClassLoader)loader);

These calls can be made with reflection, or you can compile against our
API jar (available on our public maven repo).

Hope this helps. If you want more information about how to go about these
particular options, please let me know off list. For discussions about how
classloading and terracotta mix, please let's continue on the list.

-tim









 

 

> -----Original Message-----
> From: tc-users-bounces@... [mailto:tc-users-
> bounces@...] On Behalf Of Fernando Padilla
> Sent: Tuesday, February 26, 2008 3:48 PM
> To: tc-users@...
> Subject: Re: [tc-users] webapp spring roots
>
> Thank you for replying.
>
> > - is your production environment is using mixture of application

servers

> > that need to share the same data?
>
> Not at the moment, but I would like to start testing Jetty instead of
> Tomcat.  And having terracotta block this experimentation, and not allow
> me to do a gradual switch over, testing at every step.. not good at all.
>
>
> > - do you have requirement to share the same data between different web
> > applications?
>
> Yes.
>
> >   For the second scenario, assuming that there is a common jar contain
> > classes used for that shared data, the work around is to put that jar
> > into a shared or common class loader or Tomcat (i.e. deploy it outside
> > of your web applications, which would give additional memory benefits

if
> > more then one web application on the same server is using those
> > classes). Those classloaders will have the same names across
Terracotta
> > clister, when all clustered web apps are running on Tomcat. See [1]
for

> > more details about Tomcat classloaders.
>
> OK.  Now I understand what you guys were talking about.  We do not have
> more than one app per server, but we do have many different web apps.
> And this is still a ma