Forums

Home » Liferay Portal » English » Liferay Legacy

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
In Response to why hot deployable themes must be based on Velocity Russ Danner August 4, 2006 3:07 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 6, 2006 9:00 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 6, 2006 8:59 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 8, 2006 8:04 PM
RE: In Response to why hot deployable themes must be based on Velocity Brian Kim August 16, 2006 7:21 AM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 16, 2006 7:57 AM
RE: In Response to why hot deployable themes must be based on Velocity Michael Young August 5, 2006 10:21 AM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 6, 2006 1:05 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 7, 2006 3:12 AM
RE: In Response to why hot deployable themes must be based on Velocity Brian Chan August 7, 2006 2:47 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 7, 2006 3:00 PM
RE: In Response to why hot deployable themes must be based on Velocity Michael Young August 7, 2006 4:41 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 7, 2006 6:11 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 8, 2006 8:06 PM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 7, 2006 8:48 PM
RE: In Response to why hot deployable themes must be based on Velocity Mika Koivisto August 8, 2006 12:40 AM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 8, 2006 5:26 AM
RE: In Response to why hot deployable themes must be based on Velocity Natalia Baranowska August 16, 2006 4:47 AM
RE: In Response to why hot deployable themes must be based on Velocity Russ Danner August 16, 2006 7:58 AM
RE: In Response to why hot deployable themes must be based on Velocity Natalia Baranowska August 21, 2006 4:22 AM
Russ Danner
In Response to why hot deployable themes must be based on Velocity
August 4, 2006 3:07 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

http://content.liferay.com/4.0.0/docs/developers/ch04s01.html#d0e4929

The following documentation states that because liferay has recently cleaned up its classloading ways JSP themes no longer work because portal classes no longer bleed from one context to another. IMO this change is one of the most important reorganizations of liferay code yet. I am so happy about it, i could pee glitter.

As a result of the class path lockdown liferay has a new issue whereby JSP based themes are no longer available for hot class loading. You have to build them with the extension mechanism. Holy crap! I am not going to deploy a new portal to get a theme out... Sheesh I am trying to get liferay to the point where we never have to build with the extension environment. I want to build my add-ons independently of liferay. The extension environment IMO should be the PATCH environment. Better yet a system that allows us to deploy patches without building the old environment (as simple as put jar in place X wich loads before the portal and thus 'patches' the system.) I really think building liferay should be a task for PORTAL infrastructure developers. Anyway the whole build JSP themes with the extension environment makes JSP themes a joke. Ah well. Progress has its price.

For example hot deployment of JSP theme in 4.1 (references to themes in this post will assume im talking about jsp themes) into tomcat will cause you to get an error that the theme context cannot be found. In jboss with the UCL on this does not happen it works because UCL overrides liferays good behavior.

Accourding to the servlet spec getContext(String pContextName) is allowed to return null for contexts that exist if security needs require a no touching policy between contexts.

The ability for contexts to touch eachother is not nearly as horrible as the classloader hell created by older deployments of liferay and jboss UCL. Its clean but it does have security implications and it does invite some developers to create cohession between thier applications.

Some thoughts here:
We have a hot deploy mechansim. This means we have a lot of control. We can move templates from one context to another and leave the cross context settings out of the picture.

OR we can turn on cross context for the root and deployable themes. Either solution solves the issue of the context loading. If we use cross context loading then the liferay include tag needs to be extended to allow developers to specify the context they are expressing. We should have ways to express to common contexts THIS and PORTAL where these things are resolved at runtime eliminating sketchy hardcoding.

OR we could combine these two mechanisms: We create a context call themeHost (or something) which is the only cross context application with the portal. This limits the exposure to security concerns. The hot deployment mechanism would then lift the templates out of the hot deployed theme and drop them in the themeHost context. The themeHost can be a special application dedicated to serving themes.

