AEM - Versioned clientlibs configuration conflict - osgi

I'm having a problem with two htmlwriter configurations: one for the versioned clientlibs and the other for link rewriting.
Only the configuration with the higher order is working, excluding the other one.
I've tried also combining them as explained in this other question, but it doesn't work for me, since the versioned clientlibs stopped working.
Is there a way to make two htmlwriter configurations work together ?
Edit - Adding my merged configuration:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="nt:unstructured"
contentTypes="text/html"
enabled="{Boolean}true"
generatorType="htmlparser"
order="5000"
paths="/content/mysite"
serializerType="htmlwriter"
transformerTypes="[linktype,linkchecker,versioned-clientlibs]">
<generator-htmlparser
jcr:primaryType="nt:unstructured"
includeTags="[A,OPTION]"/>
</jcr:root>

Related

Apache CXF SOAP JAXB issue on WebLogic 12c

We are using Java 8, Apache CXF as a SOAP client on top of Spring Boot to send SOAP messages to WS.
If the app is deployed as a WAR on Tomcat 8, the app works well and the SOAP client is sending the right XML messages with the right namespaces.
If the same app WAR is deployed on Weblogic 12c the SOAP message that is produced by the CXF SOAP client has missing namespaces.
We know that the WebLogic maybe uses some old JAXB jars that are responsible for creating the XML message from Java objects and they are different then the Tomcat server and this maybe the reason why we are seeing this issue.
We also know that we can specify in the weblogic.xml in the war file what jars the Weblogic needs to load from the war and what dependencies to load from directly from the Weblogic libraries, but every combination that we tried in the weblogic.xml does not work.
Any good advice will be fully appreciated
Sample XML output from Tomcat server with Apache CXF
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<event xmlns="http://www.test.com" xmlns:ns5="http://www.test2.com" xmlns:ns3="urn:test1:1423.15465:123123:namespace">
<ns5:created-date-time>2020-08-12T08:02:35Z</ns5:created-date-time>
<ns5:payload>
<Test2>
<ns3:ID>f14bb</ns3:ID>
<ns3:createdDateTime>2020-08-12T08:02:35Z</ns3:createdDateTime>
</Test2>
</ns5:payload>
</event>
</env:Body>
</env:Envelope>
Sample code from Weblogic 12c
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<event xmlns="http://www.test.com" xmlns:ns5="http://www.test2.com">
<ns5:created-date-time>2020-08-12T08:02:35Z</ns5:created-date-time>
<ns5:payload>
<Test2>
<ID>f14bb</ID>
<createdDateTime>2020-08-12T08:02:35Z</createdDateTime>
</Test2>
</ns5:payload>
</event>
</env:Body>
</env:Envelope>
The "urn:test1:1423.15465:123123:namespace" is completely ignored in the weblogic server making this XML message not valid by the consumer
weblogic.xml
we are trying to tell weblogic to load our classes from the war file instead of the JaxB classes from the web logic but without success
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>java.xml.bind.*</wls:package-name>
<wls:package-name>org.apache.cxf.*</wls:package-name>
<wls:package-name>javax.xml.ws.*</wls:package-name>
<wls:package-name>javax.wsdl.*</wls:package-name>
</wls:prefer-application-resources>
</wls:container-descriptor>
Except this issue everything else is working fine, the Apache CXF is sending correct in multiple scenarios, just in one is it not adding the namespace we need
It looks like you are describing a class loading problem here. Thus, kindly use the below tag in your weblogic.xml descriptor.
<prefer-web-inf-classes>false</prefer-web-inf-classes>
Some years ago I was struggling with class loading issues because I was missing it. Below you have an example about this extracted from this blog.
If after applying this you still are facing issues with the class loader, you should install Classloader Analysis Tool (CAT) to get the class loader, which is loading the conflicting classes. In this blog you will have some instructions about how to use CAT.
Importantly, in this document Oracle states about this
Note that in order to use prefer-application-packages or prefer-application-resources, prefer-web-inf-classes must be set to false.
This issue was solved by updating the package-info.java
#javax.xml.bind.annotation.XmlSchema(namespace = "urn:test1",
xmlns = {#XmlNs(prefix = "",
namespaceURI = "http://www.test.com")},
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
This is the part of the package-info that was not been there before
xmlns = {#XmlNs(prefix = "",
namespaceURI = "http://www.test.com")}
adding the namespace trick JavaXB to add the original namespace
Please check the mentioned page, which has a different Filtering classloading:
<wls:prefer-application-packages>
<wls:package-name>com.ctc.wstx.*</wls:package-name>
<wls:package-name>javax.wsdl.*</wls:package-name>
<wls:package-name>org.apache.cxf.*</wls:package-name>
<!-- <wls:package-name>javax.jws.*</wls:package-name> -->
</wls:prefer-application-packages>

