I am deveoloping a custom plugin for Pentaho DI / Kettle 4.4 and use custom Validation and XSLT jars as part of it.
Those jars are referenced in plugin.xml along with the plugin's jar itself and deployed in the same location as the plugin's jar.
When I try to load this plugin in Spoon GUI, I can see and run the plugin fine till I reach the reference to the external jars and after that I get ClassNotFOund Exception.
I have tried following so far but has not worked :
Add the expernal Jars to libext folder and expect those to be picked up automatically. - Failed. Jars not loaded.
Add -cp command line option to Spoon.bat and specify the Jar files - Did not work.
Turned on -verbose option and search everywhere in the output but the Jars are ignored.
Deployed the Jars next to the plugin's Jar file in the plugin's folder. - Jars are not recognized.
From Within the plugin, if I dynamically load (using Reflection and URL Class Loader) I am able to force the loading of the Jars and it works that way but I would like a simpler classpath fix.
Any class that I reference in the Jar through XSL externsion (XALAN-J Java Extension) is still not recognized / loaded and XSL terminates at the beginning of Extension call.
Searched Google and this site for something similar but did not find specific answers on why SPoon behaves so differently and avoids external code and content.
A similar issue is reported here though its too old and has not shown final conclusive fix. I tried all that it said. http://forums.pentaho.com/archive/index.php/t-77190.html
Requesting someone to help me identify whats missing. Thanks in advance,
Thanks to this seemingly obscure website and it fixed all pain.
http://www.arulraj.net/2014/09/how-to-access-external-java-libraries-with-in-pentaho.html
Basically, go to the launcher folder and edit the launcher.properties file to include any path, library etc. and it fixes all the issues I reported above. Wish Kettle documentatation had answers like this.
Related
I have created a minimal reproducable example with a detailed README here.
In my expo app, I was having trouble using the babel module-resolver to use path aliases. My Metro bundling would fail when I used path aliases.
I learned that when I changed my babel.config file extension from .cjs to .js, the problem was resolved.
However, I do not understand why that would have any effect on whether the module-resolver plugin would work.
As described on babel's documentation, "Babel can be configured using any file extension natively supported by Node.js", with cjs specifically enumerated. And as I understand it, Expo by default creates a CommonJS babel.config file as it uses module.exports.
I have never created a GitHub issue, but perhaps this question is better suited as a babel-plugin-module-resolver issue, or I need to narrow down this issue further to determine whether Expo, or other babel plugins are relevant.
In short:
I tried creating a new expo app with npx create-expo-app to see if something about my project was effecting this issue. I then added a path alias to a test component and imported the component with the path alias. I ran expo which resulted in a bundle success. I then renamed babel.config.cjs and ran expo again with --clear, which resulted in a bundle failure "Unable to resolve [path alias]..."
I expected the cjs file extension to have no effect on whether the module-resolver caused an error.
What resulted was the module-resolver being fixed once I renamed babel.config.cjs to babel.config.js
I’ve been trying to explore WSO2 Microgateway and set up a Microgateway project. Building the project in Windows 10 with the command “micro-gw build project-name” is giving this error: “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”.
I’ve downloaded the Toolkit and Runtime from https://wso2.com/api-management/api-microgateway/. I've set the Path environment variable to the /bin directory of the Toolkit and Runtime extracted folders, but still the “micro-gw build project-name” command is giving error “Could not find or load main class org.wso2.apimgt.gateway.cli.cmd.Main”. I’ve also cloned the source code from Github (https://github.com/wso2/product-microgateway/) which has the Main.java class and tried setting environment variables to its path.
I also tried setting the environment variables to the path where Toolkit batch file is present. I also followed the steps mentioned here, https://github.com/wso2/product-microgateway/#running-the-microgateway.
I'm assuming the Toolkit batch file (micro-gw) would execute the Main.java class coming up in the error.
These steps did not resolve the error. I'm new to Java based product, and I'm sure I'm missing something here.
Problem is with the init command not the build command. Init command is suppose to setup the TOOLKIT after the first use. It should extract the platform.zip file and copy all of the required resources to relevant places for you.
I hope you get the Project ___ successfully initialized message after running the init command. Just check $TOOLKIT_HOME/logs/ directory to see if there are any information on the log file.
If the log file also doesn't help, as a workaround, copy all the .jar files inside $TOOLKIT_HOME/lib/gateway/platform and $TOOLKIT_HOME/lib/gateway/cli to $TOOLKIT_HOME/lib/platform/bre/lib and try again, that should work.
Also please report this issue at https://github.com/wso2/product-microgateway/issues
I am trying to write a Dropwizard application and its doc tells me that I need to ship everything as an uber jar.
However, in my application I need to support multiple databases and this requires multiple database JDBC driver jars in my classpath, all of which are not expected to be shipped together with my application. Users are expected to place the corresponding JDBC jar like mysql-connector-java-5.1.39.jar in a particular folder by their own.
After reading Dropwizard's documentation I am not sure if this kind of usage is supported. Does anyone have experience making it to work this way?
Since java 6, you can wildcard classpaths.
Using the application plugin, the generated bin folder will have a start script that contains the classpath. What we want to do, is to instead of listing every possible jar in the bin folder, we simply include all of them.
Note: You can also do the same thing with different folders if you want the classpath in a different location.
This can be achieved (in a workaround manner since there are problems with this plugin in my version) in the easiest way as follows. In build.gradle you do:
startScripts {
doLast {
def windowsScriptFile = file getWindowsScript()
def unixScriptFile = file getUnixScript()
windowsScriptFile.text = windowsScriptFile.text.replaceAll('CLASSPATH=.*', 'CLASSPATH=\\$APP_HOME/lib/*')
unixScriptFile.text = unixScriptFile.text.replaceAll('CLASSPATH=.*', 'CLASSPATH=\\$APP_HOME/lib/*')
}
}
This will wildcard your lib folder in the start scripts. When starting up, your classpath will simply be
lib/*
When you drop jars into that folder, they will automatically be picked up (on startup, not on runtime).
I hope this helps,
Artur
I can't seem to get my JSTL library working in my embedded jetty project working.
My taglib line seems to be giving me grief, and it all changes when I use different URIs. Here is the line I would want to use:
<%#taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
I first tried using the normal URI http://java.sun.com/jsp/jstl/core but that throws the error:
org.apache.jasper.JasperException: /bad.jsp(1,61) PWC6188: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
However when I change the URI to http://java.sun.com/jstl/core_rt. It works!
Another thing I noticed, if I have the old JSTL 1.0 url (http://java.sun.com/jstl/core) I get the following error:
org.apache.jasper.JasperException: /bad-el.jsp(4,0) PWC6236: According to TLD or attribute directive in tag file, attribute value does not accept any expressions
Now another preplexing thing I have noticed, this all works in IntelliJ! Which leads me to believe that there is a classpath problem, but the libraries should be all the same when I embed them inside the war. I think I am missing something.
So, what my question boils down to, what library do I need, or what configuration do I need to have to make this work properly?
Here are the current questions I have tried to follow but did not resolve my issues:
cannot load JSTL taglib within embedded Jetty server
Embedded Jetty fails to load JSP taglibs when classpath specified in jar
Jetty 8 standalone doesn't detect jstl taglib jar
JSTL not parsed in a JSP page running on an embedded Jetty instance
and many others
I have a sample project that one could checkout and try out.
if you want the JSTL uri to work, you should know that jstl is two files.
jstl-1.2.jar
jstl-api-1.2.jar
so look for them in the internet or go to the maven repo and download the jars
Is there a way to fix the file locking issue caused by jetty entirely from gradle?
Some clarification:
When using the Gradle Jetty plugin by running gradle jettyRun, jetty causes the static resource files (html, css, js, etc.) to be locked when using Windows.
You can see a description of the problem in Files locked on Windows.
The same article also describes how you can fix that. Basically you have to either:
Disable the use of file mapped buffer
Not use NIO at all.
Both things require to add some jetty specific configuration files to the project, which I do not want to do - the jetty plugin is used only for convenience, and maintaining configuration for it does not feel right.
I do not need NIO for testing on the local machine, so any solution works.
Edit:
For now, I picked the option at which you set useFileMappedBuffer to false. This is how to do it:
Specify a path to your webdefault.xml like
[jettyRun, jettyRunWar,jettyStop]*.with {
//other configs
webDefaultXml = file("${project.webAppDir}/WEB-INF/jetty-webdefault.xml")
}
Get file from the latest 6.1.x distribution of jetty. The plugin seems to support only jetty 6. You can localte it at jetty-6.1.26\etc\webdefault.xml. Obviously, you have to place it at the path specified at the previous step.
Change the default servlet init parameter useFileMappedBuffer to false
I will research the option of using embeded jetty insted of the plugin.
I found a plugin that seem to be a better alternative:
https://github.com/akhikhl/gretty
Positives
Does not lock your files and support hot deployment (even something Gretty call "fast reload")
Gretty 1.2.0 uses Jetty 9.2.9.v20150224. Jetty plugin provided by Gradle 2.2.1 uses Jetty 6.1.25.
same task is used jettyRun (or more simply run).
"Press any key to stop the server". Jetty plugin required CTRL+C then Y.
From what I can tell, the documentation seem to be awesome (Gradle's not so much)
Negatives
A bit more bloated code to setup the buildscript's classpath dependency or apply plugin directly from URL (see doc)
Gretty crash unless you explicitly apply plugin: 'war' (Jetty plugin extends the War plugin)
Kiril answered his own question, many thanks. You should follow Kiril's instructions and this will help you find the appropriate webdefault.xml.
To find out what version of Jetty is started by Gradle, execute
gradle jettyRun -i
And you'll see something like this:
...
Tmp directory = determined at runtime
Web defaults = org/mortbay/jetty/webapp/webdefault.xml
Web overrides = none
Webapp directory = C:\dev\my-project\src\main\webapp
Starting jetty 6.1.25 ...
jetty-6.1.25
...
It took me a while to find a copy of Jetty 6.1.25 as it is no longer listed on the Jetty download page (not even in the archive section!).
You can then grab the appropriate copy of webdefault.xml from here, adjusting the version number as appropriate for your needs:
http://grepcode.com/file/repo1.maven.org/maven2/org.mortbay.jetty/jetty/6.1.25/org/mortbay/jetty/webapp/webdefault.xml