I suppose your patch will break a lot of modifications I made to the java code.
The rationale of milestone (1) is that all references to files, resources and anything else in APLAWS is strictly made relative to document root rsp. the web application context
All modifications / configurations regarding the servlet container and where to install APLAWS (in which context) are the responsibility of the container / the container administrator / the container's webapp installation tool. Nothing at all that APLAWS should care about.
In some situations we need the full file system path to a file or resource (esp. during installation / initial configuration and while using the test machinery I suppose), and we need the path to the APLAWS web context. That is ccm.home in the logik of milestone (1).
Currently ccm.home is fixed ${app.server.webapp.dir}/ROOT. As soon as I've finished the work on the URL resource: protocol (I suppose I will provide a patch today in the evening) I will start to make APLAWS installable in any arbitrary directory, specified in project.xml webapp tag or during installation time. This involves a massive rewriting of xsl files and a lot of work in web.xml and the dispatcher magic and may take some time.
So ccm.home will become: ${app.server.webapp.dir}/${ccm:project.webapp}
See milestone (1) and related tickets for details.
Well, I suppose I should start to write a new developer guide as soon as possible.
In which situations do we need ccm.home pointing to the servlet containers home dir?
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I will start to make APLAWS installable in any arbitrary directory, specified in project.xml webapp tag or during installation time. This involves a massive rewriting of xsl files and a lot of work in web.xml and the dispatcher magic and may take some time.
Peter, I have already done work to get APLAWS to run under a context other than root. It does not require a massive rewrite of xsl files. The xsl files get loaded through the templating system which will look for the xsl files under the context defined with the web.context (from memory) registry configuration setting.
I can help you with the changes that do need to be made. Their aren't that many as far as getting it to run is concerned. I'm going to be away for several days but can provide a path when I get back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it would be very very helpful if you could contribute your experiences and provide a patch. Your patch regarding ResourceParameter was the "breakthrough" to get the problem resolved.
Regarding rewriting of xsl files: I had (rather) a short look into some files and found a huge amount of references to other xsl files (includes) which contain the ROOT directory as a fix part of the path. So I suppose we have to have a look into every file (or let grep do that) to check for absolute path specifications.
My idea is: if we have to look into nearly every xsl file, we should use that occasion to thorougly clean up the web directory structure as well. Currently it's really a mess. Files a spread all over the directory, functional identical files are stored at different locations, some files are doubled at different locations, theme files are mixed with logic files, etc.
It is nearly impossible to maintain such a code structure. But in order to improve APLAWS's usability, we must lay emphasis on themes / easy themability. That involves a lot of maintenance work.
A possible structure of the web dir might be:
- themes
- themes/internal (assembles all the files of the current build-in "theme")
- themes/mandalay (the new, modularized and easy configurable theme developed in Bremen)
- themes/public (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/devel (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/default (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/aplaws (current default theme)
You must be refering to packages other than ccm-core or ccm-cms. I do not use the other packages so don't know about how they include other XML templates.
In the XML templates for ccm-core and ccm-cms I had to replace the <a href="/somefile"> urls with <a href="{$context-prefix}/somefile">. For APLAWS applications that I developed myself that run outside of the APLAWS context I modified com.arsdigita.templating.SimpleURIResolver. This class is used by the TransformerFactory that the XSL Templates use to resolve the location of the XML template files. I used "/@ccm_context@" as a special string in the include which gets replaced by the APLWAS context in SimpleURIResolver. You can follow a similar method to resolve the other XML includes to suit your needs for the other apps, no need to edit the XML template files.
I don't have time now but some time next week I should be able to get a patch file together which allows the core APLAWS to run under a context other than ROOT.
Thanks,
Brett
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
| You must be refering to packages other than ccm-core or ccm-cms.
| I do not use the other packages so don't know about how they
| include other XML templates.
Yes indeed, mostly those packages which used to install into their own web context as ccm-userpreferences, or ccm-ldn-themes as an example. They contain include statements like "../../../../ROOT/static/.......", because they directly use resources from modules installed into ROOT (and vice versa) - very strange design.
I startet to check all the xml files and to remove all absolute adressing.
I studied your hints about SimpleURIResolver - and I'm wondering a little bit about the design decisions behind it. I think XML templates, which render a xml information to html, are very private to the module which maintains that information. It should never be used by any other module directly, and even more so by another web application (if there is a need to access that information, an jee service or a content type as proxy site or xmlfeed should be used). So I would expect a real "Simple" way would be to resolve any xsl template as a resource relative to it's own context.
Things are even worse with the parameter waf.web.server, which must contain the correct url including the port, otherwise c.ad.templating.XSLTemplate can not find the resource (fails at line 100). I suppose, an application user should not be forced to take the system administrators cnfiguration philosophy into account. Why not fetch it from the we applications context?
Even more worse with c.ad.caching.CacheServlet. It reads the host's name and port from a persistent database table (we have no maintenance tool as to my knowledge). So every time the system administrator modifies e.g. the port, we either produce a bunch of log errors or we have to manually edit the database.
Do you have a solution / idea for these latter two issue as well? I'm eager to study your patch.
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I think XML templates, which render a xml information to html, are very private
> to the module which maintains that information. It should never be used by any
> other module directly, and even more so by another web application
The problem is that the presentation layer depends upon Bebop XSLT in ccm-core. Each module should be able to run in its own context but it also needs to access the core XSLT components of Bebop. I don't think each individual module should have it's own copy of the core resources.
> if there is a need to access that information, an jee service or a content type
> as proxy site or xmlfeed should be used
The stylesheet-paths.txt file describes where to look for these resources and by default points to the resource-resolver servlet through an absolute URL. The templating system translates this into a call to resolve the resource from the local context to optimize resource lookup.
> Why not fetch it from the we applications context?
It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource can be lookup up in multiple contexts.
> Even more worse with c.ad.caching.CacheServlet. It reads the host's name and
> port from a persistent database table
I've never had to change these values so haven't run into this problem. It's used to support clustering I suppose. I haven't ever looking into it since I've never changed the host name or used clustering.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> The problem is that the presentation layer depends upon Bebop XSLT in ccm-core.
> Each module should be able to run in its own context but it also needs to access the core XSLT
> components of Bebop. I don't think each individual module should have it's own copy of the core resources.
Is it really true, that each module should be able to run in its own context? I asked on the forum and tried hard to find a reason for it.
E.g. why should ccm-ldn-theme run in its own context? By design (i.e. the xml include mechanism) it provides services for just one web application, that one that is running in ROOT. Nothing else. It used to store all the themes in its own context, but a theme is very specific to a web application, no one wants to mix themes between several web applications.
Of course, several web applications might use the services, the module ccm-ldn-themes provides. Therefore, the jar files might be / should be stored in the containers shared lib directory so it can be used by any web application. But each web application will store the themes in its ówn context (xsl but also logo, images and other private or specific things the webapp might not be willing to share). And it will store the theme of the admin interface in its own context and might whish to modify or redesign it.
As to my knowledge version 5 of APLAWS was a JEE application, were all modules were installed into one context (ccm). Do you know, WHY that had been changed? I suppose I never understood this design decision.
Currently, the development system had been changed so that all modules are installed into one context which is specified in project.xml. If there is a requirement, that a module should run in its own context, I have to adjust the build-template.xsl.
Just another topic: If each module is dependent from resources in core, I suppose it is an example of (very) strong coupling. So it should not divided into different modules (at least according to theory :-) )
> It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource
> can be lookup up in multiple contexts
That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context, we have to find a solution.
Therefore the question is: Is it essential for your usage of APLAWS / CCM that each module is able to run in its own context,
or is it sufficient that jar files are stored in a shared directory
or can we determine specific circumstances for the requirement to run in ist own context (some sort of special kind or types of modules) for which we can develope a solution for the include directive in xsl files (of make them unneccessary).
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Is it really true, that each module should be able to run in its own context?
I don't see modules necessarily as being an extension to the existing functionality. A module can provide completely new and independent functionality. Developers should be able to use the core as a lower level framework for their own applications. This is what I use the code for. I tap into the user/group/permission functionality and dispatcher and templating mechanism to create multiple themable instances of my applications. Beyond that, the software I've developed stands on its own. Having each module in it's own context also makes it truly modular. You don't have to merge the moduals web.xml in with the core web.xml. This also allows you to undeploy/redeploy individual moduals without having to undeploy/redeploy the entire system. Those are the main benefits I see in having modules in their own context. I don't think each module has to be in its own context but when a module provides new application services that simply rely on the core for lower level API it's nice of have that capability.
> a theme is very specific to a web application, no one wants to mix themes between several web applications.
Why not? In an enterprise environment you want all of you applications to have the same look and feel.
> As to my knowledge version 5 of APLAWS was a JEE application, were all modules were installed into one
> context (ccm). Do you know, WHY that had been changed? I suppose I never understood this design decision.
I'm not sure why. The code used the c.a.sitenode.SiteNodeDispatcher to locate the package dispatcher to handle the request. That was deprecated in favor of the c.a.web.DispatcherServlet which tries to forward the request to a servlet defined in c.a.web.Application. The new dispatcher mechanism is more flexible and allows the application to reside in a different context. My guess is that it makes the moduals more plug and play.
> Just another topic: If each module is dependent from resources in core, I suppose it is an example of
> (very) strong coupling. So it should not divided into different modules (at least according to theory :-) )
I see core as being a lower level web framework that should be in a shared jar. I think much of whats in their can/should be replaced with other competing technologies that are maintained as independent projects. What should stay are the things that make APLAWS+ truly unique like the way it handles users/groups/permissions and dispatches modules in a way that facilitates multiple instances of an application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> > It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource
> > can be lookup up in multiple contexts
> That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim
> which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context,
> we have to find a solution.
Sorry, I forgot that you already developed a solution for this part.
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Terry,
I suppose your patch will break a lot of modifications I made to the java code.
The rationale of milestone (1) is that all references to files, resources and anything else in APLAWS is strictly made relative to document root rsp. the web application context
All modifications / configurations regarding the servlet container and where to install APLAWS (in which context) are the responsibility of the container / the container administrator / the container's webapp installation tool. Nothing at all that APLAWS should care about.
In some situations we need the full file system path to a file or resource (esp. during installation / initial configuration and while using the test machinery I suppose), and we need the path to the APLAWS web context. That is ccm.home in the logik of milestone (1).
Currently ccm.home is fixed ${app.server.webapp.dir}/ROOT. As soon as I've finished the work on the URL resource: protocol (I suppose I will provide a patch today in the evening) I will start to make APLAWS installable in any arbitrary directory, specified in project.xml webapp tag or during installation time. This involves a massive rewriting of xsl files and a lot of work in web.xml and the dispatcher magic and may take some time.
So ccm.home will become: ${app.server.webapp.dir}/${ccm:project.webapp}
See milestone (1) and related tickets for details.
Well, I suppose I should start to write a new developer guide as soon as possible.
In which situations do we need ccm.home pointing to the servlet containers home dir?
Peter
ant start worked
ant load-bundle put the configuration under webapps/ROOT/webapps/ROOT/WEB-INF/conf
'Hm, seems to be another example where my svn didn't work. I will have a look into it.
But can we agree about the underlying rationale?
Peter
> I will start to make APLAWS installable in any arbitrary directory, specified in project.xml webapp tag or during installation time. This involves a massive rewriting of xsl files and a lot of work in web.xml and the dispatcher magic and may take some time.
Peter, I have already done work to get APLAWS to run under a context other than root. It does not require a massive rewrite of xsl files. The xsl files get loaded through the templating system which will look for the xsl files under the context defined with the web.context (from memory) registry configuration setting.
I can help you with the changes that do need to be made. Their aren't that many as far as getting it to run is concerned. I'm going to be away for several days but can provide a path when I get back.
Hi Brett,
it would be very very helpful if you could contribute your experiences and provide a patch. Your patch regarding ResourceParameter was the "breakthrough" to get the problem resolved.
Regarding rewriting of xsl files: I had (rather) a short look into some files and found a huge amount of references to other xsl files (includes) which contain the ROOT directory as a fix part of the path. So I suppose we have to have a look into every file (or let grep do that) to check for absolute path specifications.
My idea is: if we have to look into nearly every xsl file, we should use that occasion to thorougly clean up the web directory structure as well. Currently it's really a mess. Files a spread all over the directory, functional identical files are stored at different locations, some files are doubled at different locations, theme files are mixed with logic files, etc.
It is nearly impossible to maintain such a code structure. But in order to improve APLAWS's usability, we must lay emphasis on themes / easy themability. That involves a lot of maintenance work.
A possible structure of the web dir might be:
- themes
- themes/internal (assembles all the files of the current build-in "theme")
- themes/mandalay (the new, modularized and easy configurable theme developed in Bremen)
- themes/public (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/devel (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/default (maintained by ccm-themesmanager aka ccm-ldn-themes)
- themes/aplaws (current default theme)
- scriptlib
- scriptlib/xinha
- scriptlib/fckeditor
- scriptlib/other Javascript
- templates (jsp per module)
- WEB-INF
I suppose you concentrated on the web.xml file and the dispatcher configuration. So we could split the work.
Peter
Peter,
You must be refering to packages other than ccm-core or ccm-cms. I do not use the other packages so don't know about how they include other XML templates.
In the XML templates for ccm-core and ccm-cms I had to replace the <a href="/somefile"> urls with <a href="{$context-prefix}/somefile">. For APLAWS applications that I developed myself that run outside of the APLAWS context I modified com.arsdigita.templating.SimpleURIResolver. This class is used by the TransformerFactory that the XSL Templates use to resolve the location of the XML template files. I used "/@ccm_context@" as a special string in the include which gets replaced by the APLWAS context in SimpleURIResolver. You can follow a similar method to resolve the other XML includes to suit your needs for the other apps, no need to edit the XML template files.
I don't have time now but some time next week I should be able to get a patch file together which allows the core APLAWS to run under a context other than ROOT.
Thanks,
Brett
Brett,
| You must be refering to packages other than ccm-core or ccm-cms.
| I do not use the other packages so don't know about how they
| include other XML templates.
Yes indeed, mostly those packages which used to install into their own web context as ccm-userpreferences, or ccm-ldn-themes as an example. They contain include statements like "../../../../ROOT/static/.......", because they directly use resources from modules installed into ROOT (and vice versa) - very strange design.
I startet to check all the xml files and to remove all absolute adressing.
I studied your hints about SimpleURIResolver - and I'm wondering a little bit about the design decisions behind it. I think XML templates, which render a xml information to html, are very private to the module which maintains that information. It should never be used by any other module directly, and even more so by another web application (if there is a need to access that information, an jee service or a content type as proxy site or xmlfeed should be used). So I would expect a real "Simple" way would be to resolve any xsl template as a resource relative to it's own context.
Things are even worse with the parameter waf.web.server, which must contain the correct url including the port, otherwise c.ad.templating.XSLTemplate can not find the resource (fails at line 100). I suppose, an application user should not be forced to take the system administrators cnfiguration philosophy into account. Why not fetch it from the we applications context?
Even more worse with c.ad.caching.CacheServlet. It reads the host's name and port from a persistent database table (we have no maintenance tool as to my knowledge). So every time the system administrator modifies e.g. the port, we either produce a bunch of log errors or we have to manually edit the database.
Do you have a solution / idea for these latter two issue as well? I'm eager to study your patch.
Peter
> I think XML templates, which render a xml information to html, are very private
> to the module which maintains that information. It should never be used by any
> other module directly, and even more so by another web application
The problem is that the presentation layer depends upon Bebop XSLT in ccm-core. Each module should be able to run in its own context but it also needs to access the core XSLT components of Bebop. I don't think each individual module should have it's own copy of the core resources.
> if there is a need to access that information, an jee service or a content type
> as proxy site or xmlfeed should be used
The stylesheet-paths.txt file describes where to look for these resources and by default points to the resource-resolver servlet through an absolute URL. The templating system translates this into a call to resolve the resource from the local context to optimize resource lookup.
> Why not fetch it from the we applications context?
It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource can be lookup up in multiple contexts.
> Even more worse with c.ad.caching.CacheServlet. It reads the host's name and
> port from a persistent database table
I've never had to change these values so haven't run into this problem. It's used to support clustering I suppose. I haven't ever looking into it since I've never changed the host name or used clustering.
Hi Brett,
> The problem is that the presentation layer depends upon Bebop XSLT in ccm-core.
> Each module should be able to run in its own context but it also needs to access the core XSLT
> components of Bebop. I don't think each individual module should have it's own copy of the core resources.
Is it really true, that each module should be able to run in its own context? I asked on the forum and tried hard to find a reason for it.
E.g. why should ccm-ldn-theme run in its own context? By design (i.e. the xml include mechanism) it provides services for just one web application, that one that is running in ROOT. Nothing else. It used to store all the themes in its own context, but a theme is very specific to a web application, no one wants to mix themes between several web applications.
Of course, several web applications might use the services, the module ccm-ldn-themes provides. Therefore, the jar files might be / should be stored in the containers shared lib directory so it can be used by any web application. But each web application will store the themes in its ówn context (xsl but also logo, images and other private or specific things the webapp might not be willing to share). And it will store the theme of the admin interface in its own context and might whish to modify or redesign it.
As to my knowledge version 5 of APLAWS was a JEE application, were all modules were installed into one context (ccm). Do you know, WHY that had been changed? I suppose I never understood this design decision.
Currently, the development system had been changed so that all modules are installed into one context which is specified in project.xml. If there is a requirement, that a module should run in its own context, I have to adjust the build-template.xsl.
Just another topic: If each module is dependent from resources in core, I suppose it is an example of (very) strong coupling. So it should not divided into different modules (at least according to theory :-) )
> It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource
> can be lookup up in multiple contexts
That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context, we have to find a solution.
Therefore the question is: Is it essential for your usage of APLAWS / CCM that each module is able to run in its own context,
or is it sufficient that jar files are stored in a shared directory
or can we determine specific circumstances for the requirement to run in ist own context (some sort of special kind or types of modules) for which we can develope a solution for the include directive in xsl files (of make them unneccessary).
Peter
> Is it really true, that each module should be able to run in its own context?
I don't see modules necessarily as being an extension to the existing functionality. A module can provide completely new and independent functionality. Developers should be able to use the core as a lower level framework for their own applications. This is what I use the code for. I tap into the user/group/permission functionality and dispatcher and templating mechanism to create multiple themable instances of my applications. Beyond that, the software I've developed stands on its own. Having each module in it's own context also makes it truly modular. You don't have to merge the moduals web.xml in with the core web.xml. This also allows you to undeploy/redeploy individual moduals without having to undeploy/redeploy the entire system. Those are the main benefits I see in having modules in their own context. I don't think each module has to be in its own context but when a module provides new application services that simply rely on the core for lower level API it's nice of have that capability.
> a theme is very specific to a web application, no one wants to mix themes between several web applications.
Why not? In an enterprise environment you want all of you applications to have the same look and feel.
> As to my knowledge version 5 of APLAWS was a JEE application, were all modules were installed into one
> context (ccm). Do you know, WHY that had been changed? I suppose I never understood this design decision.
I'm not sure why. The code used the c.a.sitenode.SiteNodeDispatcher to locate the package dispatcher to handle the request. That was deprecated in favor of the c.a.web.DispatcherServlet which tries to forward the request to a servlet defined in c.a.web.Application. The new dispatcher mechanism is more flexible and allows the application to reside in a different context. My guess is that it makes the moduals more plug and play.
> Just another topic: If each module is dependent from resources in core, I suppose it is an example of
> (very) strong coupling. So it should not divided into different modules (at least according to theory :-) )
I see core as being a lower level web framework that should be in a shared jar. I think much of whats in their can/should be replaced with other competing technologies that are maintained as independent projects. What should stay are the things that make APLAWS+ truly unique like the way it handles users/groups/permissions and dispatches modules in a way that facilitates multiple instances of an application.
Brett,
> > It is fetched from the applications context. Using the ::webapps:: variable in stylesheet-paths.txt the resource
> > can be lookup up in multiple contexts
> That works very well for the core dispatcher, but does not work inside of xml files (include directive, a mechansim
> which is widely used in APLAWS). Therefore, if we decide that every module must be able to run in its own context,
> we have to find a solution.
Sorry, I forgot that you already developed a solution for this part.
Peter