I try to use jain sip API in an OSGi bundle, when i use it in a standard java application, it seems to work when I import the log4j jar. But when i don't import it, i catch an exception when I use the Sipfactory.createStack(Properties p) function. From what i saw in my researches it's because the log4j jar is absent.
Now when i try with an OSGi environment i have the same problem, even when I try to put the lib log4j with the jainsip jars. I just don't know how to make it work, maybe there is a specific manipulation to be able to use log4j.
Moreover i already have another plugin using log4j, i tried to export the log4j lib from this bundle and to import it in my jainsip bundle but it didn't work too.
JAIN-SIP uses log4j-1.2.15.jar. Have you checked if that version of log4j makes any difference?
Related
I have two bundles, one is DB related and another one simple. DB bundle will export osgi service reference. Another one will get the service reference.
It is working fine when installing one by one. The service reference is null when starting the Jboss fuse karaf container.
Can i set bundle ordering ? or Can i set delay for completing DB bundle?
I need to install bundle after completing DB bundle.
Advance Thanks.
The actual code you have to write depends on how your bundles start. Do you use a Java class as BundleActivator? Spring? Blueprint?
Generally speaking, each bundle must specify its dependencies. There are 2 kinds of dependencies:
dependeny on some classes in packages exported by other bundles
dependency on a service provided by some other bundle
Your bundle should declare packages and services (Java interfaces) it needs. This way you "force" JBoss/Karaf to start bundles in the correct order and avoid null service references.
Have a look at this guide:
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html-single/Managing_OSGi_Dependencies/index.html
I have a collection of XD job modules that all use log4j logging. I have recently upgraded to Spring XD 1.3.1 and my modules are no longer logging.
I have tried adding my packages to the xd-singlenode-logback.groovy configuration file. This has no effect.
I have created a dummy module using slf4j, which logs correctly.
I have tried to find any information on log4j and logback compatibility, but haven't found a definitive answer.
Do I have to switch out log4j with slf4j, or is there something I am missing.
Do you have log4j on the classpath?
xd/lib contains log4j-over-slf4j-1.7.12.jar which should convert your log4j calls to slf4j which in turn calls logback.
You should not have the real log4j on the CP for this to work properly, though.
I receive the error java.lang.NoClassDefFoundError: org.codehaus.jackson.map.ObjectMapper even after adding the Jackson jar files. In Android Studio?
Also tried a few links. Namely this, which did not help.
Edit:
After some research I discovered the root of the error. The dynamo-geo.jar library that is provided by Amazon is inherently flawed in that it refers to some sort of outdated Jackson version. Upon looking in I can see that the class that is called geoJsonMapper refers to a deprecated version of ObjectMapper from the old 1.x.x versions of Jackson. I opened source code from dynamo-geo.jar here and I edited the ObjectMapper import from the outdated version to import com.fasterxml.jackson.databind.ObjectMapper;.
Now the issue I have is I am not sure if there is a way to compile a JAR file in Android Studio? In order to get the newly updated library into my other Android Studio project?
EDIT:
Solution - read this.
If you are using Jackson 2 then you will want to import com.fasterxml.jackson.databind.ObjectMapper instead of org.codehaus.jackson.map.ObjectMapper. You may also have a mix of Jackson 1 and Jackson 2 JAR files in your classpath.
You should be able to fork dynamodb-geo, make your changes, and use Maven to package the new JAR file (run the command mvn clean package). The new JAR file would be located in /dynamodb-geo/target/.
I'm completely new to OpenShift and so far ran in hundreds of bugs while trying to create my first application. Now I want to configure Maven to use my own goals. So far I tried:
adding a Jenkins and configuring the Maven Build - the Jenkins didn't take up the changes and finally stopped building altogether
adding a file .openshift/action_hook/pre_build with the content export MAVEN_ARGS="clean package -Popenshift" as explained here
adding a file .openshift/action_hook/build with the content mvn clean package -Popenshift as explained there
Evidently, the documentation is somewhat obsolete... so what is the correct way?
I finally managed to get the Jenkins to build with my goals. The misconception was that it would use the configured Maven goals INSTEAD of the default ones, when it would just use them additionally (he never had to, since the shell script failed). So deleting the script and adding a custom Maven build works.
My question is a little bit common, but it is linked with Gradle too.
Why we need compile and runtime configuration?
When I compile something I need artifacts to convert my java classes in bytecode so I need compile configuration, but why is needed runtime configuration do I need something else to run my application in JVM?
Sorry if it sounds stupid, but I don't understand.
In the most common case, the artifacts needed at compile time are a subset of those needed at runtime. For example, let's say that a program called app uses library foo, and library foo internally uses library bar. Then only foo is needed to compile app, but both foo and bar are needed to run it. This is why by default, everything that you put on Gradle's compile configuration is also visible on its runtime configuration, but the opposite isn't true.
Updating the answer as per the latest gradle versions.
From gradle's official documentation at below link:
https://docs.gradle.org/current/userguide/upgrading_version_5.html
Deprecations
Dependencies should no longer be declared using the compile and runtime configurations The usage of the compile and runtime
configurations in the Java ecosystem plugins has been discouraged
since Gradle 3.4.
The implementation, api, compileOnly and runtimeOnly configurations should be used to declare dependencies and the compileClasspath and
runtimeClasspath configurations to resolve dependencies.
More so, the compile dependency configuration has been removed in the recently released Gradle 7.0 version.
If you try to use compile in your Gradle 3.4+ project you’ll get a warning like this:
Deprecated Gradle features were used in this build, making it
incompatible with Gradle 7.0. Use ‘–warning-mode all’ to show the
individual deprecation warnings.
You should always use implementation rather than compile for dependencies, and use runtimeOnly instead of runtime.
What is an implementation dependency?
When you’re building and running a Java project there are two classpaths involved:
Compile classpath – Those dependencies which are required for the JDK to be able to compile Java code into .class files.
Runtime classpath – Those dependencies which are required to actually run the compiled Java code.
When we’re configuring Gradle dependencies all we’re really doing is configuring which dependencies should appear on which classpath. Given there are only two classpaths, it makes sense that we have three options to declare our dependencies.
compileOnly – put the dependency on the compile classpath only.
runtimeOnly – put the dependency on the runtime classpath only.
implementation – put the dependency on both classpaths.
Use the implementation dependency configuration if you need the dependency to be on both the compile and runtime classpaths. If not,
consider compileOnly or runtimeOnly.