I would like to know the steps to integrate OSGi with WildFly-8.2.0.Final.
I have followed https://docs.jboss.org/author/display/JBOSGI/Getting+Started?_sscc=t but it is for older version and thrown exceptions on startup.
Please share if you ave any idea.
Thanks!
OSGi is no longer part of WildFly distribution.
However, community member Arcadiy Ivanov picked up the projected and released compatible version for WildFly 8.2
see http://ivanov.biz/2015/jbosgi-for-wildfly-8-2-released/ for more
Related
I've googled to find detailed working tutorial for update Jboss Wildfly resteasy to latest version (3.0.17) but seems without solutions.
I'm testing on wildfly 10.0.0.Final release-version: "2.0.10.Final"
with resteasy core version. First question how to list (from shell or from Gui) all core modules version in use?
From official documentation i'm using jboss-jaxrs-api_2.0_spec-1.0.0.Final version but i want use for my project resteasy 3.0.17
I can accept globally upgrade and/or instruction to use resteasy 3.0.17 only in my war project "bypassing" core wildfly resteasy implementation.
I read official Jboss Resteasy upgrade but without success.
Is there some guide or complete tutorial about manage modules on jboss wildfly ?
Or someone has already had these headaches and can share suggestions ?
Have a look at this post from JBoss forum:
https://developer.jboss.org/thread/274219
Basically from Wildfly 11 it will be possible to see the module versions on console and in regards to the upgrade, it's manual work.
I need to migrate from Jboss 5.1.0 GA to any other that supports jdk 1.7.
I'm currently using jboss 5.1 with seam 2, jdk 1.6 and sqlserver 2008 r2.
What community version of Jboss is recommended for jdk 1.7 and why?
Thanks in advance!
You can actually get JBoss AS 5.1.0 GA to run on JDK 7, see JBAS-6981. All of the following options will work with JDK 7:
JBoss AS 5.1.0 (plus the fix for JBAS-6981)
JBoss AS 6.1.0
JBoss AS 7.1.1
JBoss EAP 6.2
WildFly AS 8 CR 1
The right solution depends on your situation:
The simplest solution with the least risk is to stay with JBoss AS 5.1.0 and fix JBAS-6981 yourself. We did that and ran with it for over a year and it worked fine. Note however that JBoss AS 5.1.0 is end of life, eg. there aren't any security patches available.
If you don't want to fix JBAS-6981 yourself you can go with JBoss AS 6.1.0. This should be quite a simple migration because it builds on the same architecture and has the same disk layout. Note however that it is Java EE 6 which means among other things standardized JNDI names. Depending on your application this can have quite a bit impact — or none at all. Note however that JBoss AS 6.1.0 is end of life, eg. there aren't any security patches available.
The next "stable" community version is JBoss AS 7.1.1 with brings a whole new architecture. Depending on your application that can be quite a large migration — or a really simple one. However I would recommend against JBoss AS 7.1.1 as it's buggy as hell. Note there won't be any future releases for JBoss AS 7.1.1 as well.
JBoss EAP 6.2 builds on JBoss AS 7.1.1 (AS 7.3 actually) and contains many bug fixes (and some features). You either need to build it from source or get a license from Red Hat. There will be patches for EAP 6.2.
The current in development community version is WildFly AS 8 CR1. As you can see from the version name there isn't a stable release yet. And it contains a whole new servlet engine, which makes a whole lot of people nervous. I would only use it if you have really good integration tests.
I don't know what the situation regarding Seam is for any of them.
Note that sooner or later you'll have to migrate to a newer version of JBoss AS anyway. To judge how hard the migration will be you first need to know what dependencies on JBoss AS you have in your code.
I am new to JBoss application server. when I go for download the application server in the website. I am seeing the below servers list in the top
EAP built from AS 7.3.
EAP 6.2 Maven Repository.
EAP 6.2 Quickstarts.
kindly help me. Which is the best one. otherwise, shall I go for any other open source application server.
Thanks
I don't want to make any comment about these things you mentioned. But I can share my experience with you.
Jboss 5.1: It was good.
Jboss 7.1: I faced a problem with log4j issue. Its very complicated.
EAP 6.2: Its much stable than 7.1. my log4j problem is solved with this version.
So, it totally depends upon how deep you want to use jboss.
I am currently developing an application which has a server part based on JavaEE 6.0 on JBoss 7.1 and a client based on Eclipse RCP 3.7.
For a simple OSGi package for a shared API I already run into trouble due to some differences in versions and depdencenies. The API requires "org.osgi.framework." for the bundle activator and "org.slf4j." for the slf4j logging API.
Currently my client is working very well, but JBoss tells me that the expected version of the OSGi import and the also the imports for slf4j do not fit...
I there a best practice to share OSGi bundles between Eclipse and JBoss? Do I need to get back to simple import and export declarations or can I used Require-Bundle somehow? Do I need to create some compatibility bundles for JBoss to get it running? What is the best way to proceed here?
UPDATE
I solved the issue by using Import-Package exclusively. For the dependency like org.osgi.framework is use version="0.0" to explain it does not matter. :-( It is not very safe, but currently I do not see another option. Is there a better way?
UPDATE 2
One also needs to pay attention to implement the correct verion of the OSGi Framework. JBoss 7.1.x only has OSGi 4.2 implemented, which has no support for typesafe service retrieval.
The best practice would be to use an import package statement with a range from the minimum version which you're using to the next major increment.
For example, if RCP expects version 1.5 of a package and JBoss expects 1.3.6, import version="[1.3.6,2)".
The Semantic Versioning whitepaper (pdf) explains why this style of import is safe and wise.
I just started learning portlet and got stuck in the first place. I have installed JavaEE 6 SDK, Eclipse Helios and GlassFish Server 3.0.1. I also successfully configured OpenPortal Portlet Container (OPC) for GlassFish by running command:
java -jar portlet-container-configurator.jar
The problem come up when I wanted to create a new server runtime environment of OPC, there was no "OpenPortal Portlet Container 2.x" node like the tutorial said. I googled and found that I needed to install Eclipse Portal Pack but the link was dead.
Any suggestion, please?
Best Regard.
If you want to develop portlets, I strongly recommend downloading Apache Pluto instead of using the open portlet container; you can download a version of Tomcat bundled with Pluto from their site: http://portals.apache.org/pluto
Actually, Pluto has a few quirks that you need to get past (for example, it wants you to run an 'assembly' step to add some entries to your web.xml) but once you do it is probably the best way. You could also try Liferay or JBoss' GateIn for development, but if you are ultimately targeting a vendor supplied platform like WebSphere, you might find that these actually have features that aren't as portable, whereas Pluto is really just a simple implementation of the portlet spec.
I have found the .jar file on Internet. Thanks for watching.