-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MCR-2966 move saxon compatible stylesheets to folder xslt #1964
Conversation
move saxon xsls to xslt folder, add configuration variable for default xsl folder
add URI resolver for XEditor XSLs
add xsl to xslt folder
default to xsl3, remove -3 suffixes from configuration
fix class name for XEditor URI resolver
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bei den Imports verzichten wir noch beim Pfadanfang auf "/xslt" bzw. "/xsl"?
Auch wenn dadurch Dinge "kaputt" gehen, würde ich das gerne vereinheitlichen.
Die "Magie" sollte noch raus. Außerdem können wir so besser erkennen, ob es sich um alte oder neue Stylesheets handelt.
@@ -5,9 +5,9 @@ | |||
xmlns:fn="http://www.w3.org/2005/xpath-functions" | |||
xmlns:mcrsolr="http://www.mycore.de/xslt/solr"> | |||
|
|||
<xsl:import href="xslImport:solr-document-3:solr/indexing/mycoreobject-dynamicfields-3.xsl" /> | |||
<xsl:import href="xslImport:solr-document:solr/indexing/mycoreobject-dynamicfields.xsl" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, the path should also start with /xsl
or /xslt
to distinguish version 1 and version 3 XSL templates.
Or does that break to much existing code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, we cann not use resource:xslt/ in xslImport, since the respective URI resolver always adds a resource: on its own (https://github.com/MyCoRe-Org/mycore/blob/issues/MCR-2966-xslt-folder/mycore-base/src/main/java/org/mycore/common/xml/MCRURIResolver.java#L1400)
MCR.URIResolver.xslIncludes.xeditorTemplates=%MCR.URIResolver.xslIncludes.xeditorTemplates%,solr-xeditor-templates.xsl | ||
MCR.URIResolver.xslIncludes.xeditorTemplates-3=%MCR.URIResolver.xslIncludes.xeditorTemplates-3%,solr/xeditor/solr-xeditor-templates-3.xsl | ||
MCR.URIResolver.xslImports.solr-document=%MCR.URIResolver.xslImports.solr-document%,solr/indexing/mycoreobject-dynamicfields.xsl | ||
MCR.URIResolver.xslIncludes.xeditorTemplates=%MCR.URIResolver.xslIncludes.xeditorTemplates%,solr/xeditor/solr-xeditor-templates.xsl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, the path should also start with /xsl
or /xslt
to distinguish version 1 and version 3 XSL templates.
Or does that break to much existing code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as abvoe: xlsImport does not allow for adding resource:xsl/ or /xslt/ in the beginning. I would suggest to adapt these references in a separate PR after we added this.
Ja wäre ich auch dafür. Das haben wir momentan noch raus gelassen, um den Umstieg etwas sanfter zu machen. Nehmen wir die vollständige Angabe mit resource:xslt/... müssen in allen Anwendungen, die 2023 und XSL1 verwenden, noch mehr an der Konfiguration angepasst werden als ohnehin schon - siehe die Mail, du warst zu schnell ;) |
use folder from configuration, use full resource statement for xeditor XSL
process new xslImport mechanism
final String baseURI = getParentDirectoryResourceURI(base); | ||
// set xslt folder | ||
final String xslFolder; | ||
if (StringUtils.contains(baseURI, "/xsl/")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
baseURI.startswith would work more secure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand this correctly, getParentDirectoryResourceURI always returns a string starting with resource (https://github.com/MyCoRe-Org/mycore/blob/2022.06.x/mycore-base/src/main/java/org/mycore/common/xml/MCRURIResolver.java#L293)
e.g.:
base: jar:file:/home/musiclpz/production/build/webapps/WEB-INF/lib/mycore-solr-2023.08-SNAPSHOT.jar!/xslt/solr/indexing/mycoreobject-dynamicfields.xsl
baseuri: resource:xslt/solr/indexing/
so startsWith resource:xsl/ should be feasible.
However, in some edge cases getParentDirectoryResourceURI returns the given base. In these cases, this would not work. But I am not totally aware if in these cases something else goes wrong. If we can ignore these edge cases, we can test on startsWith resource:xsl/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand this correctly, getParentDirectoryResourceURI always returns a string starting with resource (https://github.com/MyCoRe-Org/mycore/blob/2022.06.x/mycore-base/src/main/java/org/mycore/common/xml/MCRURIResolver.java#L293)
e.g.:
base: jar:file:/home/musiclpz/production/build/webapps/WEB-INF/lib/mycore-solr-2023.08-SNAPSHOT.jar!/xslt/solr/indexing/mycoreobject-dynamicfields.xsl
baseuri: resource:xslt/solr/indexing/
Yes you are right.
However, in some edge cases getParentDirectoryResourceURI returns the given base. In these cases, this would not work. But I am not totally aware if in these cases something else goes wrong. If we can ignore these edge cases, we can test on startsWith resource:xsl/
I think in the edge cases the property should be used. So check for startsWith resource:xsl/ or resource:xslt/ and if both false than use the property.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed to startsWith resource:xsl/ / resource:xslt/
I had to rollback the changes in nextImportStep, since it produced errors when using the proposed new xslImport syntax (without selfname). This resulted in errors because xsl:import href="xslImport:xxx" was included more than once and ultimately failed with a stylesheet including itself. I was not able to fix this and, thus. would suggest to postpone the syntax change to a later point.
|
||
importXSL = MCRXMLFunctions.nextImportStep(importPart); | ||
} else { | ||
final String selfName = StringUtils.substringAfter(baseURI, xslFolder + "/") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe more secure to use baseURI.substring(xslFolder.length+1)
use startsWith for evaluating folder, fallback via configuration; reverse xmlfunctions:nextImportStep
remove test for new xslimport mechanism
Falls weiterhin XSLT-1 verwendet werden soll, sind folgende Anpassungen an der Konfiguration vorzunehmen:
Anwendungen, die schon auf XSLT3 umgestellt sind, brauchen folgende Einträge:
|
move saxon xsls to xslt folder, add configuration variable for default xsl folder
add URI resolver for XEditor XSLs
add xsl to xslt folder
default to xsl3, remove -3 suffixes from configuration
fix class name for XEditor URI resolver
use folder from configuration, use full resource statement for xeditor XSL
process new xslImport mechanism
use startsWith for evaluating folder, fallback via configuration; reverse xmlfunctions:nextImportStep
remove test for new xslimport mechanism
…o issues/MCR-2966-xslt-folder
…folder # Conflicts: # mycore-base/src/test/java/org/mycore/common/xml/MCRURIResolverTest.java
fix code style
add response-browse content transformer for XSLT3
remove duplicate parameter from msie-warnings.xsl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works with MIR branch MyCoRe-Org/mir#913
* 2023.06.x: MCR-2647 hibernate 6 jpa 3.1 (#1587) MCR-2959 fix property guid xslt directory MCR-2964 [jobqueue] update yarn dependencies MCR-2966 move saxon compatible stylesheets to folder xslt (#1964) MCR-2990 Added support of <xinclude @uri="..."/> element. (#1988) MCR-2993 Fixed NullPointerException MCR-2995 always return Source with systemId (#1995) MCR-2998 add save-xsl to xslt folder (#1997) MCR-3000 fix exception in MCRACLResolver on factbased access system (#2000) MCR-3002 Fix Javadoc for log4j2 (#2008) MCR-2995 always return Source with systemId (#1995) MCR-3002 fix log4j2 javadoc URL MCR-3003 jobs in queue do not trigger onCommitTasks Revert "MCR-3002 fix log4j2 javadoc URL"
* UBO-283 Set mycore version to 2022.06.3-SNAPSHOT * UBO-283 Fixed compile errors * UBO-283 Removed deprecated api invocation * UBO-283 Replaced deprecated StringUtils.getLevenshteinDistance() with LevenshteinDistance.getDefaultInstance().apply(normalizeTitle(titleFromAleph), normalizeTitle(titleFromBibEntry)).intValue() * UBO-283 Moved basket2solradd.xsl and solr2csv.xsl to /xslt. Set TransformerFactoryClass for xslt 1 stylesheets * UBO-283 Include variable $User-Agent in html-layout.xsl to avoid blank landing page * UBO-283 Added configuration as mentioned in MyCoRe-Org/mycore#1964 (comment) * UBO-283 Added mapping files in persistence.xml * UBO-283 Curly braces must now be encoded in json.facet * UBO-283 Improved readability of added properties * UBO-291 Use h2 for testing * UBO-291 Set mycore version to 2023.06.1-SNAPSHOT * UBO-291 Sort poms * UBO-291 Added sort pom plugin * UBO-291 Removed property "<property name="hibernate.dialect" value=" org.hibernate.dialect.H2Dialect"/>" from persistence.xml * UBO-291 Fixed persistence.xml * UBO-291 Set mycore version to 2023.06.2-SNAPSHOT * UBO-283 Fixed compile error and sort pom.xml * UBO-283 Migrated to MCRJobQueue to MCRJobQueueManager * UBO-283 Set mycore version to 2023.06.03-SNAPSHOT * UBO-283 Updated ImportListJobAction to mycore version 2023.06.x * UBO-283 delete obsolete language classification, update versions and installation documentation --------- Co-authored-by: Kathleen Neumann <[email protected]>
Link to jira.
The following changes were made: