I have downloaded the spring-batch-admin 1.3.0.RELEASE project, and updated all of the library references to the most recent RELEASE versions so that they are compatible with my spring-batch environment (eg. spring-xxx 4.1.4.RELEASE).
I have applied the environment settings and overrides per http://docs.spring.io/spring-batch-admin/getting-started.html . However, those overrides are not being recognized.
At least one email chain linked this symptom to the jira issues linked to https://jira.spring.io/browse/SPR-12111 , but those are allegedly fixed in spring core 4.1 .
Since the problem appears to be that the XML files in the project are not being scanned at all (only the ones embedded in the jar files), it seems to me that here should be some obvious way to work around this, even if it is not technically a "fix".
I am open for suggestions.
I resolved this by downloading the latest 1.3.1.RELEASE source from github and building it without any modifications.
Related
I have two library plugins, each of the same library that have the same API, but different versions
One of the library plugins has the following in the MANIFEST.MF:
Export-Package: com.package1.packagename1;version=1.0.0,
com.package2.packagename2;version=1.0.0
The second library plugin has the following defined in the MANIFEST.MF:
Export-Package: com.package1.packagename1;version=1.1.0,
com.package2.packagename2;version=1.1.0
The plugin that uses this API has the following defined in the MANIFEST.MF:
Import-Package: com.package1.packagename1;version="[1.0.0,1.1.0]",
com.package2.packagename2;version="[1.0.0,1.1.0]"
When the plugin that is using Import-Package is activated,
it checks a preference value to determine which version of the library
the user would like to use. The Activator then uses
bundle.stop()
bundle.uninstall()
for the library version that is NOT wanted, leaving only the one plugin available to satisfy the
Import-Package. Up to this point, everything functions as expected and the correct version of the
library can be used without error.
The problem comes in when changing versions. When a user changes the library preference, currently,
the application shuts down and asks the user to restart it manually. This guaruntees that the JVM and platform
both restart so that I can programmatically stop and uninstall the other version of the plugin. However,
when the library consumer plugin attempts to invoke the remaining installed version of the library plugin,
the following exception is thrown:
java.lang.LinkageError: loader constraint violation: loader (instance of
org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) previously
initiated loading for a different type with name "com/package1/packagename1/ClassName"
There was a similar problem here, but the solution seemed to be rename some of the packages to just avoid the issue. This solution will not work for me as the entire point is them having the exact same API and just changing out the underlying library version.
Restarting the JVM and Platform again without changing the preference fixes this issue, but I'd much
rather find a solution that doesn't require users to restart the application two times to change
a library version. Is there another way to solve this problem to avoid this linkage error?
It sounds like the classloader using the other library is still active.
You have to make sure the bundle using the library is not holding any references to objects and classes when it is stopped. Only then can the bundle classloader be cleaned up.
Additionally you have to refresh all bundles using the library. This will rewire them to the new library.
I am trying to rebuild a grails application using ggts 3.4.0 with groovy 2.1.8, grails 2.3.3 and java 1.7.
In the services files I'm getting these error messages:
Groovy.class grails.transaction.Transactional is not an annotation in #grails.transaction.Transactional
I believe that one of the components listed above is causing this problem. Can someone suggest which particular one and the required version I need?
Incidentally, I've successfully built this in the past with different versions of the various components but I'm not sure what they were. I do have backups - so if you can suggest where can I find details of these builds that would help.
I would welcome any suggestions?
-mike
I'm writing a GAE project in Java and now, I'm trying to create a different version to use it for testing future changes.
I read about modules, app-engine-web.xml..., but I can't find how to deploy two versions.
I have seen posts that say that you can access it by changing the url:
"version"."app_id".app...
But I don't know what files have I to modify.
In appengine-web.xml you can use the version tag to specify a version. Likewise when deploying using appcfg you can use the -v argument to override that value with a different version.
So one approach is to have a production version specified in the config file and a testing version you deploy with
appcfg -v test_version ...
I'm developing an application that should run on a server. The application uses some external jars.
I have build the application and run it on a local machine without a problem.
Now, I need to deploy it on the server. The server has some of the jars located.
What should I do to make my application work on the server, using the jars that are already there?
I don't have much experience with Java, but I understand that there is a manifest file which has a class-path field that points to all the jars needed. Should I change the manifest "manually", so that it points to the location of the jar on the server? What do you do in situations like this, what is the correct procedure?
Also, if I use one version of jar during development, and there is a bit older version of that jar on the server, what should I do to perform the deployment correctly?
And what is the procedure in case of using maven, should I copy the jars from where it locates them on the local drive to one directory, or is there a way for maven to do it itself?
I'm using NetBeans btw.
Thanks
Re "using the jars that are already there":
See Introduction to the Dependency Mechanism, Dependency Scope: "provided ... indicates you expect the JDK or a container to provide the dependency at runtime."
Re "there is a bit older version of that jar on the server":
Update the library on the server or use the older when developing. I'd consider it a really bad idea to use different versions of a library for developing and runtime. This can lead to subtle errors that are hard to identify.
Re "And what is the procedure in case of using maven":
Does the introduction linked above help you in answering this as well?
Maven is supposed to work the same with any type of IDE.
I am new to Java and experiencing problems understanding exceptions thrown by the framework.
Right now, I am trying to implement a regular expression validator into an application consisting of Java 5 EE with myFaces 1.2 and Tobago running in an apache tomcat 5.5.
I followed a couple of tutorials (including the Java 5 EE tut from SUN) and came pretty far. However, when calling my jsp, I get the following error message:
java.lang.LinkageError: loader constraints violated when linking javax/faces/validator/Validator class
Can anyone explain to me what I need to do to solve this problem?
So far, it seems as if MyFaces 1.1.7 has a version conflict to TomCat 5.5. Both contain javax.* packages (one of them namely javax.faces.validator). The validator class has a different version in the packages. The corresponding MyFaces library is called myfaces-api-1.1.7.jar and the TomCat library is called javaee.jar.
The included javax packages in the myfaces lib is a subset of the packages from within the javaee lib. However... I cannot skip any of both, because the project will fail to start then.
Any tipps?
This is almost certainly caused by your application having its own copy of Validator (in one of its JAR files), and this is clashing with the server's own copy. Something this can cause a LinkageError.
Find out which of your WAR or EAR's JAR files contains that, and remove it (along with the rest of the javax.faces classes).
Sounds like a classpath problem. Check your classpath for two jars with conflicting versions (both containing the javax.faces.validator.Validator class)
According to the MyFaces homepage. Tomcat Config: Tomcat 5.5.x
Some users have reported problems when
using MyFaces with Tomcat 5.5.x. Here
is a short guide that will hopefully
help you not run into the same
problems :-)
If your are using the binary version
of MyFaces: MyFaces is packaged so
that it works with Tomcat 5.0.x so
the WEB-INF/lib/jsp-2.0.jar and
WEB-INF/lib/commons-el.jar JAR files must be removed from your
WAR files (including the examples).
If you are building from source: If
you want to build MyFaces from scratch
to work with Tomcat 5.5.x, you have to
set the property
tomcat.pre.5.5.version in the
$MYFACES_HOME/build/build.default.properties
file to the value false.
Perhaps you've got two conflicting versions of the same library available on your classpath. For example, you might have a jar file in WEB-INF/lib that's already provided in TOMCAT_HOME/lib. (el-api.jar is a common culprit, but there are other possibilities.)