JavaMail not working in OSGI(ServiceMix/Karaf) - apache-camel

I created a Karaf Instance on a Service Mix(7.0.1) and deployed my bundles into it.
The camel route is starting up properly, but always fails when it should send an email.
With the following exception:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed;
I tried several solutions i found from different sources around the web, but cannot actually fix it.
I tried commenting javax.activation out in the jre.properties file of the instance, as well as using a bundle that contains java mail and the osgi friendly version of the activation bundle in the same feature.
Could openJDK be an issue here?
Note: Everything works perfectly fine on a windows/oraclejdk environment, the exception only occurs in a linux/openjdk environment.

My issue stemed from a class loader problem after all and i fixed it by bundling javax.mail/mail/1.4.7 and org.apache.servicemix.specs.activation-api-1.1/2.8.0 in the same bundle.
I also needed to remove every occurence of javax.activation from the jre.properties and config.properties file of the child instance.
I am not sure why it ran per default on a different environment, as in theory the same classloader problems should have occured too, but that might be connected to different JREs being in use.

Related

Apache Flink - set plugin folder for local development from IDE (IntelliJ IDEA)

Is it possible to override the location of Apache Flink's plugins folder to a local development environments folder in order to load them from the IntelliJ IDEAs IDE?
I tried to set the env. variable in the Run/debug configurations:
FLINK_PLUGINS_DIR="c:\flink-plugins\"
println("PluginsDir " + PluginConfig.getPluginsDir)
The output is:
WARN org.apache.flink.core.plugin.PluginConfig [] - The plugins directory ["c:\flink-plugins\"] does not exist.
PluginsDir Optional.empty
Does anyone know how to load Apache Flink plugins from an IDE?
TL;DR: When running locally in an IDE Flink uses a MiniCluster with LocalEnvironment or TestEnvironment (for unit tests). Unfortunately, it seems these do not utilize the local environment variables even if they are set, and there is no way to configure them otherwise.
I ran into the same problem wanting to run Flink in my IDE (VS Code) and have plugins. I used (scala) sys.env.get(ConfigConstants.ENV_FLINK_PLUGINS_DIR) to verify the environment variable was set correctly. Additionally, I consulted a unit test in Flink's source and found two things: First, despite setting the environment variable the value in PluginConfig was still the default. Second, overriding the value as is done in the unit test doesn't prevent the error due to plugin not found but it does change the return value of PluginConfig.getPluginsDir. This is probably because the plugins dir must be set at startup for the plugins to be found and loaded.
Looking in Flink documenation it appeared that the environment could be configured, but my attempt didn't work.
val conf: Configuration = new Configuration();
conf.setString(ConfigConstants.ENV_FLINK_PLUGINS_DIR, "C:/Users/ivwebber/Source/MDPLocal/private/MapsAI/projects/TrafficInference/Modules/traffic-forecast-pipeline/plugins/");
val env = StreamExecutionEnvironment.createLocalEnvironment(1, conf);
I think the problem with this approach is that it's not a value that could be set in conf/flink-conf.yaml. I looked in the source and found that the value is never copied to the resultant config. See here too.
This question may be related.
This question may be related.
I probably spent more time than it's worth looking into it, so I think filing a feature request/bug would be the next step. Considering that the token "ENV_FLINK_PLUGINS_DIR" only shows up 4 times in the source; I actually wonder if its never read or used.

Vespa Tutorial – HTTP API use-case fails to activate with IllegalArgumentException

I'm currently following the Vespa tutorials, and ran into an issue with the HTTP API use-case. Everything works fine from the mvn install package to the vespa-deploy prepare target/application.zip.
The call to vespa-deploy activate returns normally, but the application then never gets available on localhost:8080. Looking at /opt/vespa/logs/vespa/vespa.log (in the VM) one finds the following stack trace:
Container.com.yahoo.jdisc.core.StandaloneMain error Unexpected:
exception=
java.lang.IllegalArgumentException: Could not create a component with id 'com.mydomain.demo.DemoComponent'.
Tried to load class directly, since no bundle was found for spec: sample-app-http-api-searcher.
If a bundle with the same name is installed, there is a either a version mismatch or the installed bundle's version contains a qualifier string.
at com.yahoo.osgi.OsgiImpl.resolveFromClassPath(OsgiImpl.java:48)
...
This occurred using a fresh Docker image with a clean clone of the sample-apps git repository. Preparing and activating the basic sample as well as the other http example did work seamlessly.
I checked the sources and the xml files for obvious problems but don't have any clue about what is failing and where.
target/application.zip contains
application/components/http-api-using-searcher-1.0.1-deploy.jar
application/hosts.xml
application/searchdefinitions/basic.sd
application/services.xml
And the jar itself does contain a com/mydomain/demo/DemoComponent.class file (among other things).
Potentially related issue on the github tracker: https://github.com/vespa-engine/vespa/issues/3479 I'll be posting a link to this question there as well, but I still think it's worth a SO question, at least to get some action behind the vespa tag :)
The bundle id in the application's services.xml file was wrong. Please pull the application from git and try again now. See also PR: https://github.com/vespa-engine/sample-apps/pull/18
Brief explanation: The bundle id given in the bundle="<id>" declaration in services.xml must match the 'Bundle-SymbolicName' in the bundle's manifest. When the bundle has been built with the Vespa bundle-plugin, the symbolic name is by default the same as the project's artifactId. Hence, in most cases you just have to verify that the bundle id matches the artifactId.

Firebase access within GAE

It seems that the latest sdk com.google.firebase:firebase-server-sdk:3.0.0 relies on creating threads for most calls, e.g., com.google.firebase.database.FirebaseDatabase.getReference
This is a problem when using GAE since it promptly throws an Exception:
servlet java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThreadGroup")
Are we suppoed to just use the JVM sdk (com.firebase:firebase-client-jvm) instead?
The instructions aren't so clear and it seems like the legacy website is the only one where we can get the secret. The new website gives us the .json file.
Has anyone had any success with using the new v3 version with GAE?
Yes. Just tested.
As with the 2.x SDKs, you can work around the threading limitation by using manual scaling.
While the Cloud guide on using Firebase with GAE is a bit outdated, the section on manual scaling should still be useful to help you through this.
More on ThreadManager here.
I was experiencing the same problem and discovered the cause in this blog thread.
When adding dependences, I had included appengine-java-sdk but overlooked appengine-api-1.0-sdk. Adding it eliminated the exception. The full dependencies block is:
dependencies {
appengineSdk 'com.google.appengine:appengine-java-sdk:1.9.48'
compile 'javax.servlet:servlet-api:2.5'
compile 'com.google.firebase:firebase-server-sdk:3.0.3'
compile 'com.google.appengine:appengine-api-1.0-sdk:1.9.48'
}
Include the JSON file in the "Resource Files" of appengine-web.xml.
Example:
<resource-files>
<include path="/**.xml" />
<exclude path="/feeds/**.xml" />
</resource-files>
See the link https://cloud.google.com/appengine/docs/java/config/appref#resource_files .
"The files that listed in the element are accessible by the application code using the filesystem. These files are stored on the application servers with the app as opposed to how static files are stored and served.".

Jersey linking support with Google App Engine issue

I didn't manage to use the Jersey linking support with Google App Engine, I'm getting these exceptions when trying to access the application :
Caused by: javax.el.ELException: Could not find expression factory class
...
Caused by: java.lang.ClassNotFoundException: de.odysseus.el.ExpressionFactoryImpl
As specified in the documentation, I put this in the Jersey servlet section of the web.xml :
<init-param>
<param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
<param-value>com.sun.jersey.server.linking.LinkFilter</param-value>
</init-param>
I also add the jersey-server-linking-1.13.jar to the WEB-INF/lib directory of my project.
I tried to add el-api.jar first, then juel-2.1.0.jar to the WEB-INF/lib directory but I'm still getting these errors.
I'd like to know if someone could give me some hints about the way to deal with this. When I don't use the Jersey linking jar, everything is working as expected.
I had a similar problem with my GAE app. It was working fine with el-api and el-impl but started asking for de.odysseus.el.ExpressionFactoryImpl as development progressed. I made the switch but when I added JUEL to my pom.xml, I got the same error as John Prince (java.security.AccessControlException).
The solution for GAE users is to use JUEL 2.2.7.
At the time of this writing, 2.2.7 is not available in maven central. However, you can find it on
<repository>
<id>repo-id</id>
<name>repo-name</name>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>
and link with whatever you need from
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-api</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-impl</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>de.odysseus.juel</groupId>
<artifactId>juel-spi</artifactId>
<version>2.2.7-SNAPSHOT</version>
</dependen
Source: https://github.com/beckchr/juel/issues/73
The issue is due to de.odysseus.el.ExpressionFactoryImpl class not being found. I will assume that you have added the jars as you have mentioned to the WEB-INF\lib folder.
I would suggest that you view the JAR files via theProject Explorer , simple expand them in Eclipse and see if you can find the de.odysseus.el.ExpressionFactoryImpl class in ny of the JAR files that you have added.
I "solved" the problem by adding "juel" and "juel-impl" as dependencies of my project (we're using Maven; if you're doing it manually, you might have to figure out exactly what those projects contain).
However, as soon as I did that, I started getting a different exception:
java.security.AccessControlException: access denied (java.io.FilePermission C:\Program Files (x86)\Java\jdk1.6.0_33\jre\lib\el.properties read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
at java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at com.google.appengine.tools.development.DevAppServerFactory$CustomSecurityManager.checkPermission(DevAppServerFactory.java:289)
...
I'm pretty sure that's because it's running afoul of GAE restrictions.
I noticed in the original ClassNotFound exception it was trying to use the URLClassLoader; I'm also wondering if that problem was ultimately a GAE issue as well.
At this point, it seems like Jersey linking support isn't compatible with GAE.
This issue is (or rather was) due to a missing implementation of the Unified Expression Language. The EL API defines a static method that looks up an implementation of the ExpressionFactory class. There are various ways to define which implementation is to be used:
Use the Services API (as detailed in the JAR specification). If a resource with the name of META-INF/services/javax.el.ExpressionFactory exists, then its first line, if present, is used as the UTF-8 encoded name of the implementation class.
Use the properties file "lib/el.properties" in the JRE directory. If this file exists and it is readable by the java.util.Properties.load(InputStream) method, and it contains an entry whose key is "javax.el.ExpressionFactory", then the value of that entry is used as the name of the implementation class.
Use the javax.el.ExpressionFactory system property. If a system property with this name is defined, then its value is used as the name of the implementation class.
Use a platform default implementation.
(Source: http://docs.oracle.com/javaee/7/api/javax/el/ExpressionFactory.html#newInstance())
App Engine appears to have defined JUEL as default implementation but does not provide the respective packages.
In order to solve this, you need to (1) provide EL API and implementation packages and (2) use one of the above ways to link it. See https://stackoverflow.com/a/19814199/2099217 for details.

jTwitter, oAuth, and Google App Engine. NoClassDefFoundError

I'm trying to use jTwitter to get an oauth instance to twitter with my consumer key/secret and access token/secret. This is well documented in the javadoc here. I have downloaded signpost, signpost-jetty, and the jtwitter library, but after deploying and running the servlet, I get a error java.lang.NoClassDefFoundError: winterwell/jtwitter/OAuthSignpostClient Eclipse isn't complaining about the class not being there, because it is there-- I can see it in the JAR file itself, which is in my project. So, I said forget it, I'll try out OAuthScribeClient instead, but this generated a VERY SIMILAR ERROR java.lang.NoClassDefFoundError: org/scribe/oauth/Token This one confuses me even further because I have the following code in my java file, and it compiles without error or warning:
import org.scribe.oauth.Token;
Token token = new Token("myaccesstokeninfo", "accesstokensecret");
Clearly, I'm missing something very fundamental, but I am at an absolute loss as to what it may be. Thanks.
Usually "NoClassDefFoundError" happens when you forget to copy all jar-files to your "/war/WEB-INF/lib" directory, so those libs will be unavailable from server-side.
Xo4yHaMope is probably right.
If you're working from Eclipse but running using a web container, then your runtime classpath might be different from your project classpath - which can cause this error.
In order to complete Ben Winters answer what I actually did and worked is add the jar in
the libs folder within the project
see also here about folder hierarchy.
When you do this eclipse will normally add the jar to the android dependencies before launching the application. What I realise is that adding a jar in the build path will make classes available only during the build

Resources