I am new to glassfish. When I add Glassfish server in Eclipse Juno, I have to choose between Glassfish 3.1 and 4.0 server, which is better supported? which specific features do they have?
This is what I saw in glassfish doc:
GlassFish 4.0 is intended to be the next major release in Project
GlassFish. This release will implement the Java EE 7 specifications,
contribute to the Java EE 7 Reference Implementation and Development
Kit. The release is being designed with primary focus on the following
features :
Higher Productivity
HTML5 Support
GlassFish 3.x supports Java EE 6. GlassFish 4.0 will support Java EE 7. A vast majority of new features in GlassFish 4.0 are actually Java EE 7 features. To find out what's new in Java EE 7, register for next week's Java EE 7 Live Launch Event and you can learn what's new.
GlassFish 4.0 is nearly final. Wait a few days (literally only a few more days) and you'll be able to download the final release of GlassFish 4.0.
IMHO, just use GlassFish 4.0. FYI, the early builds of Eclipse Keplar already have support for Java EE 7 projects and GlassFish 4.0. The Juno GlassFish plugin will also be updated to support GlassFish 4.0. We'll also update the GlassFIsh IDE Plugins page next week with more information.
Glassfish 3.1 - Java EE 6 compliant server.
Glassfish 4.0 - Java EE 7 compliant server.
Related
I am using Mule 3.9 with Anypoint studio 7.2 for API development. After my functionality developed I was able to export to a Jar file which I was supposed to run on my hardware which doesnt support x64 architecture.
I got error of not supported architecture. So I am looking for solution in 2 ways.
As hardware architecture cant be changed, is there any way to still run Mule program on it without using Mule runtime environment.
Using exported Jar file is it possible to use it only without Mule installed on my hardware machine.
Thanks in advance.
As per comment See error message,when tried to run in Docker also.
Mule uses the Java Service Wrapper to bootstrap the Mule runtime. At this time the version of the wrapper included with Mule previous to Mule 4.4 doesn't support aarch64 as an architecture, only 32 bits ARM (armhf). At this time only Mule 4.4 Enterprise Edition seems to has compatibility with armhf-64. You should try that version to see if aarch64 is recognized as armhf-64.
Also note that Studio 7.x is not compatible with Mule 3.x applications so it is not possible to use it to develop a Mule 3.9 application. You are saying that the deployment file is a jar file so it is clearly a Mule 4 application. A Mule 4 application can not be deployed to a Mule 3 server, they are not compatible.
I am working on a project that is currently using an early pre-release .net 4.0 version on HttpClient in System.Web.Http namespace. We know that this version causes conflicts with .net 4.5 version.
We are thinking of upgrading to Visual Studio 2012 and we know that this is going to install .net 4.5 (which we dont currently use). My question(s) is, how drastically different are the two version of the HttpClient class? Or, would the use of the latest .net 4.0 version of HttpClient be enough to get us to a stage where we could install .net 4.5 and not have any conflicts?
Cheers
NCBL
The two versions are identical from an API perspective and 4.5 is backwards compatible with 4.0 from a functionality perspective. The 4.5 version does support a couple new features on WebRequestHandler (ContinueTimeout & ServerCertificateValidationCallback) so avoid those.
You shouldn't run into any conflicts when using this library and running on 4.5. The 4.5 version has the same name as the 4.0 version and the framework will unify to the inbox version.
We are using mule (enterprise edition) and are debating whether to use EE jars (whenever available) or CE jars. Is there a reason to go one way or another. The application is eventually going to deployed in Mule Enterprise edition.
You need to use the EE jars in order to have the EE versions of the XML schemas to resolve properly.
I have an EJB 2.1 project, works on WebShere 7. I must migrate it to WebSphere 8.
Which one is the better (less effort) approach:
First convert the project into an EJB3.1 project then migrate into Websphere. If yes, is it easy to do that by a large project?
Adapt the project till it works on Websphere8 (What should be taken into account)
Thanks??
The easiest approach is to do nothing: WebSphere Application Server v8 supports EJB 2.1 just as well as v7. Why risk changing something that isn't broken?
What is the simplest way to convert EJB 2.0 (WebLogic 8.1) project to EJB 3.0 (OAS or WebLogic etc)?
I found just this article "Converting an EJB 2.0 Entity Bean to EJB 3.0", which could automate this process, but forced to do too much manual manipulations.
IMO, you can't really convert an EJB 2.1 project to an EJB 3.x project. You can however migrate and this is a project by itself. Some more resources:
Migrating EJB 2.1 Entity and Session Beans to EJB 3.0
Migrating EJB 2.x applications to EJB 3.0
Use Intellij's "Apply EJB 3.0 Style" tool. It automates a lot of the painful steps, especially replacing ejb-jar.xml configurations with annotations. Migration can be applied incrementally (you select the ejb's) or all at once. It does other steps for you as well; details here:
http://www.jetbrains.com/idea/webhelp/migrating-to-ejb-3-0.html
I found this to be immensely helpful and worth the price of an Intellij license all by itself for the number of hours it saved me. I did not find anything comparable in either Eclipse or Netbeans.
An old, but helpful, additional resource:
http://www.javaworld.com/javaworld/jw-08-2006/jw-0814-ejb.html?page=1