Alfresco Custom Content Type not showing

I have been trying to follow this tutorial about Alfresco custom content types
http://ecmarchitect.com/alfresco-developer-series-tutorials/content/tutorial/tutorial.html#localizing-strings-for-custom-content-models.
However, when I get to the 'Test your changes' step and I go to manage rules, I can't manage to get the custom types created (sc_doc and sc_whitepaper) in the dropdown list.
My share-config-custom.xml:
<!-- Share configuration related to this particular Share module extension, such as:
- Doclib action config
- Form config
- Aspect and Type config
Note. Any configuration related to the whole Share.war webapp
(i.e. not specific to this share extension) should be
placed in the environment specific config:
alfresco/tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml file
-->
<alfresco-config>
<!-- Document Library config section -->
<config evaluator="string-compare" condition="DocumentLibrary">
<aspects>
<!-- Aspects that a user can see -->
<visible>
<aspect name="sc:webable" />
<aspect name="sc:productRelated" />
</visible>
<!-- Aspects that a user can add. Same as "visible" if left empty -->
<addable>
</addable>
<!-- Aspects that a user can remove. Same as "visible" if left empty -->
<removeable>
</removeable>
</aspects>
</config>
<config evaluator="node-type" condition="DocumentLibrary">
<types>
<type name="cm:content">
<subtype name="sc:doc" />
<subtype name="sc:whitepaper" />
</type>
<type name="sc:doc">
<subtype name="sc:whitepaper" />
</type>
</types>
</config>
</alfresco-config>
PS: Do I have to re-run 'mvn install' after every change I make in the .xml using Eclipse?
Any help will be much appreciated!
I know i am posting this answer bit late
and my solution is bit poor, But it works for me :)
I hope it will also work for you.
Strange thing is i am following same tutorial and at the time of 'Test your changes' stage not able to see my custom types on the server.
so to make it working in my share project i have changed place of
share-config-custom.xml
from src/main/resources/META-INF to src/main/amp/config/alfresco/web-extension
and restart alfresco and now able to view my custom types in type list on server.
plz post your answer if you have make done this by any other way :)
thank you.
I am not sure which kind of project you have created from maven artifacts.
Repository AMP archetype
All-In-One (AIO) archetype
Share AMP archetype
Here you can see list of all maven commands.
If you are not using local maven repository then you can go for "mvn package" to generate new AMP files and then deploy them manually on alfresco server.

spring src-resolve issue "Cannot resolve the name ...''

