September 2014 - wildfly-dev - Jboss List Archives

Early Access builds for JDK 9 b31 and JDK 8u40 b06 are available on java.net

by Rory O'Donnell Oracle, Dublin Ireland

Hi Guys, Early Access build for JDK 9 b31 <https://jdk9.java.net/download/> is available on java.net, summary of changes are listed here <http://www.java.net/download/jdk9/changes/jdk9-b31.html> Early Access build for JDK 8u40 b06 <http://jdk8.java.net/download.html> is available on java.net, summary of changes are listed here. <http://www.java.net/download/jdk8u40/changes/jdk8u40-b06.html> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

10 years, 9 months

1
0
0 / 0

Cassandra Subsystem

by Heiko Braun

FYI I started integrating Apache Cassandra [1] into Wildfly. It's a prerequisite for integrating rhq-metrics [2] with Wildfly, but I guess it has a lot of value on it's own. The integration is done as a subsystem, which can be used to run a a single C* node on a standalone box, but more importantly it allows for launching and managing a complete C* cluster as part of Wildfly managed domain. I've provided example configuration files for both options which can be used to play around with it and get going. The current subsystem relies on a patched Cassandra 2.0.6 version. Cassandra isn't designed to be used an embedded library. In particular the CassandraDaemon and some of the core services make heavy use 'System.exit()' calls. In order to embed Cassandra as a managed service, we had to remove some of the code that would otherwise break the service contracts in Wildfly. But I am confident we can find a way to get these changes back into the upstream project. But I haven't discussed all the details with the Apache folks yet. Overall it's pretty much work in progress, but I think it's good enough to get your hands dirty. You can find the codebase in my github repository: https://github.com/heiko-braun/wildfly-cassandra Thoughts and comments are welcome. /Heiko [1] http://cassandra.apache.org/ [2] https://github.com/rhq-project/rhq-metrics

10 years, 9 months

5
11
0 / 0

Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs

by Rebecca Searls

I filed https://issues.apache.org/jira/browse/CXF-6008 requesting the CXF team responding to this information. ----- Original Message ----- > From: "Balchandra Vaidya" <balchandra.vaidya(a)oracle.com> > To: "Rebecca Searls" <rsearls(a)redhat.com>, "rory odonnell" <rory.odonnell(a)oracle.com> > Cc: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>, "Norman Maurer" <norman.maurer(a)googlemail.com>, > wildfly-dev(a)lists.jboss.org, "Dalibor Topic" <dalibor.topic(a)oracle.com> > Sent: Wednesday, September 17, 2014 6:33:12 AM > Subject: Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs > > > Hi Rebecca, > > Thank you for the report. Both sun.misc.Unsafe and > org.relaxng.datatype.Datatype > are JDK-internal APIs that have no supported replacements. If you are > unable to > migrate away, please provide us with an explanation. > > Thank you for your efforts and feedback helping us make JDK 9 better. > > > Regards, > Balchandra > > > On 16/09/2014 18:59, Rebecca Searls wrote: > > I ran jdeps on apache CXF ( http://git-wip-us.apache.org/repos/asf/cxf.git, > > branch 3.0.x-fixes) > > and got the following results. > > > > --- > > digraph "ehcache-2.8.1.jar" { > > // Path: > > ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/ehcache-2.8.1.jar > > "net.sf.ehcache.pool.sizeof.UnsafeSizeOf" -> "sun.misc.Unsafe > > (JDK internal API (rt.jar))"; > > } > > > > --- > > digraph "woodstox-core-asl-4.3.0.jar" { > > // Path: > > ./services/sts/sts-war/target/SecurityTokenService/WEB-INF/lib/woodstox-core-asl-4.3.0.jar > > "com.ctc.wstx.msv.GenericMsvValidator" -> > > "org.relaxng.datatype.Datatype (JDK internal API (tools > > .jar))"; > > } > > > > > > > > ----- Original Message ----- > >> From: "Rory O'Donnell Oracle, Dublin Ireland" <rory.odonnell(a)oracle.com> > >> To: "Rebecca Searls" <rsearls(a)redhat.com> > >> Cc: "Tomaž Cerar" <tomaz.cerar(a)gmail.com>, "Norman Maurer" > >> <norman.maurer(a)googlemail.com>, "Balchandra Vaidya" > >> <Balchandra.Vaidya(a)oracle.com>, wildfly-dev(a)lists.jboss.org, "Dalibor > >> Topic" <dalibor.topic(a)oracle.com> > >> Sent: Tuesday, September 16, 2014 12:08:20 PM > >> Subject: Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on > >> JDK-Internal APIs > >> > >> Hi Rebecca, > >> > >> Not yet, we have a long list of FOSS Projects which we are targeting and I > >> can't say when we will get to it. In the mean time the tool is available > >> here: > >> > >> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > >> > >> Feel free to run it yourself and post results. > >> > >> Rgds,Rory > >> > >> > >> On 16/09/2014 16:08, Rebecca Searls wrote: > >>> Has Oracle run the tool on apache's CXF project? > >>> > >>> ----- Original Message ----- > >>>> From: "Rory O'Donnell Oracle, Dublin Ireland" <rory.odonnell(a)oracle.com> > >>>> To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com> > >>>> Cc: "Norman Maurer" <norman.maurer(a)googlemail.com>, "Balchandra Vaidya" > >>>> <Balchandra.Vaidya(a)oracle.com>, > >>>> wildfly-dev(a)lists.jboss.org, "Dalibor Topic" <dalibor.topic(a)oracle.com> > >>>> Sent: Thursday, September 11, 2014 10:33:44 AM > >>>> Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on > >>>> JDK-Internal APIs > >>>> > >>>> Hi Tomaz, > >>>> > >>>> As part of the preparations for JDK 9, Oracle’s engineers have been > >>>> analyzing open source projects like yours to understand usage. > >>>> One area of concern involves identifying compatibility problems, such as > >>>> reliance on JDK-internal APIs. > >>>> > >>>> Our engineers have already prepared guidance on migrating some of the > >>>> more common usage patterns of JDK-internal APIs to supported public > >>>> interfaces. The list is on the OpenJDK wiki [0], along with instructions > >>>> on how to run the jdeps analysis tool yourself . > >>>> > >>>> As part of the ongoing development of JDK 9, I would like to encourage > >>>> migration from JDK-internal APIs towards the supported Java APIs. I have > >>>> prepared a report for your project wildfly-8.1.0 release based on the > >>>> jdeps output. > >>>> > >>>> The report is attached to this e-mail. > >>>> > >>>> For anything where your migration path is unclear, I would appreciate > >>>> comments on the JDK-internal API usage patterns in the attached jdeps > >>>> report, (if any) - in particular comments elaborating on the rationale > >>>> for them - either to me or on this list. > >>>> > >>>> Finding suitable replacements for unsupported interfaces is not always > >>>> straightforward, which is why I am reaching out to you early in the JDK > >>>> 9 development cycle so you can give feedback about new APIs that may be > >>>> needed to facilitate this exercise. > >>>> > >>>> Thank you in advance for any efforts and feedback helping us make JDK 9 > >>>> better. > >>>> > >>>> Rgds,Rory > >>>> > >>>> [0] > >>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > >>>> > >>>> -- > >>>> Rgds,Rory O'Donnell > >>>> Quality Engineering Manager > >>>> Oracle EMEA , Dublin, Ireland > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> wildfly-dev mailing list > >>>> wildfly-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> -- > >> Rgds,Rory O'Donnell > >> Quality Engineering Manager > >> Oracle EMEA , Dublin, Ireland > >> > >> > >> > >> > >> > >

