Replacement of renderRequest.getParameter("param") in Liferay 7.x - java

When I'm using below code getting warning that it's deprecated
renderRequest.getParameter("param")
Then I used
renderRequest.getRenderParameters().getValue("param")
as this was suggested by v3.0. But after that getting bellow error at run time
2020-11-19 02:58:02.537 ERROR [http-nio-8080-exec-6][render_portlet_jsp:131] null
java.lang.UnsupportedOperationException: Requires 3.0 opt-in
at com.liferay.portlet.internal.PortletRequestImpl.getRenderParameters(PortletRequestImpl.java:520)
at com.training.portlet.MyPortlet5.doView(MyPortlet5.java:61)
at com.liferay.portal.kernel.portlet.LiferayPortlet.doDispatch(LiferayPortlet.java:303)
at com.liferay.portal.kernel.portlet.bridges.mvc.MVCPortlet.doDispatch(MVCPortlet.java:478)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:291)
at com.liferay.portal.kernel.portlet.bridges.mvc.MVCPortlet.render(MVCPortlet.java:302)
at com.liferay.portlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:127)
at com.liferay.portlet.ScriptDataPortletFilter.doFilter(ScriptDataPortletFilter.java:58)
at com.liferay.portlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:124)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:71)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:115)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:153)
at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:62)
at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:120)
at org.eclipse.equinox.http.servlet.internal.servlet.RequestDispatcherAdaptor.include(RequestDispatcherAdaptor.java:48)
at com.liferay.portlet.internal.InvokerPortletImpl.invoke(InvokerPortletImpl.java:573)
at com.liferay.portlet.internal.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:670)
at com.liferay.portlet.internal.InvokerPortletImpl.render(InvokerPortletImpl.java:362)
at

This issue was because my portlet module was using portlet API v2.0 by default and getRenderParameters() is available since v3.0. So, when explicitly I mentioned in component class to use v3.0 and did Gradle refresh the issue got fix.
I could fix this issue by adding
"javax.portlet.version=3.0"
in portlet's component class.
#Component(
immediate = true,
property = {
"javax.portlet.version=3.0",
"com.liferay.portlet.display-category=category.app",
"com.liferay.portlet.instanceable=true",
"javax.portlet.init-param.template-path=/",
"javax.portlet.resource-bundle=content.Language",
"javax.portlet.security-role-ref=power-user,user",
"javax.portlet.init-param.view-template=/myportlet5/view.jsp",
"javax.portlet.name=" + MyModuleMainPortletKeys.MY_PORTLET5
},
service = Portlet.class

Related

GraalVM native image with micronaut and aws sdk-v2