it would understand what kinds of themes are deployed to it VM, JSP, etc. When a new theme is registered its type is registerd. It can be assigned the appropriate theme adapters which would eliminate code like this from running on every request (yay for object oriented code cutting down on case logic -- depending on how much case logic we drop we may even see a perf improvement):

 1
 2public class ThemeUtil {
 3
 4    public static void include(
 5            ServletContext ctx, HttpServletRequest req, HttpServletResponse res,
 6            PageContext pageContext, String page, Theme theme)
 7        throws Exception {
 8
 9        String extension = theme.getTemplateExtension();
10
11        if (extension.equals("vm")) {
12            includeVM(ctx, req, pageContext, page, theme);
13        }
14        else {
15            String path =
16                theme.getTemplatesPath() + StringPool.SLASH + page;


The themeHost application can have cohesion with the portal implemenation that we would discourage from the themes. It would give us a buffer between the theme and portal. Changes in the portal would be less likely to break peoples themes. We could also use it to address backward compatibility. people could then deploy a 3.6.1 theme and we would apply the right adapter and it would continue to run. (of course we would then have to support a deprication program.... we allow 2 versions of theme backward compatability.. upgrade soon but it doesnt have to be upgrade now... companies cant handle that.)

----

I really like the velocity templates but I think it is worth while keeping the JSP themes fully functional. There are a lot of developers who are used to JSP and creating JSP taglibs and less who know how to extend VM tag libraries.

We will probably continue to create liferay plugins that allow developers to express themes in whatever mechanism works best for them JSP, FreeMarker, Velocity, WebMacro, TapestryISH templates, etc.


---

look im thinking outloud here so... dont kill me if Im out to lunch (I almost always am.)

My personal pain/motivation is thus:
My company now has several themes written in JSP. The continue to work in JBoss (our production environment) because we use UCL. UCL sucks and I want it turned off yesterday.
I use tomcat for development because it loads much faster then JBOSS and also because I have a belief: "If it doesnt work in Tomcat -- it doesnt work". I can no longer develop themes or theme related code in tomcat as long as its JSP and unless i want to rebuild my portal (out of the question.) I like VM templates but I will not move my organization to using these in any short term timeframe. Velocity is great but it shouldnt not be the only option.

On a community note:
This problem was created because liferay is moving in the right direction. I think we can solve the issue with a design that not only solves the problem but again gives liferay a leg up in plug-ability, support for backward compatibility etc.

This is an oppertunity to tackle an unsolved issue. If you think the issue is relevant to you, get involved in the conversation and lets do some community based design and development.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 6, 2006 9:00 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

This is my understanding of how the Theme Hot Deploy works...
Michael Young
RE: In Response to why hot deployable themes must be based on Velocity
August 5, 2006 10:21 AM
Answer

Michael Young

LIFERAY STAFF

Rank: Liferay Master

Posts: 847

Join Date: August 4, 2004

Recent Posts

For example hot deployment of JSP theme in 4.1 (references to themes in this post will assume im talking about jsp themes) into tomcat will cause you to get an error that the theme context cannot be found. In jboss with the UCL on this does not happen it works because UCL overrides liferays good behavior.


It's not that the theme context is cannot be put there as we have experimented with the cross-context possibility. The problem is the WARs ability to load portal classes.

As I expressesd in a previous thread we need a way to cleanly expose portal service interfaces alone without moving over the jars.

I have some ideas about this and actually think it will work, but amount of refactor would be a nightmare for us at this point.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 6, 2006 1:05 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Michael Young:
For example hot deployment of JSP theme in 4.1 (references to themes in this post will assume im talking about jsp themes) into tomcat will cause you to get an error that the theme context cannot be found. In jboss with the UCL on this does not happen it works because UCL overrides liferays good behavior.


It's not that the theme context is cannot be put there as we have experimented with the cross-context possibility. The problem is the WARs ability to load portal classes.

As I expressesd in a previous thread we need a way to cleanly expose portal service interfaces alone without moving over the jars.

I have some ideas about this and actually think it will work, but amount of refactor would be a nightmare for us at this point.


Right I've noticed several sticky issues. First is the context issue. As you said thats not the only issue, you have the issue of the need to get certain key classes exposed across the platform. This might involve a lot of refactoring. The kernel jar is a start on this. Moving some key classes to this jar or a core jar would solve a lot of the issues. You could also look at some class loader options but that is tricky and would be hell to support across all of the containers. lastly is the JSP issues. Liferay JSP themes make use of the <%@include ...%> tag which is a real problem to overcome unless you are willing to move JSP files into a common area where the processor has access to all the needed files. <%@include ...%> behaves entirely different from <jsp:include ..> or <liferay:include ..> which depends on the request dispatcher.

Anyway what are your refactoring ideas? andd can you explain where the refactoring would give rise to the worst issues
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 6, 2006 8:59 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

I think is is more accurate

Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 3:12 AM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

We have been talking about some refactoring in another thread which I hope continues but I have something of a productionISH / development deadline issue to solve at the moment. In

production we are on 4.0RC2, if I go to 4.1.x I am basically up the creek without a paddle because its going to bust my ability to hot deploy themes >[ (JSP based themes which are the only themes I have). I don't have time to recode the themes and I don't have any options on the liferay upgrade; I need to go to 4.1.x (as you know, our site is [for the moment a monument to MySQL's ability to handle more then a few queries / second].

In production we are running the Jboss UCL. Which seems to keep the 4.1 themes working but I think we will not have that entirely proved out until the end of today. emoticon

I have some development tasks which I would like to get done using tomcat. I'd like to know how to get 4.1 back to the 4.0RC2 ability to run JSP themes in tomcat (that is, run JSP themes without the help of the UCL [sheesh... am I actually saying this? without the help of the UCL... I hate that thing and now it seems a blessing] emoticon ) so we can do development without waiting 10 minutes for Jboss/Liferay to load.

If possible, I'd also like some advice on moving our production environment away from the enterprise configuration and on to the professional configuration. There seems to be no benifit of the enterprise configuration for our purposes. We did know better is all.
I am hoping it goes something like "No problem... build and deploy the war rather than the ear" but I won't get my hopes up just incase its more complicated.

Thanks guys
Brian Chan
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 2:47 PM
Answer

Brian Chan

LIFERAY STAFF

Rank: Liferay Master

Posts: 751

Join Date: August 4, 2004

Recent Posts

In app.server.properties:

app.server.tomcat.dir=D:/Java/tomcat-5.5.17
app.server.tomcat.bin.dir=${app.server.tomcat.dir}/bin
app.server.tomcat.classes.global.dir=${app.server.tomcat.dir}/common/classes
app.server.tomcat.classes.portal.dir=${app.server.tomcat.portal.dir}/WEB-INF/classes
app.server.tomcat.deploy.dir=${app.server.tomcat.dir}/webapps
app.server.tomcat.lib.global.dir=${app.server.tomcat.dir}/common/lib/ext
app.server.tomcat.lib.portal.dir=${app.server.tomcat.portal.dir}/WEB-INF/lib
app.server.tomcat.portal.dir=${app.server.tomcat.deploy.dir}/ROOT
app.server.tomcat.log.dir=${app.server.tomcat.dir}/logs
app.server.tomcat.temp.dir=${app.server.tomcat.dir}/temp
app.server.tomcat.work.dir=${app.server.tomcat.dir}/work

Set the value of app.server.tomcat.lib.portal.dir to that of app.server.tomcat.lib.global.dir and now you have UCL in tomcat as well and you can then hot deploy JSP based themes.

Do the same for

app.server.tomcat.classes.global.dir and app.server.tomcat.classes.portal.dir
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 3:00 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Thanks man, this is good info. I will try tonight. If we are using the Enterprise version and want to go the the Pro version is there a lot of work or is it simply another build target in the EXT and a deployment of the War. I could RTFM ... If i dont here from you I'll assume its not a simple one line response and go see what I can find in the documentation.
Michael Young
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 4:41 PM
Answer

Michael Young

LIFERAY STAFF

Rank: Liferay Master

Posts: 847

Join Date: August 4, 2004

Recent Posts

It's just ext configuration in app.server.yourname.properties.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 6:11 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Rock and Roll
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 7, 2006 8:48 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

What did you guys do to get the Jasper to have access to do an <%@import X %> from one context to another... that seems to be my hangup

 1
 2
 303:45:17,592 ERROR [com.liferay.taglib.util.IncludeTag] org.apache.jasper.JasperException: /html/themes/ccsTemplate/templates/portal_normal.jsp(25,0) /html/themes/ccsTemplate/templates/portal_init.jsp(25,0) /html/themes/ccsTemplate/templates/init.jsp(25,0) File "/html/common/init.jsp" not found
 4        at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:39)
 5        at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:405)
 6        at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:86)
 7        at org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:339)
 8        at org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:372)
 9        at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:484)
