We are using SpringSource-TC-Server and we are considering upgrading to java7. (Currently using java6).
We have not seen any reports on SpringSource-TC-Server not working well with java7 but we do not know of any name worthy projects that have migrated to such an environment.
I'm looking for answer(s) about the following:
Are there any known issues?
Are there any projects who migrated and can report on how it went?
Java 7 is officially supported since vFabric tc Server 2.7.0:
http://www.vmware.com/support/vfabric-tcserver/doc/vfabric-tcserver-rn-2.7.0.html#whatsnew
Since you're using tc Server instead of plain Tomcat probably due to commercial support, it's reasonable only to migrate the underlying Java JDK to the latest version when it is officially supported by the employed version of tc Server. Otherwise, you'd be running it in an unsupported configuration, which isn't far from running a plain unsupported open source version of Tomcat.
Operating tc Server on Java 7 in an officially supported arrangement of versions gives you 2 advantages:
It would have been thoroughly tested by vmWare for any incompatibilities so that you wouldn't have to deal with testing by yourself.
If any problems do occur, you can always get support from vmWare in resolving them.
I know it doesn't directly address your questions, as we in my company also haven't upgraded yet and are only planning to do so.
I just had an impression that your approach makes no sense for a commercially supported product and wanted to outline the reasonable (IMO) approach that is in wide use.
As to any known issues, Java 7 is known for its backward incompatible changes to the XML stack, especially the migration to JAXB 2.2 which changes handling of java.lang.Boolean objects (see the other question - What are the pitfalls when upgrading to Java 7). This can spring up in many different places, I've seen it cause problems in Apache CXF's cxf-codegen-plugin that generates Java stubs from WSDL since the wsdl2java tool it launches makes use of JAXB - the generated method names for boolean elements were no longer in the form of java.lang.Boolean isSomeBooleanProperty() but in the form of java.lang.Boolean getSomeBooleanProperty() which broke code depending on those stubs.
So perform thorough testing if you deal with SOAP web services or XML in general.
Related
I'm developing an Eclipse plugin and i've run into this problem several times already.
I always keep my Target Platform updated for the latest (stable) Eclipse release so that i test my code against all the recent updates, fixes etc.
However, this may (and have) result in accidental breakage of backward compatibility of my plugin, e.g. when i accidentally use new API that did not exist in the Eclipse version i aim to support.
Or, more sneaky example, in 4.6 Eclipse moved to Java 8 and some interface methods got default implementations. Now when i implement these interfaces my IDE doesn't automatically generate empty implementations for those methods and no error is generated. If i install and run this code against a previous Eclipse version these methods will throw AbstractMethodError since no implementation has been provided.
So my question is: is there a tool to further restrict API my Target Platform provides to some earlier Eclipse API version?
Is API Baseline an appropriate tool for this? Because i couldn't get it to work like this. (It allowed even non-baseline method calls not to mention the more complex default-methods example.)
You can use multiple target platforms, switching between them doesn't take long. For testing Stack Overflow questions I have one Eclipse install with 10 target platforms.
So have a target platform for the oldest release you want to support as well as your current release target platform and check the code runs against that.
It is particularly important to test with the actual Target Platform if you want to support Eclipse 3 releases as the were large changes going from Eclipse 3 to 4.
I'm trying to deploy my application in JBoss AS 6. Currently it is deployed in JBoss version 4.
So what are the things I need to consider when doing this?
Any help will be highly appreciated. Thanks.
You're talking about two major versions change, so, expect a lot of things to happen. Some steps that might be helpful:
Make an inventory of everything that is JBoss-specific in your project: deployment descriptors being the most common examples, but you might also be implementing some specific classes for your own use, or things like that
Make an inventory of the Java EE APIs that you are using. For instance, JPA 1.0, JSP 1.1 and so on. With those, compare with the APIs that are available for AS 6. I guess that most of your work will be centered here.
You might also want to take note of changes in the Java version (AS 4 was released during the days of Java SE 5, IIRC).
Finally, you might want to take a look at the Windup project, which is a tool that can help you migrate your applications to JBoss AS. Note, however, that it will not give you a comprehensive list of everything you need to do, but will certainly give you good hints.
One last comment: you might want to consider migrating to JBoss EAP 6, which is JBoss AS 7, or even migrating to Wildfly 8 (the successor of JBoss AS 7).
I just installed rapidSQL 8.0.1 and tried connecting to a valid database. I'm fairly certain I have the right connection data (it was imported from another developer), but I'm getting the following error:
db2abind.dll Cannot be loaded! That will severely impact use of this application. Please restore the missing library.
I have created a ticket with Embarcadero, but I was wondering if anyone else has had this problem and have a solution.
According to the publib, db2abind.dll's functionality has been moved into db2app.dll since version 9 for Linux, Unix, Windows. It also mentions that at that time, stub DLLs were provided for convenience sake, but would be removed in a future version.
Since LUW is now on version 9.7, perhaps this removal has taken place.
Application libraries have changed
Operating systems affected
All supported operating systems are affected.
Change
The following changes have been made:
db2app.dll was extended. It includes its original information, plus
the information from the db2util.dll, db2abind.dll, and db2cli.dll
libraries. db2api.dll was extended. It includes its original
information, plus the information from the db2cli.dll library.
Explanation
The library information is being consolidated.
Resolution
Stubs for the db2util.dll, db2abind.dll, and db2cli.dll
libraries are still available for backwards compatibility. These stubs
will be removed in a future version or release of the product. You
should rebuild your application using the changed libraries.
So this was being caused by the fact that I didn't have a DB2 client installed on my machine. I chose a light db2 client from among the many(!) available at IBM, and it got me past this issue.
http://www.db2dean.com/Previous/DB2Client.html
The above link was a good resource on understanding what was going on with IBM clients and DB2 connectivity.
I have inherited an application that is running on JBoss 2.4.3 (which I believe is EJB spec 2.0 compatible), and I'm running into quite a few issues (like being able to use modern log4j "Logger" apis [JBoss 2.4 specific issues pushing me to upgrade]).
I understand that I should be able to use a EJB 2.1 container (Jboss 4) without issue, but should I expect to be able to go further?
What are the backwards compatibility requirements for EJB?
Are they meant to be backwards compatible through major versions?
Do application vendors make them fully backwards compatible?
What modifications are necessary to make an older application conform? (small or large? application configuration or re-compilation? etc)
log4j and EJB 2.0 are not related. If you have problems with log4j, then most likely it is a class path issue and not EJB 2.0 compatbility issue. Probably your old application assumes that log4j is somewhere on system class path.
http://what-when-how.com/enterprise-javabeans-3/backward-compatibility-and-interoperability-with-ejb-2/ states that
The EJB 3 specification requires that all complying containers support EJB 2
Which is a good sign. It goes on further to talk about mixing EJB 2 and 3 functionality. So there may be some exceptions, but it really shouldn't be any where near impossible.
Reality may be different; I'll update if I find problems with my jboss upgrade.
See this compatibility report for the EJB library:
I need to use some EJBs which are deployed on JBoss version 4.x from another EJB deployed on JBoss version 3.2.x. Is this possible?
I ask because I have a third party application which uses some strange bridge's to do that and don't know why (though I haven't try to do this on my own).
This is unfortunately not possible. One of the major drawbacks of remote EJBs is that there is nothing in the specification that guarantees or even suggests any kind of interoperability between different vendors or between different EJB versions from the same vendor.
In practice I found that at least with JBoss AS it never works. Even minor upgrades break binary compatibility completely. There have been some very hacky attempts with special class loaders that are only been given access to the client libs of the target JBoss AS, but this is very tricky to get right.
I guess this "strange bridge" you are talking about is using such a trick. Kudos to whoever build that bridge for getting this to work at all.
See this topic I started on the JBoss community forum for some more details: http://community.jboss.org/message/587180