We have an application that uses Apache James 2.3.2, which is an older but stable version. We plan to migrate to the latest Apache James 3.4.0 and we have been going through the documentation for the same.
On this page, we see a note that says:
Apache James Server 3.4.0 represents the leading edge of development. This code stream has many more features than the 2.3 code, but is not be as well tested in production. Reasonable configuration compatibility has been retained with 2.3.2.
The above statement was a bit concerning, and we are unsure whether to migrate or stay on version 2.3.2.
What would be the recommended approach?
To answer my own question, I have learned that the recommended approach would be to upgrade to James 3.4.0.
Related
We are using JBoss 7.1.1 and we basically dont pay anything to the Red Hat.
My first question is, since we are not paying for any support, this would be considers as JBoss community edition?
My next question is whats the current status of the JBoss support, is the community edition still considered as supported and where can I find this info?
I' m reading this notes, but I cant conclude anything from it?
There is no support for community bits. The notes that you referred to is applicable for only enterprise (EAP) bits.
JBoss AS project has been migrated to the JBoss WildFly community. The latest community release is WildFly 10 which is based on the JEE7 spec. JBoss AS 7 was a JEE6 implementation.
JBoss 7.1.1 AS isn't supported by RedHat (AS products have now been renamed to Wildfly, which is basically the free version of JBoss). Yes you could say that it is the "community edition" of JBoss.
EAP products such as JBoss 7 EAP are supported, but they are commerical and you have to pay a subscription fee for their usage and support. Redhat typically backports bugfixes, etc. from its commercial versions to AS products, but this isn't guranteed and there is no fixed support cycle or maintenance phases in the case of the latter.
we are using a very old version of java installed previously in our server (version 1.4) and according to this case we used a very old version of iText2.1
Our main vendors planned to upgrade the server and they will upgrade the java version to 8.
Question: should i upgrade my application which uses the iText2.1, or it will work fine with the new Java ver.? and what version should i use then?
Note:i've tried to raise this question in the itext blog but they put the stackoverflow link for any technical question. , so please be kind and help me.
The above comment is really an answer:
I know that in recent versions of iText (I think 5.5.7 or 5.5.8) we made some small changes for Java 7 and Java 8. The minimum for iText 5.x.x is Java 5. Anything older than 5.0.0 is totally unsupported, sorry. iText 2.1.0 is from March 2008, that's 8 years ago.
Using Eclipse
I am Using 1.8_45 with iText5.7
No Exception and warning with it .
So Upgrade
and if you are not upgrade your iText2.1 with java 1.8_45
so it's give you Exception
yes you can easily upgrade your versions
1.8_45 to 66 jdk
with
iText5.7
I am using Netty for a while now and could never solve this question. One can download four different versions. Three of them are actively getting developed.
3.x
4.0.x
4.1.x
5.x
As far as I understand 3.x is for JRE 1.5 and everything else for JREs greater than that. I am using 4.0.28 because it is the stable and recommended version. But what exactly is the difference or goal of the other versions?
I could not find any information about this on their website.
EDIT: I see close votes coming so I'd like to clarify: I'm not looking for someone who lists me all the differences in the code of the versions. But there has to be some sort of objective or purpose for the 4.1.x and 5.x versions.
3.x is deprecated. We maintain it because some users still use it widely.
4.0 is the current stable version. When in doubt, use this version.
4.1 is a backward compatible version of 4.0. It adds some cool new features like HTTP/2 and asynchronous DNS resolver. So, 4.1 is the version you might want to try when your application already runs on top of 4.0 and you wanna try the new features.
5.0 is a backward incompatible version. However, it's not like a rewrite we did for 4.0 vs 3.x. However, we did fix some API design flaws. You'll need to make some changes in your code to make your Netty 4 application run on Netty 5, but it's not like porting Netty 3 application to Netty 4 application. Eventually, 4.x will be deprecated and 5.0 will be a stable version.
It should be noticed that 5.0 had been revoked in Nov 2015, 4.1 is the newest stable version now.
If you want to know what are all new (and noteworthy changes) between these versions, you can visit these links:
3.x -> 4.0
4.0 -> 4.1
4.x -> 5.0
I have got an application which uses Java SE 5 and Hibernate 2.5. I have to upgrade / migrate it to Java 6 and a newer version of Hibernate. What is the best strategy?
Should I directly upgrade to the newest stable release (at the moment: 3.6), or does it make more sense to just upgrade to 3.0?
Is it a lot of effort to do such a migration?
I have no experience with Hibernate yet, but I already used Toplink JPA 1.0 in projects.
Can you give me some hints? Thank you...
Best regards,
Kai Wähner
Depends. If you'll use Java EE, then don't bother with Hibernate versions and focus on JPA 2.0. Hibernate will be just the implementation for the JPA. In case you really need some Hibernate specific feature, then check what's its version based on your AS implementation.
If you are not using Java EE, then I would go with Hibernate 3.6 if I'm planning to deploy my app in some months, or I would use 3.5 if I plan to deploy the app to production sometime next week.
The basic idea is: use the latest GA at the time you put something in production. This way, you ensure that you'll have a "supportable" version for a long time.
It's also worth mentioning that the Community versions are not always supported by the vendor. In this case, you won't get a support contract from Red Hat for Hibernate 3.5 or 3.6. If you need support, then you'll have to chose whatever versions they officially support.
I say go for the latest stable release as it will contain further improvements/bugfixes and give you more benefit overall. There have many changes since 2.5 so the migration will not be trivial, but later on, when you upgrade to subsequent versions, the migration steps will be smaller and easier.
Take a look at the migration guides to help you.
What is the best strategy?
It depends, if you have to maintain a lot of projects. Only do updates if you're working on a project. In other words it it isn't broken don't fix it. If you are still developing and you face problems in libraries then check more current versions which could have the bug already fixed.
Does anyone know if Red Hat has forked the code you download from JBOSS.org? I'm guessing that the answer is "yes", but I'd like to confirm it. I can't pin it down at the Red Hat site, and jboss.org giving me an HTTP 502 right now for some reason.
I know that Red Hat owns JBoss. Does that mean that the code they sell in JBoss Developer Studio for $99 a pop is identical to what I can download from JBOSS.org without paying a fee? Or have they forked the for-fee version in some way?
All the source code for Red Hat/JBoss products is available in opensource (in svn/cvs etc.), but the sold version is what is called the productized version.
What does productized mean ? It means as Michael says, it has additional tests/QA, it has the certified bits, it has matching doc's, etc. It also means that some features in the community version are disabled, removed or have a slightly different configuration default and slightly different packaging.
Examples of differences:
i.e. JBoss EAP comes bundled with Seam, JBoss AS does not.
The productized Seam 1.2 works on JBoss AS 4.3, Seam from .org did not
JBoss EAP has a 'production' profile which is tuned for production (i.e. hotdeploy disabled and other best practices which our support recommend), JBoss AS does not have that.
JBoss EAP gets supported and guaranteed cumulative patches for many years, JBoss AS from .org does not.
All of the above is about having a productized version that is supportable for a long period of time and hence much more about having a stable version than about having the latest-greatest cutting edge version of the latest development.
If you are looking for the bleeding edge then JBoss.org is for you.
To answer you question for Michael, "If I download the code from JBoss.org i'm sure to be using the same stuff that someone who buys it from Red Hat, correct?" - Then the answer to that is: It depends on the project.
Some projects are exactly the same, where as others have more visible differences BUT all features in the productized version is available in the .org version, but there might be some features that exist in .org that has been removed/disabled (see above).
So what to do? If you are looking for bleeding edge, use JBoss.org - if you are looking for making sure you are developing on the exact same set of binaries which JBoss/Red Hat can provide development and product support on for the next many years, then the $99 product from Red Hat you refer to (I assume you meant JBoss Developer Studio Portfolio) is your best option.
btw. the official answer to what the difference is between the community and enterprise (productized) versions is shown at http://www.jboss.com/products/community-enterprise/
For full disclosure: I'm the lead of JBoss Tools and JBoss Developer Studio.
No its not a fork as in different code - its build from the .org versions and put through various tests/QA environments, certified if necessary etc...
Its analagous to what goes on with Fedora and Red Hat Enterprise Linux (I think the idea is to have a similar model) - so if you look into that model it might help explain it better then I can.