I have an issue when building a GraalVM native image using micronaut and aws sdk-v2. Before detailing the error I want to note that before using the sdk-v2 the native image was built correctly.
Once I updated to aws sdk-v2 (via micronaut dependency as):
...
implementation "io.micronaut.aws:micronaut-aws-sdk-v2:2.0.2"
...
I get an error when the trying to built the image
Fatal error:java.lang.NoSuchMethodError
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at java.base/java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:603)
at java.base/java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1006)
at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:480)
at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:349)
at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:508)
at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:114)
at com.oracle.svm.hosted.NativeImageGeneratorRunner$JDK9Plus.main(NativeImageGeneratorRunner.java:537)
Caused by: java.lang.NoSuchMethodError: 'void io.micronaut.core.graal.AutomaticFeatureUtils.initializeAtBuildTime(org.graalvm.nativeimage.hosted.Feature$BeforeAnalysisAccess, java.lang.String)'
at io.micronaut.aws.sdk.v2.graal.AwsSdkAutomaticFeature.beforeAnalysis(AwsSdkAutomaticFeature.java:41)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$runPointsToAnalysis$7(NativeImageGenerator.java:693)
at com.oracle.svm.hosted.FeatureHandler.forEachFeature(FeatureHandler.java:70)
at com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:693)
at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:555)
at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:468)
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1407)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Error: Image build request failed with exit status 1
com.oracle.svm.driver.NativeImage$NativeImageError: Image build request failed with exit status 1
at com.oracle.svm.driver.NativeImage.showError(NativeImage.java:1558)
at com.oracle.svm.driver.NativeImage.build(NativeImage.java:1308)
at com.oracle.svm.driver.NativeImage.performBuild(NativeImage.java:1269)
at com.oracle.svm.driver.NativeImage.main(NativeImage.java:1228)
at com.oracle.svm.driver.NativeImage$JDK9Plus.main(NativeImage.java:1740)
...
My assumption was that micronaut must be doing some reflection internally and that is making the build process to fail.
I have added the following json file to set a reflection configuartion
[
{
"name" : "io.micronaut.core.graal.AutomaticFeatureUtils",
"allDeclaredConstructors" : true,
"allPublicConstructors" : true,
"allDeclaredMethods" : true,
"allPublicMethods" : true
},
{
"name":"io.micronaut.core.graal.AutomaticFeatureUtils",
"methods":[{"name":"initializeAtBuildTime","parameterTypes":["org.graalvm.nativeimage.hosted.Feature$BeforeAnalysisAccess","java.lang.String[]"] }]
}
]
However the error persists. Not sure if it is due to the fact that AutomaticFeatureUtils.initializeAtBuildTime is expecting a varargs of strings and however in the stacktrace I can see just one String being passed, or the error is not related to reflection at all.
No matter what I try, that method is not found when building the image.
Any idea on what I may be missing here?
Thanks!!
This error is not related to reflection.
Feature and AutomaticFeature are GraalVM native image concepts that allow programmatic configuration for the native iamge, more details can be found for example in the javadoc: https://github.com/oracle/graal/blob/master/sdk/src/org.graalvm.nativeimage/src/org/graalvm/nativeimage/hosted/Feature.java#L59
The error you show happens during the image generation, this is a normal java process, which doesn't need to have reflection configured etc. Those are the configuration for the runtime behavior.
What the error says is that AwsSdkAutomaticFeature (source tries to call void io.micronaut.core.graal.AutomaticFeatureUtils.initializeAtBuildTime(org.graalvm.nativeimage.hosted.Feature$BeforeAnalysisAccess, java.lang.String) but there's no such method. Most probable cause is the version mismatch between the dependency and the core micronaut library that contain graal support.

ai.djl.pytorch.zoo.PtZooProvider not found

i am testing the framework djl https://djl.ai/
When i try to load the model : ModelZoo.loadModel(criteria)
I am getting this error :
java.util.ServiceConfigurationError: ai.djl.repository.zoo.ZooProvider: Provider ai.djl.pytorch.zoo.PtZooProvider not found
Criteria<BufferedImage, DetectedObjects> criteria =
Criteria.builder()
.optApplication(Application.CV.OBJECT_DETECTION)
.setTypes(BufferedImage.class, DetectedObjects.class)
.optFilter("size", "512")
.optFilter("backbone", "resnet50")
.optFilter("flavor", "v1")
.optFilter("dataset", "voc")
.optProgress(new ProgressBar())
.build();
I finally find a solution. I just add this to my maven pom.xml file
<dependency>
<groupId>ai.djl.pytorch</groupId>
<artifactId>pytorch-native-auto</artifactId>
<version>1.4.0-SNAPSHOT</version>
</dependency>
It seems you are using master branch. The latest master branch should have fixed this issue. PyTorch support is not officially supported (will be released by early April). You can try stable release by checkout v0.3.0.

Hazelcast : Portable Serialization : Incompatible class-definitions with same class-id

I recently upgraded a cluster from 3.7.2 to 3.9.2; shutting down all the boxes.
I'm using Portable Serialization and the current version number in the config file is 6. Yet, after a cold start, the cluster indicates a incompatible class definition.
I've restarted the cluster several times since, yet the same error remains.
How is it possible for the system to remain out of sync for some fields in some classes, yet the version for the class was upgraded?
Log:
Caused by:
com.hazelcast.nio.serialization.HazelcastSerializationException:
Incompatible class-definitions with same class-id:
ClassDefinition{factoryId=1, classId=8, version=6, fieldDefinitions=[
FieldDefinitionImpl{index=0, fieldName='feature', type=UTF, classId=0, factoryId=0, version=6},
FieldDefinitionImpl{index=1, fieldName='value', type=BOOLEAN, classId=0, factoryId=0, version=6}]}
VS
ClassDefinition{factoryId=1, classId=8, version=6, fieldDefinitions=[
FieldDefinitionImpl{index=0, fieldName='feature', type=UTF, classId=0, factoryId=0, version=0},
FieldDefinitionImpl{index=1, fieldName='value', type=BOOLEAN, classId=0, factoryId=0, version=0}]}
Config:
<serialization>
<portable-version>6</portable-version>
<portable-factories>
<portable-factory factory-id="1">
com.MyPortableFactory
</portable-factory>
</portable-factories>
</serialization>
It is a bug in Hazelcast library that got fixed in 3.9.4 and 3.10+.
Issue:
https://github.com/hazelcast/hazelcast/issues/12733
Fix for 3.10:
https://github.com/hazelcast/hazelcast/pull/12734
Fix for 3.9.4:
https://github.com/hazelcast/hazelcast/pull/12735

What causes elusive: NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint()?

Many people have asked for help with this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
at
org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:51)
at
org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:152)
at
javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
...
But no request I can find ever provides a conclusive answer. Just suggestions to tinker with jars.
I believe that’s because there’s an inconsistency in the structure of Jboss interfaces. Can anyone confirm or correct that?
Here’s my code that throws the above error:
final private Properties env = new Properties() {
{put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
put(Context.PROVIDER_URL, "http-remoting://localhost:9990");
put(Context.SECURITY_PRINCIPAL, "myID");
put(Context.SECURITY_CREDENTIALS, "myPassword");
put("jboss.naming.client.ejb.context", true);
}
};
/****************************************************
* myID & myPassword open the Admin GUI for wildfly *
* on localhost:9990 *
****************************************************/
Context ctx = new InitialContext(this.env);
To determine the required jars I removed all jars from the Build path.
Then I ran my program till all ClassNotFoundException were gone.
First Error
java.lang.ClassNotFoundException:
org.jboss.naming.remote.client.InitialContextFactory]
Added jboss-remote-naming-1.0.7.final.jar to class path
Second Error
java.lang.NoClassDefFoundError:
org/jboss/logging/Logger
Added jboss-logging.jar
Third Error
java.lang.NoClassDefFoundError:
org/xnio/Options
Added xnio-api-3.0.7.ga.jar
Fourth Error
java.lang.NoClassDefFoundError:
org/jboss/remoting3/spi/ConnectionProviderFactory
Added jboss-remoting-3.jar
Fifth Error
java.lang.NoClassDefFoundError:
org/jboss/ejb/client/EJBClientContextIdentifier
Added jboss-ejb-client-1.0.19.final.jar
FINAL AND FATAL ERROR
(Note: All NoClassDefFoundError have been cleared)
java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
Using Eclipse’s Project Explorer I verified:
a. jboss-remoting3.jar has the org.jboss.remoting3.Remoting Class.
b. That Remoting Class has this Method:
public Endpoint createEndpoint (String, Executor, OptionMap)
Note it calls for 3 parameters.
BUT the FINAL FATAL ERROR above calls for
public Endpoint createEndpoint (String, OptionMap)
Note: it calls for 2 parameters. Hence the NoSuchMethodError.
Looking at the top lines in the stack trace, I guess
org.jboss.naming.remote.client.InitialContextFactory.getInitialContext() is trying to call org.jboss.remoting3.Remoting.createEndpoint() using 2 parameters, but org.jboss.remoting3.Remoting only defines createEndpoint() with a 3-paramater signature.
Is that supposed to even be possible?
A jar that says it has the org.jboss.remoting3 package whose Remoting class has a single createEndpoint() method with a 3-parameter signature, and another jar that says it has the org.jboss.remoting3 package whose Remoting class has another createEndpoint() method with a 2-parameter signature?
HELP!
I mean do I need to look through every org.jboss.remoting3 package to find one whose Remoting class has a 2 parameter createEnpoint() method?
Or am I missing something important.
I mean this does explain how many questions have been posted about this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
And explain why there is never a conclusive explanation or solution other than fiddling with jars and build path.
I mean getting an InitialContext from WildFly running on the same PC as the Java program should be a trivial process. But it hasn’t been. Maybe it's because of inconsistencies in the API.
Thanks to Christoph Böhme:
jboss-logging-3.1.4.GA.jar has an org.jboss.remeoting package with a Remoting class that has createEndpoint() with a 0, 2 and 3 parameter signature.
Replacing jboss-remoting-4.0.7.Final.jar with the above jar was all it required to clear the NoSuchMethodError.
Hope that helps others.

