Java-8 Support for various appserver versions
by Rob Stryker
Can anyone tell me the following:
1) What server versions will work with Java 8
2) What server versions will **require** Java 8 to work properly?
Feel free to answer with all varients of our products... so anything
from AS 4 through wf8.x, eap*, soa*, etc etc.
Thanks in advance.
10 years
issues with modules name differences in wildfly vs jboss eap (mvn scope and duplicate jar files)
by hanasaki＠gmail.com
wildfly modules
* include some open source non-JBoss modules
* named the same as in Internet maven repositories
JBoss eap commercial product modules AND maven eap repo zip download
* include the same modules as wildfly
* named differently : suffixed with ex: "-redhat-3"
* some might have been named ".redhat-3"
1. Should my projects use the internet version of the open source libs
that are provided as JBoss modules or the JBoss modules by name?
2. If using the jboss modules by name (and jboss specific version
number) they I assume the maven pom.xml would depend on them as
<scope>provided</scope>
instead of
<scope>compile</scope>
???
3. If using the modules from jboss/wildfly as "provided"
- how to build one WAR/EAR that deploys on wildfly and eap?
4. if depending on a jboss "-redhat-3" version, this will depend on the
other app server provided modules. There is an issue if the project
uses X and A below.
X-1.2.3-redhat-_ depends on Y-..-redhat-_ from the repo zip
which is OK
A-5.6.7 depends on Y all not from the mvn repo zip
which is OK
project depends on X (in repo zip) and A (not in repo zip)
NOT OK - project gets Y (internet) and Y (from repo zip)
based on maven build
10 years
Exclusions in WildFly
by Juan Manuel CABRERA
Hello devs,
I have a wildfly war application at hands, which depends on a jar which
starts its own JPA persistence container with Spring. This jar has its own
`persistence.xml`, with only one persistence unit.
In the embedded jar, since there is only one persistence unit, it is
injected using a `@PersistenceContext` without a unit name. Furthermore,
the objects having such fields are not EJBs, they are simple Spring beans...
On the other hand, the application has also a `persistence.xml` with two
persistence units.
The code of the application has `@PersistenceContext` fields with a proper
`unitName`, which is mandatory since there are two of them.
Now, when I start my application, Wildfly (specifically the jpa module)
scans the code from the jar and chokes on the `@PersistenceContext` without
unitNames of my Spring beans:
DEBUG [org.jboss.as.jpa.messages] (MSC service thread 1-1) persistence
unit search for unitName=null referenced from class=the.spring.Bean
(annotation=(a)javax.persistence.PersistenceContext() on void
the.spring.Bean.setEntityManager(javax.persistence.EntityManager))
To cope with this, I would like to exclude the jar: In TomEE there is a
mean to exclude a jar explicitly from being scanned, but I cannot find a
similar functionnality in WildFly.
I have tried the following configurations without success:
- `jboss-deployment-structure.xml` which is read but without noticeable
effect:
<jboss-deployment-structure
xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<exclusions>
<module name="deployment.jee-app.war.spring-app.jar" />
<!-- I have also tried the following -->
<!-- <module name="jee-app.war.spring-app.jar" /> -->
<!-- <module name="spring-app.jar" /> -->
</exclusions>
</deployment>
</jboss-deployment-structure>
- `jboss-scanning.xml` which seems to be ignored
<scanning xmlns="urn:jboss:scanning:1.0">
<path name="jee-app.war/WEB-INF/lib">
<exclude name="spring-app.jar" />
</path>
</scanning>
Both of these files are in the WEB-INF folder of my war application.
Of course, I cannot modify the spring-app.jar (would be too easy...)
Needless to say, I have spend a considerable amount of time in the WildFly
doc and on Google without finding anything else than exluding subsystems,
or overriding locally modules of WildFly...
Thanks for your help!
Juan Manuel
PS: This question is also posted on StackOverflow:
http://stackoverflow.com/q/22932015/3509723
10 years
8.1.0.CR1 Released, Replaces 8.0.1
by Jason Greene
Hello Everyone,
After an IRC discussion, we decided that since 8.0.1 had included some small features to address a few usability problems, that it was more appropriate to label it as a minor release. Our standard process for all feature releases is to release at least one CR to catch any unexpected problems. If you could please give it a try, and raise the flag if you notice a problem.
Provided no blockers are uncovered, we will promote the CR to Final status.
As always you can download the release here:
http://wildfly.org/downloads/
The release notes are available here:
https://community.jboss.org/wiki/WildFly810CR1ReleaseNotes
Thanks, and sorry for any confusion this may have caused.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
10 years
Re: [wildfly-dev] Failed to persist sessions: java.io.NotSerializableException at undeploy time
by Tomaž Cerar
That should not be there, it is not stable enough yet!
For same reason we removed it from default shipped configs before
8.0.0.Final.
In any case it is just warn and should not effect application deployed
beyond redundant logs.
--
Tomaz From: Scott Marlow
Sent: 12.4.2014 21:17
To: Jason Greene
Cc: wildfly-dev(a)lists.jboss.org
Subject: Re: [wildfly-dev] Failed to persist sessions:
java.io.NotSerializableException at undeploy time
http://pastie.org/9075691 shows what we are using and that we do have
"<persistent-sessions path="persistent-web-sessions"
relative-to="jboss.server.data.dir"/>"
On 04/12/2014 03:15 PM, Jason Greene wrote:
> It looks like it does:
>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
>
> We should pull that out. It’s a development feature, and it’s reliant on everything that is put in the session is serializable which is not strictly required. It’s odd though why it would intermittently fail. It should be deterministic.
>
> On Apr 12, 2014, at 2:11 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
>
>> Does the TCK config have this in it, under the undertow servlet section?:
>>
>> <persistent-sessions/>
>>
>>
>> On Apr 12, 2014, at 2:06 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
>>
>>> I'm running some tests with WildFly 8.0.1 master branch and seeing an
>>> intermittent failure. Any ideas why http://pastie.org/9075646 might be
>>> occurring? I see a number of these errors during an EJB test. It is
>>> possible that this error is expected, I'm not sure.
>>>
>>> Scott
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10 years, 1 month
Release date of 8.0.1 final
by Marek Żupnik
Hi all,
I would like kindly ask if there is any estimation when 8.0.1.Final version
will be released?
Regards,
Marek
10 years, 1 month
regression caused by "WFLY-3175 Create non-clustered implementations of org.wildfly.clustering.api services" change
by Scott Marlow
I'm running with an older WildFly configuration (EE TCK) that probably
doesn't have the needed changes for the
"jboss.clustering.registry.ejb.default" service. Rather than just
syncing up with the WFLY-3175 changes, I would like to know if the
dependencies on "jboss.clustering.registry.ejb.default" should be
optional so that people with older WildFly configurations do not get
service dependency errors on "jboss.clustering.registry.ejb.default"?
Scott
10 years, 1 month