I'm stuck with a standalone java application I'm maintaining, I'm really new with Maven. I use the copy dependencies, package plugins in command line and everything it's ok, but then when I see the project in eclipse, it validates the project and it seems that there is a problem checking which .xsd version should take into account.
Description Resource Path Location Type src-resolve: Cannot resolve
the name 'beans:identifiedType' to a(n) 'type definition'
component. spring-jee-2.0.xsd
Description Resource Path Location Type src-resolve: Cannot resolve
the name 'beans:identifiedType' to a(n) 'type definition'
component. spring-jee-2.5.xsd
I'm using spring 2.5.6 and I cannot upgrade. I do not know if I have to set up something in my eclipse IDE.
My configuration file is like this:
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:jee="http://www.springframework.org/schema/jee"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">
Any ideas or suggestions? Is it something related with a problem in the project or with eclipse IDE?
Thanks in advance
I cannot reproduce your situation, but it seems to be related to this problem:
That's a feature of STS (trying to be clever and importing XSD from
project classpath it fails to find the spring core ones). Raise a JIRA
ticket there if you want to really solve the problem, but my
understanding is that it is a compromise - users who do not edit
custom XSDs are far more numerous than those that do, so it's better
to support the larger group.
You can work around it by adding the spring-beans-3.1.xsd to your XML
Catalog in Eclipse (look in Preferences). You probably only need to
specify a namespace id, but I always add the schema location to be on
the safe side. You probably need to extract the XSD from the spring
jar file because I don't think you can add a catalog entry from a jar.
So, try to add spring-beans-2.5.xsd to XML Catalog in Eclipse. Hope this helps.

Forwarding requests between contexts in Tomcat

I'd like to be able to do cross-context request forwarding in Tomcat with the Tuckey URLRewrite filter. For example, I'd like to be able to route an incoming request with an SEO-/user-friendly URL like http://example.com/group-elements/300245/some-descriptive-text, where "group-elements" isn't the name of a deployed application, to a URL mapped to a Java Spring controller method for application 'foo', like http://example.com/foo/app/group/300245/elements. I'm using Tomcat 7.0.27 and URLRewrite 3.2.0; I'm working with Java Spring 3.1 web applications.
The URLRewrite 3.20 documentation notes an optional 'context' attribute for the 'to' filter parameter element:
If your application server is configured to allow "cross context" communication then this attribute can be used to forward (and only forward, not redirect or other "to" types) requests to a named servlet context.
On Tomcat, for instance, the application contexts in the server configuration (server.xml or context.xml) need the option crossContext="true". For instance, the two applications mentioned before ("app" and "forum") have to be defined as:
<Context docBase="app" path="/app" reloadable="true" crossContext="true"/>
<Context docBase="forum" path="/forum" reloadable="true" crossContext="true"/>
Given that and the original discussion about the feature, the 'context' attribute seems to be what I'm looking for. However, I haven't been able to properly enable cross-context request forwarding.
Here's my 'Context' entry application 'foo' in conf/server.xml:
<Context docBase="foo" path="/foo" reloadable="true" crossContext="true"/>
I have my urlrewrite.xml file and web.xml file in webapps/ROOT/WEB-INF/. Here's what they look like:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: this 'to' element's value has an error. See the edit at bottom of this post for corrected version. -->
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
</urlrewrite>
web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd" version="2.5">
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>WARN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</web-app>
The rule defined above in urlrewrite.xml is intentionally basic and hard-coded. In this case I'm simply trying to get the cross-context aspect of the rule working before developing the regular expressions in 'to' and 'from'.
When I request http://example.com/baz with that rule in place, Tomcat returns a 404 error saying "The requested resource (/baz) is not available." I've tried a few variations in the 'to' filter parameter, but nothing has worked yet. And I haven't been able to find any examples of how 'context' should be used.
Any ideas on how I could get this kind of cross-context request filtering to work? Is it even possible? I imagine I might be able to achieve what I'm trying to do by renaming foo.war to ROOT.war or changing the root application as mentioned here, but I'd like to try doing this via URLRewrite unless doing so is infeasible or a bad idea on its face.
If showing more of my configuration would help, please let me know. Thanks in advance for any input.
Edit:
Thanks to Christopher Schultz for the helpful answer. In my case, the problem was caused by two things: 1) not having a context.xml file in webapps/ROOT/META-INF, and 2) having an error in the 'to' element in the URL rewrite rule in webapps/ROOT/WEB-INF/urlrewrite.xml.
The fix involved putting a proper context.xml file in webapps/ROOT/META-INF. For reference for anyone else that encounters this problem, that file ended up looking like this:
webapps/ROOT/META-INF/context.xml
<?xml version='1.0' encoding='utf-8'?>
<Context docBase="ROOT" path="/" reloadable="true" crossContext="true" />
As Schultz mentions, it's only necessary for a context with crossContext="true" to be defined for the context implied in the 'from' element in a given URL rewrite rule (here, that's ROOT). It is not necessary to explicitly define a context for the application in the 'to' URL rewrite rule. In other words, you shouldn't need to manually create a context.xml file for that application -- so continuing the example above, you would not need to manually define and put a context.xml file into webapps/foo/META-INF/.
Schultz's answer reflects the recommendations for defining a context in the official Tomcat documentation: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context.
The problem was also caused by the fact that the URL rewrite rule in my initial post had an error. The correct version should have been:
urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<rule>
<from>baz</from>
<!-- Note: the use of '/app' instead of '/foo/app/' below -->
<to context="foo">/app/group/300245/elements</to>
</rule>
</urlrewrite>
If your (real) webapp is deployed to /foo and you want to on-the-fly rewrite URLs like /group-elements/baz to forward (not redirect) to /foo/app/group/300245/elements, then you're going to have to deploy your rewrite filter to one of two places: /group-elements or /.
The above configuration appears to be deploying to ROOT (which is /) but then mapping the URL /baz to /foo/app/group/300245/elements. Instead, you probably want this:
<rule>
<from>/group-elements/baz</from>
<to context="foo">/foo/app/group/300245/elements</to>
</rule>
It looks like you were trying to hit http://example.com/baz which I would have expected to work. The last bit of magic is going to be making the ROOT context cross-context (note that your webapp does NOT need to be cross-context: only the urlrewrite one does). You can change the ROOT webapp to be cross-context by addint crossContext="true" to webapps/ROOT/META-INF/context.xml.
Finally, you should really stop putting <Context> elements in server.xml: leaving them in there basically means you need to restart Tomcat in order to change your webapp deployments.
After the comments I come do this possible conclusion:
I think you are mixing the concepts of a reverse proxy with cross-context. Cross-context is method to share data between two web-applications within the same application server. A reverse-proxy like 'Apache http' can rewrite a url to pass it to a certain server behind it, effectively hiding any unwanted parts or performing other operations like load-balancing.
The infrastructure would be: client --> reverse proxy --> application server