Wildfly won't play nicely with camel: IllegalArgumentException: Type is not a Component implementation

I'm trying to get apache camel running on wildfly 9.0.2.Final.
Using the guide here, I've downloaded a wildfly bundle WildFly-Camel 3.3.0 and patched my wildfly instance.
My route configuration uses netty-http, like this:
from("netty-http:http://localhost:8459/broker/router.jsp").convertBodyTo(String.class)
So I have added camel-netty-http version 2.16.2 to my project.
However, when I start up, I get the following stack trace:
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: netty-http://http://localhost:
8459/broker/router.jsp due to: Cannot auto create component: netty-http
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:590)
at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:79)
at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:211)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:107)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:113)
at org.apache.camel.model.FromDefinition.resolveEndpoint(FromDefinition.java:69)
at org.apache.camel.impl.DefaultRouteContext.getEndpoint(DefaultRouteContext.java:89)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:1052)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:196)
... 39 more
Caused by: org.apache.camel.RuntimeCamelException: Cannot auto create component: netty-http
at org.apache.camel.impl.DefaultCamelContext.getComponent(DefaultCamelContext.java:412)
at org.apache.camel.impl.DefaultCamelContext.getComponent(DefaultCamelContext.java:388)
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:560)
... 47 more
Caused by: java.lang.IllegalArgumentException: Type is not a Component implementation. Found: org.apache.camel.component.netty.http.NettyHttpComponent
at org.apache.camel.impl.DefaultComponentResolver.resolveComponent(DefaultComponentResolver.java:89)
at org.wildfly.extension.camel.handler.ComponentResolverAssociationHandler$WildFlyComponentResolver.resolveComponent(ComponentResolverAssociationHandler.java:67)
at org.apache.camel.impl.DefaultCamelContext.getComponent(DefaultCamelContext.java:401)
... 49 more
Looking at the camel source here, it seems this exception is thrown when the Component specified is not a org.apache.camel.Component:
if (Component.class.isAssignableFrom(type)) {
return (Component) context.getInjector().newInstance(type);
} else {
throw new IllegalArgumentException("Type is not a Component implementation. Found: " + type.getName());
}
But it clearly is a Component, and it's the correct version too.
What can I be doing wrong? Is it perhaps picking up the Component class with a different classloader than the one loading the NettyHttpComponent class?
netty-http component is not supported by wildfly-camel. You should use the components they support listed here: https://wildflyext.gitbooks.io/wildfly-camel/content/components/index.html

Categories

Resources