on 2018 May 25 5:04 PM
We are running a configuration with multiple hybris 6.7 storefront applications, each having its own "storefront" extension.
Each storefront has its own set of addons installed (b2b, b2c). With each addon, comes a set of js and css files that the storefront then relies on. On top of that, the hybris-made wrapper for WRO4J is supposed to group together and compress these web resources(css/js).
We have had issues on one B2B storefront not importing expected js resources, to realize that web resources were fetched from another (B2C) storefront, thus lacking b2b-specific resources (js in our current case). The generated wro model processed by the wro ResourceBundleProcessor was also the one from the B2C storefront.
Our conclusion is that out-of-the-box, wro configuration not working on multiple storefront.
2 reasons (at least) have been identified (so far):
The property storefront.wro4j.enabled to enable WRO processing is not storefront-specific: if storefronts use different settings, you can't know which setting will be applied
WRO processing is based on the file storefront-extensions own wro.xml but the way this wro.xml is dynamically fetched is not storefront-specific: the css/js resources from addons are imported by a directive: classpath:wro_addons.xml. Obvisously, that is not ok when having multiple storefront, as you can't know for sure which model(wro.xml) will be fetched having multiple resources of the same name in the classpath. WRO allows a servletContext aware type of import, which unfortunately is of no use here as the wro_addons.xml file is not part of the web context (it is placed in the resources folder)
We haven't identified a clean - ie: 100% out-of-the-box 0% hybris hacking- way of solving this issue. The "hacking way" of solving the issue is obviously to ensure
that each storefront has it own properties and
that each storefront has its own uniquely-identified model(wro.xml) including uniquely-identified wro_addons resources (by naming them differently or by copy-pasting them at an appropriate place)
Have you experienced this issue yourself? Did you guys find a "clean" way of solving this issue?
Thanks for your feedback!
Request clarification before answering.
Hi, I think the clean solution is as you mentioned, having storefront specific properties for each storefront extension.
I don't think this approach is a "hacking way", since its just a property change. Just change the name of the property in ConfigWro4jBeforeViewHandler and you're good to go. Hope it helps!
Cheers!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.