JBoss 7 on FreeBSD - jboss7.x

I heard that JBoss 7 is not certified for FreeBSD - is that correct?
Where can I find a list of supported platforms? (I spent some time googling, but was not successful)

Strictly speaking there is no certified OS for JBoss 7 as only JBoss EAP 6 is supported by Red Hat.
The supported configuration for JBoss EAP 6 (the supported version of community JBoss 7) can be found here: https://access.redhat.com/knowledge/articles/111663
As JBoss is pure java application, a compliant JDK is enough to have a supported system. So if you have the Oracle or IBM JDK running on FreeBSD is will be supported by Red Hat. But they haven't test them with JBoss.
Any way if you want Red Hat support for the EAP you better check with there representative to discus the extends of the support (if the FreeBSD JDK have some compliance bug, they will probably send you back to the JDK supplier. If you chose RHEL with OpenJDK you will have one supplier to blame for any software stack issue, no redirect to another suplier.)
For community JBoss as for other platform, you will be responsible to make it work with your stack. An good first test can be performed by running the standard compliance tests included in the JBoss sources, if it runs on your target platform and JDK it is a good sign that JBoss is working on it.

Certified Support as per Redhat only goes up to 6:
https://access.redhat.com/knowledge/articles/111663
However if you look back at the release docs they have not changed. OS's are the same.

Related

Is jboss 4.2.2 GA compatible with java 11?

We have a product that is running fine with JBoss 4.2.2/java 7.
We are now moving to JDK 11. simply added java 11 in the classpath and tried starting the server.
Encountered below error
OpenJDK 64-Bit Server VM warning: Ignoring option MaxPermSize; support was removed in 8.0
-Djava.endorsed.dirs=C:\PathBuilder\GE\EMEA\vp\jboss\lib\endorsed is not supported. Endorsed standards and standalone APIs in modular form
will be supported via the concept of upgradeable modules.
removed below configurations from run.bat and started the server again
-XX:MaxPermSize=128m
"-Djava.endorsed.dirs=%JBOSS_ENDORSED_DIRS%"
now getting below error and which is
interrupting the ear deployment Caused by:
java.lang.ClassNotFoundException: No ClassLoaders found for:
org.omg.CORBA.Object
Is Java 4.2.2 compatible with JDK 11 or we need to update JBoss to 7.2 or latest versions?
can someone help with this or provide related links?
JBoss 4.2 is a very old and outdated version and it only tested with JDK 1.5 and 1.6 version. If you are upgrading your JDK to 11 then you should update the JBoss to 7.3 version which is the latest available GA release from Red Hat.
You can download the jdk files of older versions like jdk6 and then replace JAVA path in the jboss run file from "set JAVA=%JAVA_HOME%\bin\java" to
"set JAVA=C:\Users\jdk1.6.0_45\bin\java"
Of course it's better to upgrade to a higher JBoss version... But in case that's not possible, you can avoid the ClassNotFoundException for org.omg.CORBA.Object by placing rt.jar from Java 8 in your JBoss-libs folder.
With this configuration you can run older JBoss versions with Java 11.

Choosing the right IBM MobileFirst version for implementation

There are multiple versions of IBM mobilefirst platform available. What are the different decision points that need to be considered for choosing a particular IBM mobilefirst version for implementation?
There are only two versions that should be considered at this time: 7.1 and 8.0, and the only reason to choose 7.1 is if you've already invested in a version older than 7.1. The reason I say that is because V8.0 is rearchitected in a number of significant ways that make it more suitable for Cloud deployments and Open development models. Therefore, the cost to migrate from an older version to V8 is somewhat greater than to migrate to 7.1, and 7.1 will continue to support all the latest mobile operating systems. V8 on the other hand has many new features that 7.1 will never have (as you'd expect) If you're looking to play with the technology, go download the free DevKit from https://mobilefirstplatform.ibmcloud.com/.
So bottom line: If this is a new deployment/purchase/etc. then I'd always suggest V8 as the preferred choice. However if you already have an investment in older versions, V8 is still the preferred choice, but migration to V8 may take more time than to migrate to 7.1.
Does that answer your question?
Mobilefirst 7 or 7.1 will be most reliable as of now since it has been in the market for some time and most of the pmr's would already be resolved. Within 7 and 7.1 itself there are few changes like 7 has desktop browser environment which is not present in 7.1. So you would want to check out the differences before chosing 7 or 7.1. But personally I would recommend you to go for mfp8 since there are lots of new features added into it. It might be a bit unstable but eventually everyone would upgrade to 8 is what I feel.