10        at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1552)
11        at org.apache.jasper.compiler.Parser.parse(Parser.java:126)
12        at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:211)
13        at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100)
14        at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:155)
15        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:295)
16        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276)
17        at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264)
18        at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563)
19        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:303)
20        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
21        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
22        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
23        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
Mika Koivisto
RE: In Response to why hot deployable themes must be based on Velocity
August 8, 2006 12:40 AM
Answer

Mika Koivisto

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1513

Join Date: August 7, 2006

Recent Posts

Those /html/common/ files are not in the context of your theme war all you need to do is copy the /html/common files to your theme and voila it should work.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 8, 2006 5:26 AM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Mika Koivisto:
Those /html/common/ files are not in the context of your theme war all you need to do is copy the /html/common files to your theme and voila it should work.


Hi Mika, yep that would work but I am not sure I need to do that. I think there is a configuration I am missing someplace or the auto deployment model has changed too much. Given that Brian didn't bring that up, I'm guessing not. let's wait if we come up with some alternatives to copying those JSPs from portal land into the theme, atleast by hand.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 8, 2006 8:04 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Can someone tell me if this document is close or way out and if so where the problems. I think it is serving its purposes for us but I would like to make sure its correct and donate it to liferay as documentation (the kind we dont have but need if we want to attract community infrastructure developers). Don't turn away a willing documenter guys emoticon or free documentation
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 8, 2006 8:06 PM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Hrmmm that didnt work for us. We'll have to work through this for out 4.1.1 release. We are going to go-ahead with our current setup for now because we want to be out on 4.1.0 by late thursday evening.
Natalia Baranowska
RE: In Response to why hot deployable themes must be based on Velocity
August 16, 2006 4:47 AM
Answer

