I have an application deployed in WAS 9 using custom jsf provider (set to DEFAULT in WAS). Jars are in a shared lib with an isolated class loader. Everything worked fine until we migrated from richfaces to primefaces. We use javax.faces 2.1.29 but for some reason primefaces seems to detect that we are using 2.2 and is making a call to a method that only exists in 2.2 (getPassThroughAttributes). Looking at the stack versions in play seem correct so I'm not sure why the 2.2 method call is being made. Anyone run into this?
> 3/19/19 17:19:07:671 CDT] 00000091 ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root cause Faces Servlet: javax.servlet.ServletException: javax/faces/component/UIComponent.getPassThroughAttributes(Z)Ljava/util/Map; (loaded from file:/opt/IBM/WebSphere/AppServer_2/trunkLib/javax.faces-2.1.29-10.jar by
com.ibm.ws.classloader.CompoundClassLoader#abecddd0[library:trunkLib]
Local ClassPath: /opt/IBM/WebSphere/AppServer_2/trunkLib/javax.faces-2.1.29-10.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/httpclient-4.5.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/httpcore-4.4.4.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/commons-codec-1.11.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-api-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-locator-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-utils-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/javax.annotation-api-1.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/jaxrs-ri-2.22.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/jersey-guava-2.22.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/validation-api-1.1.0.Final.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/classes:/opt/IBM/WebSphere/AppServer_2/trunkLib/javassist-3.23.1-GA.jar
Parent: com.ibm.ws.classloader.ProtectionClassLoader#a5c5ece8
and
> Caused by: java.lang.NoSuchMethodError: javax/faces/component/UIComponent.getPassThroughAttributes(Z)Ljava/util/Map; (loaded from file:/opt/IBM/WebSphere/AppServer_2/trunkLib/javax.faces-2.1.29-10.jar by
com.ibm.ws.classloader.CompoundClassLoader#abecddd0[library:trunkLib]
Local ClassPath: /opt/IBM/WebSphere/AppServer_2/trunkLib/javax.faces-2.1.29-10.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/httpclient-4.5.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/httpcore-4.4.4.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/commons-codec-1.11.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-api-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-locator-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/hk2-utils-2.4.0-b34.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/javax.annotation-api-1.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/jaxrs-ri-2.22.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/jersey-guava-2.22.2.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/validation-api-1.1.0.Final.jar:/opt/IBM/WebSphere/AppServer_2/trunkLib/classes:/opt/IBM/WebSphere/AppServer_2/trunkLib/javassist-3.23.1-GA.jar
Parent: com.ibm.ws.classloader.ProtectionClassLoader#a5c5ece8
Delegation Mode: PARENT_LAST) called from class org.primefaces.util.Jsf22Helper (loaded from file:/opt/IBM/WebSphere/AppServer_2/profiles/server1/installedApps/loggerheadNode03Cell/trunk80_war.ear/trunk80.war/WEB-INF/lib/primefaces-6.2.jar
It looks like PrimeFaces searches the classpath for JSF 2.2 classes - and unfortunately in this case PrimeFaces must be finding the those classes in the WAS-provided JSF 2.2 bundle. Moving primefaces-6.2 out of your application trunk80.war and into the isolated shared library trunkLib should resolve this.
First lets begin that the PrimeFaces source is OPEN, it is easilly debugged. A simple search in the source (either locally in your IDE or in GitHub) will get you the source of Jsf22Helper.java. You can than inspect where this is being called. Running in debug mode is the easiest, but a search in the PrimeFaces repository in GitHub shows just one location in CoreRenderer.java
protected void renderDynamicPassThruAttributes(FacesContext context, UIComponent component) throws IOException {
if (PrimeApplicationContext.getCurrentInstance(context).getEnvironment().isAtLeastJsf22()) {
Jsf22Helper.renderPassThroughAttributes(context, component);
}
}
Next you should inspect the
PrimeApplicationContext.getCurrentInstance(context).getEnvironment().isAtLeastJsf22()
And the getter for this returns a property that gets its boolean value from
atLeastJsf22 = LangUtils.tryToLoadClassForName("javax.faces.flow.Flow") != null;
In here you see that for determining the 'minimal' version, they try loading a class that is only present in JSF 2.2 or up. This means that no matter whether you use parent first classloading or not or independent of where you put PrimeFaces, if javax.faces.flow.Flow is on the classpath, PrimeFaces will think JSF 2.2 is available. It does not matter if JSF 2.1 is also on the classpath and even before JSF 2.2 since this specific class is not present in JSF2.1 and will always be loaded from the JSF 2.2 jars.
To fix this you have three options
Override the PrimeFaces PrimeEnvironment.java (e.g. via reading an explicit context property from the web.xml so you can optionally manually override the version detection and create a pull request for this with PrimeFaces so they can accept it as an improvement
'Correct' the way to override the JSF version similar to How to make websphere 8.5 use mojarra not myfaces
Switch to JSF 2.2
The latter would be the best and might even just be working out of the box.
Related
I am in the progress of upgrading a legacy application from PrimeFaces 6.2 to 11.0.0 (which is the newest available with maven - https://mvnrepository.com/artifact/org.primefaces/primefaces). I have had to make a number of changes, including adding Object as the parameter for RowEditEvent and TreeNode objects (which are now generic) and changing instantiations of DefaultStreamedContent to use .builder(). Now, I am facing the following error whenever I try to run the application and navigate to certain pages:
"javax.faces.FacesException: Unable to automatically determine the lazy attribute. Either define the lazy attribute on the component or make sure the value attribute doesn't resolve to null."
It looks like an exception is being thrown rather than a warning as is noted in the conversation here: https://github.com/primefaces/primefaces/issues/8436. It also looks like it was fixed, but for version 12 (which is not on the maven central repository).
I am wondering what my options are, or what could be done about this. Should I go back to an older version?
As a workaround you could create an application factory which sets the lazy attribute to false.
See: https://primefaces.github.io/primefaces/11_0_0/#/core/globalattributes
Is it a lazy DataTable which uses LazyDataModel? If yes, just set lazy=true, otherwhise set lazy=false
I have followed given 2 tutorials to use COnfigurationAPI in a Liferay dxp plugins SDK portlet built using Ant/Ivy.
COnfiguration API 1
COnfiguration API 2.
Below is the configuration class used:
package com.preferences.interfaces;
import com.liferay.portal.configuration.metatype.annotations.ExtendedObjectClassDefinition;
import aQute.bnd.annotation.metatype.Meta;
#ExtendedObjectClassDefinition(
category = "preferences",
scope = ExtendedObjectClassDefinition.Scope.GROUP
)
#Meta.OCD(
id = "com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration",
name = "UnsupportedBrowser.group.service.configuration.name"
)
public interface UnsupportedBrowserGroupServiceConfiguration {
#Meta.AD(deflt = "", required = false)
public String displayStyle();
#Meta.AD(deflt = "0", required = false)
public long displayStyleGroupId(long defaultDisplayStyleGroupId);
}
Post following the steps,I am getting the below error:
ERROR [CM Configuration Updater (ManagedService Update: pid=[com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration])][org_apache_felix_configadmin:97] [org.osgi.service.cm.ManagedService, id=7082, bundle=297//com.liferay.portal.configuration.settings-2.0.15.jar?lpkgPath=C:\dev\Liferay\osgi\marketplace\Liferay Foundation.lpkg]: Unexpected problem updating configuration com.preferences.interfaces.UnsupportedBrowserGroupServiceConfiguration {org.osgi.service.cm.ConfigurationAdmin}={service.vendor=Apache Software Foundation, service.pid=org.apache.felix.cm.ConfigurationAdmin, service.description=Configuration Admin Service Specification 1.2 Implementation, service.id=56, service.bundleid=643, service.scope=bundle}
Caused by: java.lang.IllegalArgumentException: wrong number of arguments
So,does this process need a osgi module as mandatory or can we do it using plusings sdk portlet built using ant as well?
Without disecting the error message Caused by: java.lang.IllegalArgumentException: wrong number of arguments:
The way you build your plugin (Ant, Maven, Gradle, manually) doesn't make a difference, as long as you build a plugin that will be understood by the runtime. aQute.bnd.annotation.metatype.Meta points firmly into the OSGi world, and makes it almost certain that you'll need an OSGi module. You can build this with Ant, of course. Even in Ant you can embed tools like bnd, or you can write the proper Manifest.mf to include in your module manually (just kidding - you don't want to do it manually, but it would work).
Recommendation: Instead of moving everything over: Try to reproduce this with a minimal example in gradle or better Liferay Workspace (which is gradle based), just to get all the automatic wiring in. Check if it makes a difference and compare the generated output from your Ant build process with the workspace output. Pay specific attention to the Manifest.
In order to build the proper Manifest, you want to use bnd - if the Manifest turns out to be your issue: Find a way to embrace bnd - if that's by saying goodby to Ant, or by tweaking your build script remains your decision.
I am using a JSON parser to extract the value and I am using the following jar
json-path-2.1.0, and I am getting the following error when I invoke the use case deployed as webservice on weblogic server
I wrote a small main program to extract the value from the json string and it works fine, but the server version of the use case is giving the issue. I am not sure if there are any other jars part of my ear can negatively impact this
SEVERE: defaultReader
java.lang.NoSuchFieldError: defaultReader
at com.jayway.jsonpath.spi.json.JsonSmartJsonProvider.<init>(JsonSmartJsonProvider.java:39)
at com.jayway.jsonpath.internal.DefaultsImpl.jsonProvider(DefaultsImpl.java:21)
at com.jayway.jsonpath.Configuration.defaultConfiguration(Configuration.java:174)
at com.jayway.jsonpath.internal.JsonContext.<init>(JsonContext.java:52)
at com.jayway.jsonpath.JsonPath.parse(JsonPath.java:596)
Stumbled about the same problem.
The reason why it does not work is not the JDK 8.
The reason why you encounter this issue, is the fact that weblogic 12.2.1.X is bundling some old version of json-smart.
On my machine this would be found here:
jar:file:/C:/dev/WLS_12_2_1_2_0/oracle_common/modules/net.minidev.json-smart.jar!/net/minidev/json/JSONValue.class
Now if you are using a library like json-path that depends on json-smart, then by default the container will load the required class using one of its built-in modules.
The blowup you have, seems to be that the JSONValue class that your json-path depends on seemed to have this defaultReder field.
Here is a snipet of the clode that is blowing up.
public JsonSmartJsonProvider() {
this(JSONParser.MODE_PERMISSIVE, JSONValue.defaultReader.DEFAULT_ORDERED);
}
That
JSONValue.defaultReader
Seems not to be valid on weblogs older system class loader class.
You can tell the container to use what you are packing by putting into your weblogic.xml deployment descriptor something like this:
<wls:prefer-application-packages>
<wls:package-name>net.minidev.json.*</wls:package-name>
</wls:prefer-application-packages>
I am having quite a bit of trouble getting weblogic to swallow the fine-grained instruction above.
I found myself to force weblogic to swallog all that goes into the web-inf folder instead doing:
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
I would have rather not be using a hammer like the web-inf-classes, but I am dancing with the weblogic system classloader when I do not go coarse grained...
Regards.
I too was facing this issue, It turned out some other library was using json-smart's older version, and it was getting precedence over json-path's json-smart dependency. Removing the other jar solved the issue. Or you can also downgrade your json-path's version to appropriate version such that it support json-smart's older version.
Looks like JsonParser jar is present in JVM 1.8 version and it seems to have more precedence over the JsonParser class available in Json-path.jar. Apparently the us case doesn't work in 12.2.1 version of the weblogic server but it works fine in 12.1.3
I had the same problem but I use Gradle so I had to add:
compile group: 'net.minidev', name: 'json-smart', version: '2.3' to my dependencies.
I use JRuby with jxBrowser. I´ve just upgraded to version 6.8 and my application stopped working. I think the problem comes with the new #JSAccessible annotation. JRuby does not allow method annotation and I inject a JRuby class into a javascript. What used to work now gives me the following message:
Unhandled Java exception: com.teamdev.jxbrowser.chromium.JSFunctionException: Uncaught TypeError: Cannot read property 'set_this' of undefined
Is it possible to not require the #JSAccessible annotation and bring back the functioning of version 6.7?
To bring back functionality of version 6.7 you just need to avoid using the #JSAccessible annotation in your code. This annotation represents an extension to the current API. If you don't use this annotation, the behavior is the same as in previous versions.
I've just started digging into the new ASP.NET 5 by creating a test single page application with the OAuth login. I already know that I can use IdentityServer3 for that purpose and it seems pretty nice. I've found a post by Dominick Baier which is explaining how to set up the IdentityServer3. However, the post seems to be out of date or the identity server itself isn't working with the latest version of the ASP.NET 5 (which is beta7 at the moment).
The problem is, when I try to configure the IdentityServer in the Startup.cs I got an error from VS telling me that IApplicationBuilder has no extension method called UseIdentityServer. And this seems to be true, since in the IdentityServer3 source code they have this extension method declared for IAppBuilder (not IApplicationBuilder).
Here is my code (Startup.cs):
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
// Add MVC to the request pipeline.
app.UseMvc();
var options = new IdentityServerOptions
{
Factory = new IdentityServerServiceFactory()
};
app.UseIdentityServer(options);
}
And the error (on the last line) is
'IApplicationBuilder' does not contain a definition for 'UseIdentityServer' and the best extension method overload 'UseIdentityServerExtension.UseIdentityServer(IAppBuilder, IdentityServerOptions)' requires a receiver of type 'IAppBuilder'
Obviously, if I change the parameter type in the Configure method to IAppBuiler, it'll throw a runtime error because the dependency injection will not be able to inject that type. Even if it would, I'd lose the UseMvc() extension method.
So could you point me in the right direction please?
Perhaps I'm just missing something tiny but crucial here.
Thanks in advance!