10 years, 10 months

1
0
0 / 0

Creating config files for provisioned servers

by Stuart Douglas

Hi All, so I have been giving a bit of thought to how our configuration files are generated, and how it can work with feature packs. At the moment feature packs just package files with a subsystem list inside, and later feature packs configs override configs from their dependents. I think we should move to an approach where feature packs build on the config provided by other feature packs. So the web feature pack config will basically express 'add these additional subsystems to standalone.xml'. Additional config files can also be created based of existing config, so for example standalone-full.xml would be represented as 'like standalone.xml, but with these additional subsystems'. Domain mode would work in a similar manner, but with profiles instead of config files (so everything I am saying here about standalone.xml will also apply to domain mode). There are quite a few advantages to this approach: - As most (all?) configs will use standalone.xml as a base, it makes it simple to keep multiple config files in place - It is easy for a feature pack to add a subsystem to all configurations (e.g. installing the KeyCloak feature pack could add KeyCloak to all configs). - It is easy to create a new configuration that is the same as existing configs, but with an additional subsystem. Does this sound reasonable? Stuart

10 years, 10 months

7
6
0 / 0

Fwd: Question on wildfly schema

by Rob Stryker

Hey All: All the wildfly schema are added online here: http://www.jboss.org/schema/jbossas/ A user is indicating some of the schema cause bugs in our tools: https://issues.jboss.org/browse/WFLY-3189 They have made a PR to make changes to some of the schema in our tools. However, we typically clone the online folder for our schema and distribute them with our tools, so it'd be very good to know if these changes can also be made to the online versions so that we don't end up forking the schema. So if any of you can either direct me to who would know the answer, or, review the changes to the schema yourself to see if they make sense, that'd be really helpful. Ideally I'd prefer these changes to be made to the online schema so that our jbt-distributed schema match the onlines. PR: https://github.com/jbosstools/jbosstools-server/pull/268/files - Rob Stryker

10 years, 10 months

2
2
0 / 0