Upgrading Worklight 6.2 to MobileFirst Platform 7.0

We are using Worklight enterprise 6.2 with fix packs and we are planning to upgrade to 6.3 in the next month (beginning of May 2015). However, we see now that IBM is about to release MFP 7.
Can you please clarify to me those queries:
What is the impact on the project which has been developed on version 6.2 to be moved to 6.3 or 7?
What is the recommendation for us in terms of upgrading, should we go immediately to WL7 or to 6.3 first?
We are very close to the production and our concern that the WL7 "might" be unstable or contains issues that we might face in a critical time."Feedback would be appreciated"
MobileFirst Platform Foundation 7.0 is not about to be released - it is already released.
Lots of changes in both 6.3 and 7.0. Read the documentation to see what's changed...
6.3: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
7.0: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
In terms of your project structure, starting 6.3 the adapter thread pool has been removed and you are now in complete control of it. Your adapter XML will be upgraded to the new structure.
In terms of technology, starting 7.0 there is REST support together with a new authentication mechanism - OAuth. Classic authentication is as before and is still there. There are also now Java adapters in addition to JavaScript adapters, and lots more.
7.0 is indeed new, but provides you with a lot of new possibilities.
6.3 is very stable (that is not to say that 7.0 is not stable, but it's also very new).
We cannot decide for you if to upgrade or not, it sounds like you are already considering the right things to consider.
Read about the two releases.

Tool similar to Dynamic code evolution with java 7 support

I have been using the dynamic code evaluation for dynamic loading of my changed classes in my Jboss server ,
I have found this tool very helpful and interesting , but it have a problem that it works with jdk 1.6 , but As i am trying to use java 7 in my project it fails .
Can anyone suggest similar type of tool with java7 support
I suggest using... the Dynamic Code Evolution VM for Java 7 :) The DCEVM web site is not up to date and the version available for download there doesn't work with the latest versions of Java 7. For some time the Mercurial repository contained a more recent version and it has been eventually forked on Github where binaries for Windows and Linux are provided. On Debian/Ubuntu DCEVM is also available after installing the openjdk-7-jre-dcevm package.

Is the OpenJDK JVM the same as the Oracle Java SE JVM?

I understand that the Oracle Java SE contains closed source extensions and tools that are not part of the OpenJDK however is the Oracle Java SE JVM identical to the OpenJDK JVM or does Oracle make changes to the OpenJDK JVM before releasing it as a Java SE JVM?
Update 1:
I found some info from the JDK7 updates projects: http://openjdk.java.net/projects/jdk7u/qanda.html
Will the 7 Update Project receive security fixes from Oracle?
Yes.
As with OpenJDK 6, security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to effected JDK release trains. In addition, they will not go through the public code review and putback approval process, and their corresponding issues in the Project's issue tracker will not be publicly visible.
OpenJDK is the reference implementation of Java as of version 7.
OpenJDK 7 is the starting point for the version that Oracle distributes as Oracle JDK. Other vendors (e.g. RedHat for IcedTea) may also use OpenJDK as their starting point.
In terms of the differences between OpenJDK and a vendor VM, there may be patches which a vendor wants to apply but which the overall OpenJDK community has not accepted into mainline.
Vendor VMs must, of course, be able to prove that they are in conformance with the TCK if they want to use the Java trademarks to describe their product.
Oracle JDK is also not open-source. This is possible because of Java's dual licensing arrangements, and the fact that Oracle own Java overall.
Do you have more specific questions - as posed, your question is a bit vague. What specific aspects are you interested in?