The webapp attribute is dependent on the Servlet container. For example, on Tomcat, it will typically be the name of the .war file (without the .war suffix).
I wasn't able to get it to work using the name of the war file, but it
did work if i put in the name of the directory to which the war is
deployed. (They are different for this particular app. I'm not sure
why... historical reasons I guess. :)
Now I am having a different issue. Here is my decorator file:
layout.jsp in the providing StyleApp application has the taglib <%@
taglib uri="http://www.opensymphony.com/sitemesh/decorator"
prefix="decorator" %> line and the <decorator:body/> tag. However,
the decorator:body appears to be replaced with nothing in the
consuming application. (It just gets deleted.)
If I go to http://localhost:9080/StyleApp/decorators/layout.jsp and
look at the processed JSP page, the taglib and decorator:body tags
have been removed. I am wondering if the consuming app actually
receives these tags? I suppose it depends on whether it is grabbing
the layout.jsp file before or after it is processed. Does it sound
like I've set this up correctly?
Thanks again,
On Mar 30, 11:44 am, Joe Walnes <j...@walnes.com> wrote:
> The webapp attribute is dependent on the Servlet container. For example, on
> Tomcat, it will typically be the name of the .war file (without the .war
> suffix).
> thanks
> -Joe
> On Fri, Mar 30, 2012 at 11:07 AM, Caden <ca...@cadenhowell.com> wrote:
> > I have a question about the solution used here (see the bottom):
> I wasn't able to get it to work using the name of the war file, but it
> did work if i put in the name of the directory to which the war is
> deployed. (They are different for this particular app. I'm not sure
> why... historical reasons I guess. :)
> Now I am having a different issue. Here is my decorator file:
> layout.jsp in the providing StyleApp application has the taglib <%@
> taglib uri="http://www.opensymphony.com/sitemesh/decorator"
> prefix="decorator" %> line and the <decorator:body/> tag. However,
> the decorator:body appears to be replaced with nothing in the
> consuming application. (It just gets deleted.)
> If I go tohttp://localhost:9080/StyleApp/decorators/layout.jspand > look at the processed JSP page, the taglib and decorator:body tags
> have been removed. I am wondering if the consuming app actually
> receives these tags? I suppose it depends on whether it is grabbing
> the layout.jsp file before or after it is processed. Does it sound
> like I've set this up correctly?
> Thanks again,
> On Mar 30, 11:44 am, Joe Walnes <j...@walnes.com> wrote:
> > The webapp attribute is dependent on the Servlet container. For example, on
> > Tomcat, it will typically be the name of the .war file (without the .war
> > suffix).
> > thanks
> > -Joe
> > On Fri, Mar 30, 2012 at 11:07 AM, Caden <ca...@cadenhowell.com> wrote:
> > > I have a question about the solution used here (see the bottom):
So, so far, I've set up one web application, StyleApp, with a
layout.jsp file, and another web application which consumes that
layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks
like:
request.setAttribute(PAGE, new Content2HTMLPage(content,
request));
// ^^^^ HERE
// see if the URI path (webapp) is set
if (oldDecorator.getURIPath() != null) {
// in a security conscious environment, the servlet
container
// may return null for a given URL
if (servletContext.getContext(oldDecorator.getURIPath()) !
= null) {
servletContext =
servletContext.getContext(oldDecorator.getURIPath());
}
}
// get the dispatcher for the decorator
RequestDispatcher dispatcher =
servletContext.getRequestDispatcher(oldDecorator.getPage());
dispatcher.include(request, response);
^^^^^ include calls the code that eventually calls the
exception code
request.removeAttribute(PAGE);
}
In the comments for this file (OldDecorator2NewDecorator.java) it says
that this class "Adapts a SiteMesh 2 {@link
com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link
com.opensymphony.sitemesh.Decorator}." I thought that maybe some new
code had been incorporated, for SiteMesh 3 that had broken it, but I
tried rolling back the library to SiteMesh 2.3 and I got a slightly
different error with a different class name in the same place. (I
neglected to copy the message)
Does anyone have any suggestions about what I could try next? I'm
very interested in this feature, as I like SiteMesh and the ability to
use a single layout from multiple wars would be a big help in our
organization.
I suspect the issue is to do with sitemesh.jar being loaded in multiple class loaders. If you have 2 identical classes loaded from separate classloaders, the JVM treats them as different and one cannot be cast to the other. Some Servlet engines use separate classloaders for each web-app to ensure they are isolated from each other.
To get around this, there may be a common directory that you can place jars that are loaded as part of the main Servlet engine, instead of the individual web-apps. Place sitemesh.jar in there. In Tomcat there is a common 'lib' directory - maybe there's something similar for WebSphereAS?
On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
> So, so far, I've set up one web application, StyleApp, with a > layout.jsp file, and another web application which consumes that > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks > like:
> request.setAttribute(PAGE, new Content2HTMLPage(content, > request)); > // ^^^^ HERE
> // see if the URI path (webapp) is set > if (oldDecorator.getURIPath() != null) { > // in a security conscious environment, the servlet > container > // may return null for a given URL > if (servletContext.getContext(oldDecorator.getURIPath()) ! > = null) { > servletContext = > servletContext.getContext(oldDecorator.getURIPath()); > } > } > // get the dispatcher for the decorator > RequestDispatcher dispatcher = > servletContext.getRequestDispatcher(oldDecorator.getPage()); > dispatcher.include(request, response); > ^^^^^ include calls the code that eventually calls the > exception code
> request.removeAttribute(PAGE); > }
> In the comments for this file (OldDecorator2NewDecorator.java) it says > that this class "Adapts a SiteMesh 2 {@link > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new > code had been incorporated, for SiteMesh 3 that had broken it, but I > tried rolling back the library to SiteMesh 2.3 and I got a slightly > different error with a different class name in the same place. (I > neglected to copy the message)
> Does anyone have any suggestions about what I could try next? I'm > very interested in this feature, as I like SiteMesh and the ability to > use a single layout from multiple wars would be a big help in our > organization.
Thanks again for your help. I looked at the classes loaded in each
war (the provider and the consumer) with the Websphere "Class Loader
Viewer" and it looks like sitemesh-2.4.2.jar is only being loaded once
in each .war. Maybe I need to force them to share the same jar? I
have copies loaded it into the WEB-INF/lib directory in each war.
Also, if I roll back the change that points to the separate
application and make it point to a template in the same application,
the error goes away.
I'm also wondering, was I supposed to set up the provider as a non-
Sitemesh enabled site which just delivers the templates through http,
still including the decorator taglib tag and <decorator:body/> tags?
Right now I'm running 2 Sitemesh web applications, both the provider
and the consumer.
Caden
On Mar 30, 5:12 pm, Joe Walnes <j...@walnes.com> wrote:
> I suspect the issue is to do with sitemesh.jar being loaded in multiple
> class loaders. If you have 2 identical classes loaded from separate
> classloaders, the JVM treats them as different and one cannot be cast to
> the other. Some Servlet engines use separate classloaders for each web-app
> to ensure they are isolated from each other.
> To get around this, there may be a common directory that you can place jars
> that are loaded as part of the main Servlet engine, instead of the
> individual web-apps. Place sitemesh.jar in there. In Tomcat there is a
> common 'lib' directory - maybe there's something similar for WebSphereAS?
> thanks
> -Joe
> On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
> > So, so far, I've set up one web application, StyleApp, with a
> > layout.jsp file, and another web application which consumes that
> > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks
> > like:
> > I should note as well that we use WebSphere Application Server 6.1
> > here, and the applications are deployed in separate wars in separate
> > ears.
> > When I bring up the consumer page in the web browser I get the
> > following exception:
> > request.setAttribute(PAGE, new Content2HTMLPage(content,
> > request));
> > // ^^^^ HERE
> > // see if the URI path (webapp) is set
> > if (oldDecorator.getURIPath() != null) {
> > // in a security conscious environment, the servlet
> > container
> > // may return null for a given URL
> > if (servletContext.getContext(oldDecorator.getURIPath()) !
> > = null) {
> > servletContext =
> > servletContext.getContext(oldDecorator.getURIPath());
> > }
> > }
> > // get the dispatcher for the decorator
> > RequestDispatcher dispatcher =
> > servletContext.getRequestDispatcher(oldDecorator.getPage());
> > dispatcher.include(request, response);
> > ^^^^^ include calls the code that eventually calls the
> > exception code
> > request.removeAttribute(PAGE);
> > }
> > In the comments for this file (OldDecorator2NewDecorator.java) it says
> > that this class "Adapts a SiteMesh 2 {@link
> > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link
> > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new
> > code had been incorporated, for SiteMesh 3 that had broken it, but I
> > tried rolling back the library to SiteMesh 2.3 and I got a slightly
> > different error with a different class name in the same place. (I
> > neglected to copy the message)
> > Does anyone have any suggestions about what I could try next? I'm
> > very interested in this feature, as I like SiteMesh and the ability to
> > use a single layout from multiple wars would be a big help in our
> > organization.- Hide quoted text -
I believe both sites need access to the jar (because they both need the Content2HTMLPage class.
But they need to be loaded by the same classloader. Even if you place the same .jar file in both WEB-INF/lib folders, they will be different classes as far as Java is concerned. So you need to remove sitemesh.jar from WEB-INF/lib and place it in a parent classloader.
You may get a better response if you ask the WebSphere community. The specific question you want is 'Where do I place a .jar to ensure that multiple web-apps can load it in the same parent classloader?'.
On Mon, Apr 2, 2012 at 10:09 AM, Caden <ca...@cadenhowell.com> wrote:
> Hi Joe,
> Thanks again for your help. I looked at the classes loaded in each > war (the provider and the consumer) with the Websphere "Class Loader > Viewer" and it looks like sitemesh-2.4.2.jar is only being loaded once > in each .war. Maybe I need to force them to share the same jar? I > have copies loaded it into the WEB-INF/lib directory in each war.
> Also, if I roll back the change that points to the separate > application and make it point to a template in the same application, > the error goes away.
> I'm also wondering, was I supposed to set up the provider as a non- > Sitemesh enabled site which just delivers the templates through http, > still including the decorator taglib tag and <decorator:body/> tags? > Right now I'm running 2 Sitemesh web applications, both the provider > and the consumer.
> Caden
> On Mar 30, 5:12 pm, Joe Walnes <j...@walnes.com> wrote: > > I suspect the issue is to do with sitemesh.jar being loaded in multiple > > class loaders. If you have 2 identical classes loaded from separate > > classloaders, the JVM treats them as different and one cannot be cast to > > the other. Some Servlet engines use separate classloaders for each > web-app > > to ensure they are isolated from each other.
> > To get around this, there may be a common directory that you can place > jars > > that are loaded as part of the main Servlet engine, instead of the > > individual web-apps. Place sitemesh.jar in there. In Tomcat there is a > > common 'lib' directory - maybe there's something similar for WebSphereAS?
> > thanks > > -Joe
> > On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
> > > So, so far, I've set up one web application, StyleApp, with a > > > layout.jsp file, and another web application which consumes that > > > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks > > > like:
> > > I should note as well that we use WebSphere Application Server 6.1 > > > here, and the applications are deployed in separate wars in separate > > > ears.
> > > When I bring up the consumer page in the web browser I get the > > > following exception:
> > > request.setAttribute(PAGE, new Content2HTMLPage(content, > > > request)); > > > // ^^^^ HERE
> > > // see if the URI path (webapp) is set > > > if (oldDecorator.getURIPath() != null) { > > > // in a security conscious environment, the servlet > > > container > > > // may return null for a given URL > > > if (servletContext.getContext(oldDecorator.getURIPath()) ! > > > = null) { > > > servletContext = > > > servletContext.getContext(oldDecorator.getURIPath()); > > > } > > > } > > > // get the dispatcher for the decorator > > > RequestDispatcher dispatcher = > > > servletContext.getRequestDispatcher(oldDecorator.getPage()); > > > dispatcher.include(request, response); > > > ^^^^^ include calls the code that eventually calls the > > > exception code
> > > request.removeAttribute(PAGE); > > > }
> > > In the comments for this file (OldDecorator2NewDecorator.java) it says > > > that this class "Adapts a SiteMesh 2 {@link > > > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link > > > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new > > > code had been incorporated, for SiteMesh 3 that had broken it, but I > > > tried rolling back the library to SiteMesh 2.3 and I got a slightly > > > different error with a different class name in the same place. (I > > > neglected to copy the message)
> > > Does anyone have any suggestions about what I could try next? I'm > > > very interested in this feature, as I like SiteMesh and the ability to > > > use a single layout from multiple wars would be a big help in our > > > organization.- Hide quoted text -
On Mon, Apr 2, 2012 at 11:18 AM, Joe Walnes <j...@walnes.com> wrote: > I believe both sites need access to the jar (because they both need the > Content2HTMLPage class.
> But they need to be loaded by the same classloader. Even if you place the > same .jar file in both WEB-INF/lib folders, they will be different classes > as far as Java is concerned. So you need to remove sitemesh.jar from > WEB-INF/lib and place it in a parent classloader.
> In WSAS, this could be an 'application classloader' - i.e. in a .ear file > and shared by multiple.wars. Or in a WebSphere extension or by the main JDK > classloader. > There are some docs here:
> You may get a better response if you ask the WebSphere community. The > specific question you want is 'Where do I place a .jar to ensure that > multiple web-apps can load it in the same parent classloader?'.
> thanks > -Joe
> On Mon, Apr 2, 2012 at 10:09 AM, Caden <ca...@cadenhowell.com> wrote:
>> Hi Joe,
>> Thanks again for your help. I looked at the classes loaded in each >> war (the provider and the consumer) with the Websphere "Class Loader >> Viewer" and it looks like sitemesh-2.4.2.jar is only being loaded once >> in each .war. Maybe I need to force them to share the same jar? I >> have copies loaded it into the WEB-INF/lib directory in each war.
>> Also, if I roll back the change that points to the separate >> application and make it point to a template in the same application, >> the error goes away.
>> I'm also wondering, was I supposed to set up the provider as a non- >> Sitemesh enabled site which just delivers the templates through http, >> still including the decorator taglib tag and <decorator:body/> tags? >> Right now I'm running 2 Sitemesh web applications, both the provider >> and the consumer.
>> Caden
>> On Mar 30, 5:12 pm, Joe Walnes <j...@walnes.com> wrote: >> > I suspect the issue is to do with sitemesh.jar being loaded in multiple >> > class loaders. If you have 2 identical classes loaded from separate >> > classloaders, the JVM treats them as different and one cannot be cast to >> > the other. Some Servlet engines use separate classloaders for each >> web-app >> > to ensure they are isolated from each other.
>> > To get around this, there may be a common directory that you can place >> jars >> > that are loaded as part of the main Servlet engine, instead of the >> > individual web-apps. Place sitemesh.jar in there. In Tomcat there is a >> > common 'lib' directory - maybe there's something similar for >> WebSphereAS?
>> > thanks >> > -Joe
>> > On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
>> > > So, so far, I've set up one web application, StyleApp, with a >> > > layout.jsp file, and another web application which consumes that >> > > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks >> > > like:
>> > > I should note as well that we use WebSphere Application Server 6.1 >> > > here, and the applications are deployed in separate wars in separate >> > > ears.
>> > > When I bring up the consumer page in the web browser I get the >> > > following exception:
>> > > request.setAttribute(PAGE, new Content2HTMLPage(content, >> > > request)); >> > > // ^^^^ HERE
>> > > // see if the URI path (webapp) is set >> > > if (oldDecorator.getURIPath() != null) { >> > > // in a security conscious environment, the servlet >> > > container >> > > // may return null for a given URL >> > > if (servletContext.getContext(oldDecorator.getURIPath()) ! >> > > = null) { >> > > servletContext = >> > > servletContext.getContext(oldDecorator.getURIPath()); >> > > } >> > > } >> > > // get the dispatcher for the decorator >> > > RequestDispatcher dispatcher = >> > > servletContext.getRequestDispatcher(oldDecorator.getPage()); >> > > dispatcher.include(request, response); >> > > ^^^^^ include calls the code that eventually calls the >> > > exception code
>> > > request.removeAttribute(PAGE); >> > > }
>> > > In the comments for this file (OldDecorator2NewDecorator.java) it says >> > > that this class "Adapts a SiteMesh 2 {@link >> > > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link >> > > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new >> > > code had been incorporated, for SiteMesh 3 that had broken it, but I >> > > tried rolling back the library to SiteMesh 2.3 and I got a slightly >> > > different error with a different class name in the same place. (I >> > > neglected to copy the message)
>> > > Does anyone have any suggestions about what I could try next? I'm >> > > very interested in this feature, as I like SiteMesh and the ability to >> > > use a single layout from multiple wars would be a big help in our >> > > organization.- Hide quoted text -
Joe, you were right on the money. I moved the jars out of the individual Sitemesh projects and into the directory where they would be loaded by the system classloader. On my machine, which runs Rational Application Developer 7 and the associated WebSphere AS 6.1, that directory was:
C:\Program Files\IBM\SDP70\runtimes\base_v61\lib
Now it is working across separate wars and ears. I am going to see if my team is as excited as I am to get this working on a few of our visually mismatched applications.
On Mon, Apr 2, 2012 at 11:21 AM, C. Howell <ca...@cadenhowell.com> wrote: > Joe, thanks this is a huge help. I will ask around. Right now the > applications are in separate ears.
> On Mon, Apr 2, 2012 at 11:18 AM, Joe Walnes <j...@walnes.com> wrote:
>> I believe both sites need access to the jar (because they both need the >> Content2HTMLPage class.
>> But they need to be loaded by the same classloader. Even if you place the >> same .jar file in both WEB-INF/lib folders, they will be different classes >> as far as Java is concerned. So you need to remove sitemesh.jar from >> WEB-INF/lib and place it in a parent classloader.
>> In WSAS, this could be an 'application classloader' - i.e. in a .ear file >> and shared by multiple.wars. Or in a WebSphere extension or by the main JDK >> classloader. >> There are some docs here:
>> You may get a better response if you ask the WebSphere community. The >> specific question you want is 'Where do I place a .jar to ensure that >> multiple web-apps can load it in the same parent classloader?'.
>> thanks >> -Joe
>> On Mon, Apr 2, 2012 at 10:09 AM, Caden <ca...@cadenhowell.com> wrote:
>>> Hi Joe,
>>> Thanks again for your help. I looked at the classes loaded in each >>> war (the provider and the consumer) with the Websphere "Class Loader >>> Viewer" and it looks like sitemesh-2.4.2.jar is only being loaded once >>> in each .war. Maybe I need to force them to share the same jar? I >>> have copies loaded it into the WEB-INF/lib directory in each war.
>>> Also, if I roll back the change that points to the separate >>> application and make it point to a template in the same application, >>> the error goes away.
>>> I'm also wondering, was I supposed to set up the provider as a non- >>> Sitemesh enabled site which just delivers the templates through http, >>> still including the decorator taglib tag and <decorator:body/> tags? >>> Right now I'm running 2 Sitemesh web applications, both the provider >>> and the consumer.
>>> Caden
>>> On Mar 30, 5:12 pm, Joe Walnes <j...@walnes.com> wrote: >>> > I suspect the issue is to do with sitemesh.jar being loaded in multiple >>> > class loaders. If you have 2 identical classes loaded from separate >>> > classloaders, the JVM treats them as different and one cannot be cast >>> to >>> > the other. Some Servlet engines use separate classloaders for each >>> web-app >>> > to ensure they are isolated from each other.
>>> > To get around this, there may be a common directory that you can place >>> jars >>> > that are loaded as part of the main Servlet engine, instead of the >>> > individual web-apps. Place sitemesh.jar in there. In Tomcat there is a >>> > common 'lib' directory - maybe there's something similar for >>> WebSphereAS?
>>> > thanks >>> > -Joe
>>> > On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
>>> > > So, so far, I've set up one web application, StyleApp, with a >>> > > layout.jsp file, and another web application which consumes that >>> > > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks >>> > > like:
>>> > > I should note as well that we use WebSphere Application Server 6.1 >>> > > here, and the applications are deployed in separate wars in separate >>> > > ears.
>>> > > When I bring up the consumer page in the web browser I get the >>> > > following exception:
>>> > > I downloaded the source code for 2.4.2 from >>> > >https://java.net/downloads/sitemesh/SiteMesh%202.4.2/ >>> > > and have been stepping through what happens in the IDE. The >>> exception >>> > > occurs here:
>>> > > request.setAttribute(PAGE, new Content2HTMLPage(content, >>> > > request)); >>> > > // ^^^^ HERE
>>> > > // see if the URI path (webapp) is set >>> > > if (oldDecorator.getURIPath() != null) { >>> > > // in a security conscious environment, the servlet >>> > > container >>> > > // may return null for a given URL >>> > > if (servletContext.getContext(oldDecorator.getURIPath()) ! >>> > > = null) { >>> > > servletContext = >>> > > servletContext.getContext(oldDecorator.getURIPath()); >>> > > } >>> > > } >>> > > // get the dispatcher for the decorator >>> > > RequestDispatcher dispatcher = >>> > > servletContext.getRequestDispatcher(oldDecorator.getPage()); >>> > > dispatcher.include(request, response); >>> > > ^^^^^ include calls the code that eventually calls the >>> > > exception code
>>> > > request.removeAttribute(PAGE); >>> > > }
>>> > > In the comments for this file (OldDecorator2NewDecorator.java) it >>> says >>> > > that this class "Adapts a SiteMesh 2 {@link >>> > > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link >>> > > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new >>> > > code had been incorporated, for SiteMesh 3 that had broken it, but I >>> > > tried rolling back the library to SiteMesh 2.3 and I got a slightly >>> > > different error with a different class name in the same place. (I >>> > > neglected to copy the message)
>>> > > Does anyone have any suggestions about what I could try next? I'm >>> > > very interested in this feature, as I like SiteMesh and the ability >>> to >>> > > use a single layout from multiple wars would be a big help in our >>> > > organization.- Hide quoted text -
One more thing, in case anyone tries to get this working on WebSphere
6.1. (I know... probably not that likely :) I did some more reading
and it appears that the preferred way to do this is not to drop the
sitemesh jar into one of the java JRE or WebSphere root lib
directories. The preferred way to share a library across an entire
server or cluster is to create a shared library through the
"Integrated Solutions Console". I used the instructions here and
shared it across the entire server rather than just certain
applications:
> Joe, you were right on the money. I moved the jars out of the individual
> Sitemesh projects and into the directory where they would be loaded by the
> system classloader. On my machine, which runs Rational Application
> Developer 7 and the associated WebSphere AS 6.1, that directory was:
> Now it is working across separate wars and ears. I am going to see if my
> team is as excited as I am to get this working on a few of our visually
> mismatched applications.
> Thanks again,
> Caden
> On Mon, Apr 2, 2012 at 11:21 AM, C. Howell <ca...@cadenhowell.com> wrote:
> > Joe, thanks this is a huge help. I will ask around. Right now the
> > applications are in separate ears.
> > On Mon, Apr 2, 2012 at 11:18 AM, Joe Walnes <j...@walnes.com> wrote:
> >> I believe both sites need access to the jar (because they both need the
> >> Content2HTMLPage class.
> >> But they need to be loaded by the same classloader. Even if you place the
> >> same .jar file in both WEB-INF/lib folders, they will be different classes
> >> as far as Java is concerned. So you need to remove sitemesh.jar from
> >> WEB-INF/lib and place it in a parent classloader.
> >> In WSAS, this could be an 'application classloader' - i.e. in a .ear file
> >> and shared by multiple.wars. Or in a WebSphere extension or by the main JDK
> >> classloader.
> >> There are some docs here:
> >> You may get a better response if you ask the WebSphere community. The
> >> specific question you want is 'Where do I place a .jar to ensure that
> >> multiple web-apps can load it in the same parent classloader?'.
> >> thanks
> >> -Joe
> >> On Mon, Apr 2, 2012 at 10:09 AM, Caden <ca...@cadenhowell.com> wrote:
> >>> Hi Joe,
> >>> Thanks again for your help. I looked at the classes loaded in each
> >>> war (the provider and the consumer) with the Websphere "Class Loader
> >>> Viewer" and it looks like sitemesh-2.4.2.jar is only being loaded once
> >>> in each .war. Maybe I need to force them to share the same jar? I
> >>> have copies loaded it into the WEB-INF/lib directory in each war.
> >>> Also, if I roll back the change that points to the separate
> >>> application and make it point to a template in the same application,
> >>> the error goes away.
> >>> I'm also wondering, was I supposed to set up the provider as a non-
> >>> Sitemesh enabled site which just delivers the templates through http,
> >>> still including the decorator taglib tag and <decorator:body/> tags?
> >>> Right now I'm running 2 Sitemesh web applications, both the provider
> >>> and the consumer.
> >>> Caden
> >>> On Mar 30, 5:12 pm, Joe Walnes <j...@walnes.com> wrote:
> >>> > I suspect the issue is to do with sitemesh.jar being loaded in multiple
> >>> > class loaders. If you have 2 identical classes loaded from separate
> >>> > classloaders, the JVM treats them as different and one cannot be cast
> >>> to
> >>> > the other. Some Servlet engines use separate classloaders for each
> >>> web-app
> >>> > to ensure they are isolated from each other.
> >>> > To get around this, there may be a common directory that you can place
> >>> jars
> >>> > that are loaded as part of the main Servlet engine, instead of the
> >>> > individual web-apps. Place sitemesh.jar in there. In Tomcat there is a
> >>> > common 'lib' directory - maybe there's something similar for
> >>> WebSphereAS?
> >>> > thanks
> >>> > -Joe
> >>> > On Fri, Mar 30, 2012 at 3:48 PM, Caden <ca...@cadenhowell.com> wrote:
> >>> > > So, so far, I've set up one web application, StyleApp, with a
> >>> > > layout.jsp file, and another web application which consumes that
> >>> > > layout.jsp with sitemesh 2.4.2. The consumer's decorator file looks
> >>> > > like:
> >>> > > I should note as well that we use WebSphere Application Server 6.1
> >>> > > here, and the applications are deployed in separate wars in separate
> >>> > > ears.
> >>> > > When I bring up the consumer page in the web browser I get the
> >>> > > following exception:
> >>> > > I downloaded the source code for 2.4.2 from
> >>> > >https://java.net/downloads/sitemesh/SiteMesh%202.4.2/ > >>> > > and have been stepping through what happens in the IDE. The
> >>> exception
> >>> > > occurs here:
> >>> > > In the comments for this file (OldDecorator2NewDecorator.java) it
> >>> says
> >>> > > that this class "Adapts a SiteMesh 2 {@link
> >>> > > com.opensymphony.module.sitemesh.Decorator} to a SiteMesh 3 {@link
> >>> > > com.opensymphony.sitemesh.Decorator}." I thought that maybe some new
> >>> > > code had been incorporated, for SiteMesh 3 that had broken it, but I
> >>> > > tried rolling back the library to SiteMesh 2.3 and I got a slightly
> >>> > > different error with a different class name in the same place. (I
> >>> > > neglected to copy the message)
> >>> > > Does anyone have any suggestions about what I could try next? I'm
> >>> > > very interested in this feature, as I like SiteMesh and the ability
> >>> to
> >>> > > use a single layout from