seam 2.2.2.Final looses translations

I'm using seam 2.2.2.Final with Richfaces 3.3.3.Final on JBoss AS 6.
My application is translated into 2 languages (dutch and english).
Sometimes (varying from hours to days) the web application looses the translations. It then only displays the key's as labels and not the translations.
Would anyone know what causes this?
First I thought it could be caused by the character set used in dutch. I then converted the files to ascii with native2ascii.exe but this did not solve the problem.
I'm using the default messages.properties files from seam. In my case these are messages_nl.properties and messages_en.properties. In JSF I use the EL-tags #{messages['key']}. after a few hours or days it seems like the application can't find the files anymore.
My faces-config.xml file contains these settings:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<application>
<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
<locale-config>
<default-locale>nl</default-locale>
<supported-locale>nl</supported-locale>
<supported-locale>en</supported-locale>
</locale-config>
</application>
</faces-config>
In JSF I use it like this:
<h:outputText value="#{messages['admin.scheduling.title']}" />
In Code I use
Messages.instance().get("admin.scheduling.title");
What are you using for translation? A converter?
The getAsString method must return the translated string.
Could you post the code?
I've ultimately solved this by creating an own implementation of the messages component.
It seems like an internal cache in seam gets cleared (probably after deserialisation of something). If the cache is (almost) empty I read the bundles again.

Resources