[MGNLETK-27] Multi site support and virtualURIMappings don't play nice together: can not resolve site definition Created: 12/May/10  Updated: 03/Jul/14  Resolved: 26/May/10

Status: Closed
Project: Extended Templating Kit (closed)
Component/s: None
Affects Version/s: 1.3
Fix Version/s: 1.3.1

Type: Bug Priority: Major
Reporter: Ernst Bunders Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: multisite, vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File config.sites.festivalsites.xml     XML File config.sites.pip.xml     Text File stacktraces.txt    
Issue Links:
causality
caused by MAGNOLIA-3204 aggregation state loses all informati... Closed
caused by MAGNOLIA-2015 VirtualURIFilter: forward to JSP page... Closed
caused by MAGNOLIA-2027 filters: improve forward and virtualU... Closed
dependency
depends upon MGNLSTK-622 Paging links are not correctly genera... Closed
relation
is related to MGNLSTK-623 Review all places where links are gen... Closed
is related to MGNLETK-28 multi-site support: fixing various is... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

This only happens when you are browning your site on the admin server, and have the site name in the url (no host mapping)

for instance: I have this page: http://localhost:8080/festival/event.html?name=Kasabian
on the public instance this page would get an ulr like this: festivalsite.vpro.nl/event.html?name=Kasabian
But our editors will see the site through the (production version of the) first link

the site root node name is 'festival' and the site def node name is 'festivalsites'

I create links to this page 'manually' , and i ran into the problem that I would have to know if the site name should be part of the url or not.
so i first obtain the content node of the site, and then use LinkUtil.createAbsoluteLink(siteNode) to create a valid link to the site root. then i add /the part to the event page.

My first surprise was that if you open the site from the admin central, the site name is used, like localhost:8080/festival, but the LinkUtil (used by all stk teasers) appends the site definition name in stead. But both seem to work, so OK.
so far so good.

But we also want to use virtalURIMappings, to create nice urls to this page (and page caching), like:
festivalsite.vpro.nl/event/Kasabian.html

so i created the virtualURIMapping, and it works well on url's without the sitename. It also works well on url's with the site name, like:
http://localhost:8080/festival/event/Kasabian.html

But, alas, the url i got from LinkUtil, doesn't have the site node name, but the site definition node name, so the url becomes:
http://localhost:8080/festivalsites/event/Kasabian.html

which throws an error:
get(cssFiles) failed on instance of info.magnolia.module.templatingkit.style.ThemeReference
The problematic instruction:
----------
==> list model.site.theme.cssFiles as cssFile [on line 18, column 1 in templating-kit/templates/global/htmlHeader.ftl]
in include def.htmlHeader.template [on line 8, column 4 in templating-kit/templates/main.ftl]

here is an xml dump from my virtualURIMapping configuration:

<?xml version="1.0" encoding="UTF-8"?>
<sv:node sv:name="events" xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<sv:property sv:name="jcr:primaryType" sv:type="Name">
<sv:value>mgnl:contentNode</sv:value>
</sv:property>
<sv:property sv:name="jcr:uuid" sv:type="String">
<sv:value>2e197e62-7451-4caf-bfe4-77248a7091f2</sv:value>
</sv:property>
<sv:property sv:name="class" sv:type="String">
<sv:value>info.magnolia.cms.beans.config.RegexpVirtualURIMapping</sv:value>
</sv:property>
<sv:property sv:name="fromURI" sv:type="String">
<sv:value>(.*)/event/([\w-]+)\.html</sv:value>
</sv:property>
<sv:property sv:name="toURI" sv:type="String">
<sv:value>forward:$1/event.html?name=$2</sv:value>
</sv:property>
<sv:node sv:name="MetaData">
<sv:property sv:name="jcr:primaryType" sv:type="Name">
<sv:value>mgnl:metaData</sv:value>
</sv:property>
<sv:property sv:name="mgnl:Data" sv:type="String">
<sv:value>MetaData</sv:value>
</sv:property>
<sv:property sv:name="mgnl:activated" sv:type="Boolean">
<sv:value>false</sv:value>
</sv:property>
<sv:property sv:name="mgnl:authorid" sv:type="String">
<sv:value>superuser</sv:value>
</sv:property>
<sv:property sv:name="mgnl:creationdate" sv:type="String">
<sv:value>2004-11-02T15:34:20.479+01:00</sv:value>
</sv:property>
<sv:property sv:name="mgnl:lastmodified" sv:type="Date">
<sv:value>2010-05-12T14:44:23.929+02:00</sv:value>
</sv:property>
</sv:node>
</sv:node>