Natalia Baranowska

Rank: Junior Member

Posts: 39

Join Date: July 11, 2006

Recent Posts

Hi!
I am using Liferay 4.1 on Jboss+Tomcat and having problems with hot deploy.
When I deploy jsp themes (sample_pack_01_thames.war) deployer writes in console that everything is fine, nevertheless I can't see any new theme in look and feel page. Why? Am I doing sth. improperly?
Thanks in advance for info/tips!
Natalia
Brian Kim
RE: In Response to why hot deployable themes must be based on Velocity
August 16, 2006 7:21 AM
Answer

Brian Kim

LIFERAY STAFF

Rank: Expert

Posts: 319

Join Date: August 16, 2004

Recent Posts

Hey Russ,

What tool are you using to create that sequence diagram? I've been looking for a good alternative to Visio...
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 16, 2006 7:57 AM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

Brian Kim:
Hey Russ,

What tool are you using to create that sequence diagram? I've been looking for a good alternative to Visio...


Its visio. Unfortunately I have to admit I dont even use the UML sheets visio provides. I find that more often then not the fo-UML (just-enough-UML) is good enough to convey what I want to say. I have a bunch of stensils I use that I have put together over time to build the stuff quickly. All in all Visio is a horrible tool for real UML. Its good for whiteboarding.
Russ Danner
RE: In Response to why hot deployable themes must be based on Velocity
August 16, 2006 7:58 AM
Answer

Russ Danner

Rank: Regular Member

Posts: 149

Join Date: February 6, 2006

Recent Posts

This should continue to work in Jboss+Tomcat as long as the Universal Classloader is still enabled.
Natalia Baranowska
RE: In Response to why hot deployable themes must be based on Velocity
August 21, 2006 4:22 AM
Answer

Natalia Baranowska

Rank: Junior Member

Posts: 39

Join Date: July 11, 2006

Recent Posts

Yes, it works fine on JBoss due to UCL.

Thanks
Natalia