Creating a Keycloak Feature Pack

by Stan Silvert

Perhaps it's a little early to start implementing a Keycloak FP, but I'm starting to look at it and identify potential issues. So I thought I should list the issues here and find out which ones are already addressed and which need some time to work out. *Task:* Implement a feature pack that adds the Keycloak Auth Server to either/both of the _WildFly Web build_ and the _WildFly Full build_. Note that this is completely separate from the effort to use Keycloak to secure the web console. That only involves Keycloak adapter integration destined to ride on top of Elytron. Here, we are talking about using a feature pack to add and configure the Keycloak Auth Server. *Issue #1: Module duplication.* Keycloak needs to install the bouncycastle module. This module already exists in the full build but not the web build. So you have the same module specified for the Keycloak FP and the Full WildFly FP. I assume this is already handled? Will the FP mechanism have a problem with duplication of modules when I try to add a module to full that already exists? *Issue #2: Adding a subsystem:* It looks like the current mechanism for creating configuration files is inappropriate for the Keycloak FP. The way this is done right now is that a config file is generated via the combination of a template file and a list of subsystem snippets. So you would have, for example: template-keycloak.xml + subsystems-keycloak.xml = standalone-keycloak.xml But that's not what we really want. We don't want a separate standalone-keycloak.xml. We really just want to add the keycloak subssytem to every generated config file, whatever they may be. *Issue #3: Adding a deployment:* The Keycloak auth server is deployed as a WAR. We can use the copy-artifacts mechanism to simply copy the WAR into the deployments directory. But that doesn't work for a domain where you want to have the WAR pre-loaded into the content repository. Furthermore, it's probably not the best way to integrate this for standalone either. What would be a better option?

10 years, 10 months

4
9
0 / 0

Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs

by Rory O'Donnell Oracle, Dublin Ireland

Hi Tomaz, As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0], along with instructions on how to run the jdeps analysis tool yourself . As part of the ongoing development of JDK 9, I would like to encourage migration from JDK-internal APIs towards the supported Java APIs. I have prepared a report for your project wildfly-8.1.0 release based on the jdeps output. The report is attached to this e-mail. For anything where your migration path is unclear, I would appreciate comments on the JDK-internal API usage patterns in the attached jdeps report, (if any) - in particular comments elaborating on the rationale for them - either to me or on this list. Finding suitable replacements for unsupported interfaces is not always straightforward, which is why I am reaching out to you early in the JDK 9 development cycle so you can give feedback about new APIs that may be needed to facilitate this exercise. Thank you in advance for any efforts and feedback helping us make JDK 9 better. Rgds,Rory [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

10 years, 10 months

6
9
0 / 0

8.2 is next

by Jason T. Greene

Hi Everyone, We just got the TCK update with CDI 1.2 and Scott is the process of setting it up. As soon as that's done and we get good results I would like to cut the release. So the window for critical patches is pretty small. So if you have them and you are confident they will not introduce TCK regressions, feel free to propose. The branch already has many fixes and, of course, CDI 1.2. Finally only "Final" component updates will be accepted. Our goal is to release as quickly as possible and move on to 9 beta. Thanks! -Jason

10 years, 10 months

1
0
0 / 0

9.0.0.Alpha1 Released

by Jason Greene

Hello Everyone, I just pushed Alpha1, which was a bit delayed due to testsuite issues that cropped up at the last minute: wildfly.org/downloads/ The biggest changes are: - Built off our new feature provisioning tool which is layered on the now separate core distribution - New servlet distribution based on above (we are calling it web lite until we can come up with a better name): https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/w... - Architecture now supports server suspend mode (graceful shutdown) + Although only Undertow + EJB3 use this so far, additional subsystems need to be updated - Notification support in the management APIs Overall 256 fixes and improvements were included in this release: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&versi... Enjoy! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

10 years, 10 months

3
2
0 / 0

performance issue with wildfly and hibernate validator

by Andrew Schmidt

I've been investigating performance issues with wildfly and hibernate validator. The changes made for this https://issues.jboss.org/browse/AS7-1306 imply the follow from the jpa spec: The results of calling the PersistenceProviderResolverHolder.getPersistenceProviderResolver and the PersistenceProviderResolver.getPersistenceProviders methods must not be cached. however, the spec says later on: Note that the PersistenceProviderResolver.getPersistenceProviders() method can potentially be called many times. It is therefore recommended that the implementation of this method make use of caching. My interpretation is that wildfly should be caching the providers and it's the responsibility of the callers to not cache the results. So the issue AS7-1306 shouldn't have been implemented. The performance penalty of wildfly not caching the implementation of that method in regards to hibernate is that HibernatePersistenceProvider uses a cache for classes/methods/fields and that cache is blown away on every call to getPersistenceProviders and that happens on every validation of every member of every class.

10 years, 10 months

5
10
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev September 2014