For some reason the site definition and the related style can not be resolved. (don't know why)

by the way, http://localhost:8080/festivalsites/event.html?name=Kasabian works equally wel as http://localhost:8080/festival/event.html?name=Kasabian



 Comments   
Comment by Ernst Bunders [ 12/May/10 ]

I just found another bug that is closely related to this one.
The following thing happens:

  • if i open the 'tegenlicht' site from the admin central, i go to the url with the site node name in it: http://redactie.test.vpro.nl/tegenlicht/nieuws.html (the site node name is used in the url)
  • now i'm on the news overview page, with a lot of news, if i use the paging navigation to see the next/previous overview page, all is well: the site node name is in the url.
  • if i use any other navigation (section navigation, teasers), the url is created with the site definition name: http://redactie.test.vpro.nl/pip/afleveringen.html
  • so now i'm on the 'pip' variation. If i go back to the news overview page, and try the paging navigation again, I get urls like: http://redactie.test.vpro.nl/nieuws.html?currentPage=2
  • there is no site reference in the url any more, resulting in an error

It seems to me that site definition name should not be used. just stick to the site name, and all seams to be well.

Comment by Philipp Bärfuss [ 12/May/10 ]

To investigate upon that few things would be helpful:

  • stacktrace of the error
  • are you using ETK 1.3 or the 1.3.1-SNAPSHOT (in which we solved related issues so far)
  • attach an export of the site definitions: /modules/extended-templating-kit/config/sites

The site name is used to ensure that the site can be detected in the authoring environment. Two links are supported:

  • full path (for instance when you open a page in the website tree)
  • /sitename/shortened-uri (for rendereded content)

This kind of site-aware links were introduced to solve problems when you combine the mutlisite and i18n feature (the uri does not necessarily represent the content's path)

I don't know why this is failing in combination with virtual uri mappings but we will try to debug it.

In case you are not using the i18n feature you could disable the site aware links by doing the following:

--> change the value of /server/rendering/linkManagement/class from info.magnolia.module.extendedtemplatingkit.ETKLinkTransformerManager to info.magnolia.link.LinkTransformerManager

Jan wrote recently a blog post explaining that in more details for those who are interested: http://weblogs.java.net/blog/rah003/archive/2010/05/03/once-more-multi-site-support

Comment by Jan Haderka [ 13/May/10 ]

I'm not able to reproduce the exact issue, however I can confirm that VirtualUriFilter looses site information on forward:

This issue should be fixed in latest snapshot of ETK [1]. In order to deploy the fix, please replace the existing ETK jar with the snapshot and change the config://server/filters/virtualURI/class to info.magnolia.module.extendedtemplatingkit.filters.ETKVirtualUriFilter

In order to further investigate the original issue, please provide the info metioned by Philipp in the comment above.

[1] http:////repo.magnolia-cms.com/sites/repo/enterprise-snapshots/info/magnolia/magnolia-module-extended-templating-kit/1.3.1-SNAPSHOT/magnolia-module-extended-templating-kit-1.3.1-20100513.093142-6.jar

Comment by Jan Haderka [ 13/May/10 ]

Deployed latest snapshot at [1]
This snapshot should fix your problem even without need to reconfigure VirtualUriFilter.
However please note that without additional information from you I'm not able to fully confirm the fix.

[1] http://repo.magnolia-cms.com/sites/repo/enterprise-snapshots/info/magnolia/magnolia-module-extended-templating-kit/1.3.1-SNAPSHOT/magnolia-module-extended-templating-kit-1.3.1-20100513.154911-7.jar

Comment by Ernst Bunders [ 14/May/10 ]

hello Jan

I tried you new jar, but i can not see a difference. Both bugs are still there. I consider the fact that the site definition name is used in by magnolia to create links as the core of the problem, that is: both errors won't occur if the link is used with the site node name in stead of the site definition node name. but I'm not sure.

I attach a couple of files.

  • in stacktraces.txt i elaborate some on both bugs, and attach stacktraces to them.
  • config.sites.festivals.xml contains the site definition of the site with name 'festival'
  • config.sites.pip.xml contains the site definition of the site with name 'tegenlicht'

So, I hope this information is helpfull. Keep me posted. for us resolving this problem is top prioritoy, so if you need anything from me, let me know as soon as you can.

Comment by Ernst Bunders [ 14/May/10 ]

The promised files.

Comment by Jan Haderka [ 14/May/10 ]

Hi Ernst,

thanks for the additional info. I'm looking into it right now.

Jan

Comment by Jan Haderka [ 14/May/10 ]

One additional question - did you try switching off ETKLinkTransformerManager as suggested by Philipp?
And if not, can you please try?

Comment by Ernst Bunders [ 14/May/10 ]

hello Jan

I hadn't tried it yet indeed. I just did, and the following happens:

Is this enough information for you?

Comment by Jan Haderka [ 14/May/10 ]

Yes it is enough. I believe I found the real problem here.
If I'm correct using latest snapshot of ETK and changing extension in the link to jsp would cause it to work as expected - i.e. http://localhost:8080/festivalsites/event/Kasabian.jsp. In the past JSPs have been treated specially - context is not reset for them but kept instead. Since then we introduced FreeMarker rendering and IMHO we should treat all the redirects the same as those to JSP pages.

Comment by Ernst Bunders [ 14/May/10 ]

hello Jan

Do you want me to test this? if so:

  • should I test it with the ETKLinkTransformerManager or the LinkTransformerManager
  • should i reconfigure magnolia to serve freemarker on the jsp extension, and if so: how do i do that?

regards,

Ernst

Comment by Jan Haderka [ 14/May/10 ]

You can test it if you want. It is definitively the cause of failure of my local tests, but since our setup might not be exactly the same, it would be good if you can confirm it too.
Use the ETKLinkTransformerManager.
There is no additional configuration necessary for that. TemplateRenderer for rendering any given page is chosen from the type of the Template associated with the page. Extension is used only in special cases where you have more then one templates assigned to a page otherwise it is ignored.
So you can just change the LinkTransformerManager and then click on the link from my previous comment and it should work (with the latest (20100513.154911-7) snapshot of ETK).

Comment by Jan Haderka [ 14/May/10 ]

Nevermind, this will not fix your problem, there is a deeper issue which I need to tackle first.

Comment by Jan Haderka [ 14/May/10 ]

So to summarize:

  • there is a deeper issue involved related to resetting AggregationState completely and therefore removing all the Site related information on forward
  • fixing this issue has impact on other parts of the code such as URI2RepositoryMapping and has to be done in magnolia-core
  • temporary workaround for the issue (passing site info in the request) is implemented in [1] and can be tested (doesn't require any additional configuration changes. Use ETKLinkTransformerManager and default VirtualURIFilter
  • the second part of the issue (pagination) is reported as MGNLSTK-622 and MGNLSTK-623
  • I'll try to provide you with workaround for this problem shortly

[1] http://repo.magnolia-cms.com/sites/repo/enterprise-snapshots/info/magnolia/magnolia-module-extended-templating-kit/1.3.1-SNAPSHOT/magnolia-module-extended-templating-kit-1.3.1-20100514.150330-8.jar

Comment by Ernst Bunders [ 14/May/10 ]

Hello Jan

I'm a bit confused by your remarks. Assuming you are strictly talking about the virtualURIMapping problem: it already works provided that the site node name is in the url and not the site definition node name, as is the case with links generated by magnolia. So
http://localhost:8080/festival/event/test.html works (the page http://localhost:8080/festival/event.html?name=test is displayed)
but
http://localhost:8080/festivalsites/event/test.html does not.
The only difference is the festival vs. festivalsites part in the url, ie. the site node name vs. the site definition node name.

The second issue has similar characteristics. The wrong urls are created. Call the pages with the site node name in the url and problems are gone.

What am i missing?

Comment by Jan Haderka [ 14/May/10 ]

So http://localhost:8080/festival/event/test.html works (the page http://localhost:8080/festival/event.html?name=test is displayed)
but
http://localhost:8080/festivalsites/event/test.html does not.

With the latest snapshot both URLs should work. The one with site root node as well as the one with site definition name.

What you are missing is probably flow of what is happening behind the scene when using multisite and virtual uri mappings and how the URI is transformed to the handle in general. Without trying to get into too many details:

  • MultisiteFilter should resolve the site and remove all site specific info from the URIs (be it the site root node info or the site name)
  • VirtualURIFilter forwards/redirects to URI specified in the mapping (and is utterly unaware of any ops done on the URI prior its execution), possibly forcing re-execution of the whole chain
  • Site and URI2RepoMapping are used in the end to resolve the content

The whole issue is around the fact that while forwarding the request, VirtualURIFilter was also causing loss of the site information (due to cleanup actions triggered by forward ).
This latest snaphot has conatins 2 changes in comparison to trunk code - it keeps track of the resolved site definitions on forward and it also doesn't try to shorten the path, removing only the site info. The second part should not have impact on your problem, but I left it that way to make sure the VirtualURIMappings are not affected in case you are using some patterns the rely on the existence of the site root node name in the URI.

The second issue, while seemingly very similar, has completely different cause. It's caused by the fact that models were assembling links for pagination and navigation manually instead of using LinkUtil which knows is aware of the site related mappings.

Comment by Jan Haderka [ 14/May/10 ]

To deal with the second part of the issue (links on pagination) I've deployed the STK snapshot with the fix.
If you do not have demo-project installed on your server you can use the snaphot to replace existing magnolia-module-standard-templating-kit-1.3.1.jar.
In case you have demo-project installed, you need to extract info/magnolia/module/templatingkit/paragraphs/AbstractItemListModel.class and info/magnolia/module/templatingkit/paragraphs/EventsOverwievModel.class and place them to WEB-INF/lib folder to prevent the dependency conflict issues.

Comment by Ernst Bunders [ 17/May/10 ]

I'v been testing all morning and it is looking good! We are going to go ahead with these fixes.
Thanks for the effort. We keep testing, so perhaps it is a good idea to keep this issue open for another day or so.

Comment by Jan Haderka [ 17/May/10 ]

'v been testing all morning and it is looking good! We are going to go ahead with these fixes.

Thanks for the feedback.

Thanks for the effort. We keep testing, so perhaps it is a good idea to keep this issue open for another day or so.

Absolutely. I still don't consider issue fixed. What I did was just apply workaround for MultiSiteFilter to track Site itself so you can go ahead. This still need to be fixed at the AggregationState level before we can close this issue.

If you find any more issues with the multisite support let me know so we can include tests for it as well on top of all other tests already mentioned by Philipp.

Comment by Ernst Bunders [ 17/May/10 ]

One small request: would it be possible to create source jars for the snapshot jars as well? We use those quite extensively, especially the stk one. It is quite inconvenient to have to do without them.
Thanks

Comment by Jan Haderka [ 17/May/10 ]

Deployed STK and ETK again, both with sources this time.

Comment by Ernst Bunders [ 17/May/10 ]

For completeness: I add the contents of the mail i just sent here as well, as it appears to be caused by the etk snapshot jar

We are now experiencing a new problem: we can not activate content anymore.
It does not happen in all the workspaces (the simplemedia media
workspace works ok, for instance), but the website and data module are
affected.

I send you a piece of the stacktrace, which is very long, because
something starts to loop.

I did some tests, and learned the following:

  • with both stk and etk jars at production version, all is well
  • with stk jar at snapshot version: all is well
  • with etk jar at snapshop version: the described error occurs.

--------------------------------------------------------------------------------------
2010-05-17 15:48:21,782 WARN sun.reflect.NativeMethodAccessorImpl
: A deprecated class or method was used: The 'path' property
is deprecated: use t
he templatePath property instead. (current value:
/templating-kit/templates/main.ftl). Check the following trace:
info.magnolia.module.templating.Template.getPat
h(Template.java:73),
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), the full
stracktrace will be logged in debug mode in the info.magnolia.cms.util
.DeprecationUtil category.
2010-05-17 15:48:21,783 WARN info.magnolia.cms.util.DeprecationUtil
: A deprecated class or method was used: The 'path' property
is deprecated: use t
he templatePath property instead. (current value:
/templating-kit/templates/main.ftl). Check the following trace:
info.magnolia.module.templating.Template.getPat
h(Template.java:73),
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method), the full
stracktrace will be logged in debug mode in the info.magnolia.cms.util
.DeprecationUtil category.
A deprecated class or method was used: The 'path' property is
deprecated: use the templatePath property instead. (current value:
/templating-kit/templates/main.f
tl). Check the following trace:
info.magnolia.module.templating.Template.getPath(Template.java:73),
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
the full stracktrace will be logged in debug mode in the
info.magnolia.cms.util.DeprecationUtil category.
A deprecated class or method was used: The 'path' property is
deprecated: use the templatePath property instead. (current value:
/templating-kit/templates/main.f
tl). Check the following trace:
info.magnolia.module.templating.Template.getPath(Template.java:73),
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method),
the full stracktrace will be logged in debug mode in the
info.magnolia.cms.util.DeprecationUtil category.
2010-05-17 15:48:22,249 WARN
openwfe.org.engine.workitem.AttributeUtils : resolveGet()
failed to get value from getDAMSupport()
java.lang.StackOverflowError
at java.lang.String.<init>(String.java:433)
at java.io.UnixFileSystem.canonicalize0(Native Method)
at java.io.UnixFileSystem.canonicalize(UnixFileSystem.java:157)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.File.getCanonicalFile(File.java:555)
at org.apache.catalina.loader.WebappClassLoader.getURL(WebappClassLoader.java:2329)
at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:2007)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1786)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:890)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1354)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154)
at org.apache.log4j.Category.forcedLog(Category.java:388)
at org.apache.log4j.Category.warn(Category.java:1025)
at openwfe.org.engine.workitem.AttributeUtils.resolveGet(AttributeUtils.java:421)
at openwfe.org.engine.workitem.AttributeUtils.bean2owfe(AttributeUtils.java:396)
at openwfe.org.engine.workitem.AttributeUtils.java2owfe(AttributeUtils.java:355)
at openwfe.org.engine.workitem.AttributeUtils.resolveGet(AttributeUtils.java:414)
at openwfe.org.engine.workitem.AttributeUtils.bean2owfe(AttributeUtils.java:396)
at openwfe.org.engine.workitem.AttributeUtils.java2owfe(AttributeUtils.java:355)
at openwfe.org.engine.workitem.AttributeUtils.fillMap(AttributeUtils.java:480)
at openwfe.org.engine.workitem.AttributeUtils.map2owfe(AttributeUtils.java:451)
at openwfe.org.engine.workitem.AttributeUtils.java2owfe(AttributeUtils.java:335)
at openwfe.org.engine.workitem.AttributeUtils.resolveGet(AttributeUtils.java:414)
at openwfe.org.engine.workitem.AttributeUtils.bean2owfe(AttributeUtils.java:396)
at openwfe.org.engine.workitem.AttributeUtils.java2owfe(AttributeUtils.java:355)
at openwfe.org.engine.workitem.AttributeUtils.resolveGet(AttributeUtils.java:414)
at openwfe.org.engine.workitem.AttributeUtils.bean2owfe(AttributeUtils.java:396)

Comment by Ernst Bunders [ 18/May/10 ]

Yes, it works again. Thanks again.

Generated at Mon Feb 12 01:47:47 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.