I am trying to setup some boiler plate code in my local workspace which uses weblogic10.3. I have a documentation that asks me to import Content.jar from /wlportal_10.3/content-mgmt/lib into window->preferences-->Weblogic-->Shared Library which I did. However when I try to deploy portlet this is the error am getting
Error Deployer BEA-149107 An attempt was made to deploy library 'content' with specified specification version '10.3.2' and implementation version '10.3.2 '. However, the library manifest has specification version '10.3.2' and implementation version '10.3.2'
Related
Ubuntu 20.04, Noetic
I have installed UR ROS driver, Moveit, Noetic, Catkin... Cloned Moveit Calibration from 'https://github.com/ros-planning/moveit_calibration'. Also have set Getting Started and Setup Assistant with MoveIt.
I am following link 'https://ros-planning.github.io/moveit_tutorials/doc/hand_eye_calibration/hand_eye_calibration_tutorial.html'. After launching `roslaunch panda_moveit_config demo.launch', getting error:
"HandEyeCalibration
The class required for this display, 'moveit_rviz_plugin/HandEyeCalibration', could not be loaded.
Error:
Could not find library corresponding to plugin moveit_rviz_plugin/HandEyeCalibration. Make sure the plugin description XML file has the correct name of the library and that the library actually exists."
I have upgraded to the latest Checkstyle plugin (8.41.1) using IntelliJ 2021.
I'm trying to configure a custom google checkstyle xml file, so I took the lates example from Github and tried to set it as config file to the checkstyle plug but I'm getting the following exception
com.puppycrawl.tools.checkstyle.api.CheckstyleException: cannot initialize module TreeWalker - cannot initialize module JavadocMethod - Property 'accessModifiers' does not exist, please check the documentation
at com.puppycrawl.tools.checkstyle.Checker.setupChild(Checker.java:473)
at com.puppycrawl.tools.checkstyle.api.AutomaticBean.configure(AutomaticBean.java:201)
at org.infernus.idea.checkstyle.service.cmd.OpCreateChecker.execute(OpCreateChecker.java:61)
...
...
If I'm setting the builtin Google check then it works.
Any idea?
I took the lates example from Github
This is the issue. You should be using the config that was built for the version of checkstyle you are using. You pulled in master's config which contains new features that have not been released.
See https://github.com/checkstyle/checkstyle/blob/49d1ea3835e017133ada46555d2214e017fc6fe2/src/main/resources/google_checks.xml
I'm creating a node extension for KNIME with the KNIME SDK (which is just an adapted Eclipse). I'm done with my code, I tested it in Eclipse, it worked perfectly. So I exported it, copied the .jar to the subfolder dropins in my KNIME installation, and started KNIME. Made a new workflow, added my node, tried to execute it and then the following error appeared:
Execute failed: Support code location could not be determined. Could not convert from URL to URI location.
URL Location: file:/C:/Program Files/KNIME_2.11.2/configuration/org.eclipse.osgi/bundles/528/1/.cp/matlabcontrol-4.1.0.jar
Code Source: (file:/C:/Program Files/KNIME_2.11.2/configuration/org.eclipse.osgi/bundles/528/1/.cp/matlabcontrol-4.1.0.jar <no signer certificates>)
Protection Domain: ProtectionDomain (file:/C:/Program Files/KNIME_2.11.2/configuration/org.eclipse.osgi/bundles/528/1/.cp/matlabcontrol-4.1.0.jar <no signer certificates>)
null
<no principals>
java.security.AllPermissionCollection#6ac1c077 (
("java.security.AllPermission" "<all permissions>" "<all actions>")
)
Class Loader: org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader#b836456
Class Loader Class: class org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
According to a thread on the KNIME forums, a similar problem also occurs with the community extension "Matlab Snippet", which builds on the same matlabcontrol framework I use (which is also the one mentioned in the error).
I tried evading the problem by including the matlabcontrol as a package in my project (it's open source, so I could just import the sources), then the same error appeared and mentioned the package .jar created by the OSGI system (in my case, matlab.jar, which is the name I chose in my build.properties), so I assume it was just the first one alphabetically and all of the files in the OSGI bundle folder are affected by this problem.
What confuses me is that the problem only occurs once I try to execute the node and connect to MATLAB. Unfortunately, the problem doesn't seem to have been resolved in the KNIME forum thread linked above, apparently an older version of that extension didn't have the issue and users just installed the old version.
So, can I somehow make the URL correctly convert to URI? Is the Protection Domain the cause and can I change it? Does it have anything to do with the default Class Loader?
I have now installed the plugin via a feature in a folder (see comments). The error persists, but the path changed:
Execute failed: Support code location could not be determined. Could not convert from URL to URI location.
URL Location: file:/C:/Program Files/KNIME_2.11.2/plugins/org.knime.ext.matlab_1.0.0/matlab.jar
Code Source: (file:/C:/Program Files/KNIME_2.11.2/plugins/org.knime.ext.matlab_1.0.0/matlab.jar <no signer certificates>)
Protection Domain: ProtectionDomain (file:/C:/Program Files/KNIME_2.11.2/plugins/org.knime.ext.matlab_1.0.0/matlab.jar <no signer certificates>)
null
<no principals>
java.security.AllPermissionCollection#2da869b5 (
("java.security.AllPermission" "<all permissions>" "<all actions>")
)
Class Loader: org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader#372bf03c
Class Loader Class: class org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
I am new to Jython and Python, trying to build a prototype that makes use of Python code to be called from within Java. The code I am developing works in Jetty and in standalone mode (running java -jar from the command line), but not when deployed to weblogic.
How can I make weblogic(10.3.5) server/Jython recognize the Lib folder within jython-standalone-2.5.4-rc1.jar?
My Java code uses the JythonObjectFactory to invoke python modules as outlined in the Jython book:
http://www.jython.org/jythonbook/en/1.0/JythonAndJavaIntegration.html
The Python modules are using external libraries like csv, logging etc. that are not packaged with jython.jar, hence I am using jython-standalone jar.
The java code includes an interface that would define the class type of the first invoked py module from within java. The interface and the input and output (to python modules) type classes are in a package structure as com.abc.xpackage. and the py modules exist at the root of this package. A controller layer calls the objectfactory and in turn executes the python code thus:
JythonObjectFactory calFactory = new JythonObjectFactory(CalcType.class, "Calculate", "Calculate");
CalcType engine = (CalcType)calFactory.createObject();
output = engine.execute(input);
The entire code is bundled as a jar file which would become part of a web application deployed on weblogic. The code was compiled with maven (with jython dependencies included in the repository) and runs fine on the included Jetty runtime within eclipse.
When deployed on weblogic, however, I get a "ImportError: no module named csv" error.
To analyze what is happening, I tried printing the Jython system state path on weblogic and the standalone environment/Jetty. What I found is,
on Jetty, the system path consists of the following:
C:\.m2\repo\org\python\jython\jython-standalone-2.5.3-rc1.jar\Lib, ____classpath__, ____pyclasspath__
on Weblogic, printing the system path by default shows the following:
____classpath__, ____pyclasspath__
I tried forcing the inclusion of the missing path using the code as follows:
public JythonObjectFactory(PySystemState state, Class interfaceType, String moduleName, String className) {
String pathToAppend = new File(state.getClass().getProtectionDomain().getCodeSource().getLocation().toURI().getPath()).getAbsolutePath()+"\\Lib";
state.path.insert(0, new PyString(pathToAppend));
state.path.append(new PyString(pathToAppend));
System.out.println("Jython sys path: "+state.path);
Please note, I prepended as well as appended the path in different trials. The sys path on weblogic now displays the following:
Jython sys path: ['C:\\wldomain\\wls135\\servers\\cgServer\\tmp\\app-1\\war\\WEB-INF\\lib\\jython-standalone-2.5.4-rc1.jar\\Lib', '__classpath__', '__pyclasspath__/', 'C:\\wldomain\\wls135\\servers\\cgServer\\tmp\\app-1\\war\\WEB-INF\\lib\\jython-standalone-2.5.4-rc1.jar\\Lib']
I am still getting ImportError despite this forcing of sys path. Please help why this works in a local environment, and not on weblogic, and if there is any configuration I am missing. Apologize for the rambling long post, I did not know how to explain the problem better. I will try and include any code/artifacts as needed.
Based on a comment(by Lassi) on the blog post below:
http://www.petervannes.nl/files/e1c3c56d15d25dcfd4adb5397a9ef71e-53.php
The jython issue was resolved after explicitly adding the Lib folder python.path to the weblogic startup script as a JAVA_OPTION.
In my case I added the exploded Lib folder to the domain server lib, but based on my test this works also from within the jython jar. Both the following JAVA_OPTIONS worked:
-Dpython.path=C:\wldomain\wls135\lib\Lib
-Dpython.path=C:\wldomain\wls135\lib\jython-standalone-2.5.4-rc1.jar\Lib
The programmatic way of sys.path.append worked for the local environment(jetty) but did not seem to work for weblogic.
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.