August 2015 - wildfly-dev - Jboss List Archives

by Arun Gupta

In case you are interested ... Kubernetes workspace now has a sample [1] that shows how to deploy Java EE application using WildFly to Kubernetes cluster. [1] https://github.com/kubernetes/kubernetes/tree/master/examples/javaee Have a good weekend! Arun -- http://blog.arungupta.me http://twitter.com/arungupta

8 years, 11 months

1
0
0 / 0

Undertow redirection issues - WildFly 8.2.0

by Nidheesh Ep

Hi team, Our old customer portal was migrated to WildFly-8.2.0 from JBoss 4. We had an integration with Drupal. The ROOT.war was deployed successfully. But while accessing to the webpage(/home), the page is running into a redirect loop. Error trace: Exception handling request to /home/index.php?q=: com.caucho.quercus.QuercusModuleException: java.io.IOException: An established connection was aborted by the software in your host machine Posted this issue in the community at: https://developer.jboss.org/thread/261266?sr=inbox In stackoverflow: http://stackoverflow.com/questions/31421347/application-runs-into-a-redir... Cheers, Nidheesh

8 years, 11 months

1
0
0 / 0

stream parallel

by Dennis Gesker

Hello List: Just looking for a best practice recommendation on new functional capabilities when WildFly is running atop Java 8. My understanding is that when you wish to do a concurrent operation one is best served using the functionality built into the EE container rather than the JVM directly. This view may be incorrect or outdated. Does it still hold true? Should stream parallel be avoided for the time being in Java EE applications? Should one expect that at some point there will be an EE level set of classes for stream parallel? Perhaps something like "ManagedStream" -- sort of like the current ManagedExecutorService for Callables/Runnables provided by the container -- in the future? BTW, I tried posting the above on jboss-user a few days ago but didn't get a bite. Has a wildfly-user been created to replace jboss-user? Thanks Dennis -- <https://www.linkedin.com/in/gesker>[image: https://www.facebook.com/gesker] <https://www.facebook.com/gesker>[image: https://twitter.com/gesker] <https://twitter.com/gesker>[image: http://gesker.wordpress.com] <http://gesker.wordpress.com>[image: http://www.gesker.com] <http://www.gesker.com> <https://pgp.mit.edu/pks/lookup?search=dennis%40gesker.com&op=index> <dennis(a)gesker.com> "Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong – that is your oath.” -The Knight’s Oath (Kingdom of Heaven)

8 years, 11 months

1
0
0 / 0

Validating operation parameters

by Emmanuel Hugonnet

Hi, I'm currently working on adding more metadata on resource attributes and operation parameters or replies [1]. As an example I added the fact that an attribute of type STRING is in fact a filesystem path or an URL [2]. To show how this kind of metadata could be helpful I have updated the CLI so that it uses the filesystem path completer and to try to validate the operation parameters : for example checking that an URL has a correct format before executing an operation. This led me to provide more validation : checking that an integer is in the valid range, etc. Brian rightfully pointed out that in some case we are defining than an operation parameter is defined a certain type while the handler supports multiple types : for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object but supports getting the object directly. So I'm wondering about adding support for range or type validation for 'complex' types as it may break existing valid (as in accepted even if wrong) operations. What do you think ? Do you see other edge cases like this one ? Emmanuel 1: https://issues.jboss.org/browse/WFCORE-74 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74

8 years, 11 months

2
2
0 / 0

Using a custom module to preview "next-gen" Hibernate versions on WildFly 9

by Sanne Grinovero

Hi all, I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 to use a preview of Hibernate ORM version 5. It seems the JPA deployer isn't allowing me to run such experiments: # First experiment - providerModule set to custom module In my first attempt, I create a custom set of jboss modules which include the snapshot builds of ORM 5, add them to my standalone WF9 instance and set the persistence.xml property: jboss.as.jpa.providerModule = my-custom-module-name and then get: Caused by: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.boot.internal.EnversIntegrator not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) [rt.jar:1.7.0_51] at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) ... 7 more Clearly it looks like I'm being served classes from the bundled Hibernate 4.x implementation - on top of those from the module I'm requesting. This isn't what the deployer should be doing, right? # Second experiment - use the "application provided" In this case I hope to hint the JPA deployer to not add the default implementor but look for a JPA implementation within my deployment, but still package my custom Hibernate build as a module. - use the same custom module containing Hibernate ORM 5 (a preview snapshot) - Add a "Dependency:" section to the manifest to import (and export) my custom module - set the "jboss.as.jpa.providerModule" property to value "application" This gets me: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYJPA0027: Persistence provider module load error application (class org.hibernate.jpa.HibernatePersistenceProvider) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] ... 5 more Caused by: org.jboss.modules.ModuleNotFoundException: application:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) [jboss-modules.jar:1.4.3.Final] at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) ... 10 more Remarks: - it's attempting to load the "application:main" module?! that's not what I'd expect from reading [1] - the provider should be available to the deployment classpath, so I'm not sure why it's not finding the Provider? (I'm even exporting it, although I'm not sure if that was required). Any suggestions to get this running please? Also I wonder if some of these should warrant opening a JIRA, but I'm not sure how far I misunderstood the intentions of these JPA deployer properties. Thanks, Sanne [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere...

8 years, 11 months

7
33
0 / 0

WildFly 10.0.0.Beta1 is now on OpenShift

by Farah Juma

See https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/... to get started.

8 years, 11 months

1
0
0 / 0

sun.misc.Unsafe usage, etc.

by Scott Stark

In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement.

8 years, 11 months

5
8
0 / 0

AUTO: Andreas Kalk ist außer Haus (returning 24.08.2015) [Virus checked]

by Andreas.Kalk＠nordsee.com

Ich kehre zurück am 24.08.2015. Ich werde ab 03.08.2015 nicht im Büro sein. Ich kehre zurück am 24.08.2015. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. In dringenden Fällen wenden Sie sich bitte an den Support (1377) Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "wildfly-dev Digest, Vol 29, Issue 1 [Virus checked]" gesendet am 06.08.2015 21:05:47. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, während diese Person abwesend ist. Jetzt NEU: Unser Räucherlachs-Walnussbrot. Das dürfen Sie sich nicht entgehen lassen! -- P Denken Sie bitte an die Umwelt - bevor Sie ausdrucken! NORDSEE Holding GmbH * Klußmannstraße 3 * 27570 Bremerhaven Registergericht Bremen * Reg.-Nr. HRB 3579 Geschäftsführer: Hiltrud Seggewiß (Vors.) * Robert Jung * Claus Schlüter Aufsichtsratsvorsitzender: Heiner Kamps

8 years, 11 months

1
0
0 / 0

Capabilities enabled by attributes

by Brian Stansberry

I would like to propose a requirement that if a particular type of resource CAN provide a capability, then it MUST provide that capability if it is created. There will be no such thing as a resource providing or not providing a capability based on the value of one of its attributes. My question to subsystem developers is whether they have a situation in their configuration model where this will be a problem? For any case where there is such an attribute, the requirement would mean that a child resource would need to be created instead, and that child resource would provide the capability. There are tricks we can use to preserve the existing attribute to provide management API compatibility. The only case I'm aware of where this is a factor is the 'jts' attribute in the subsystem=transactions resource. The reason for this requirement is we want tooling to be able to inspect the types of resources that are available for use, see what capabilities they provide and what requirements they have, and work out what resources need to be present in a configuration in order to have a consistent set of capabilities. That task is significantly more complex if the presence of a capability is determined by some arbitrary attribute value. David Lloyd described allowing attributes to control this as being "like creating an RDBMS where you have foreign keys that only exist if some function evaluates in a certain way." -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

8 years, 11 months

2
2
0 / 0

Early Access builds for JDK 8u60 b26 and JDK 9 b75 are available on java.net

by Rory O'Donnell

Hi Jason/Tomaz, Early Access build for JDK 8u60 b26 <http://jdk8.java.net/download.html> is available on java.net, summary of changes are listed here. <http://download.java.net/jdk8u60/changes/jdk8u60-b26.html?q=download/jdk8...> As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b75 <https://jdk9.java.net/download/> is available on java.net, summary of changes are listed here <http://download.java.net/jdk9/changes/jdk9-b75.html?q=download/jdk9/chang...>. With respect to ongoing JDK 9 development, there are two new Candidate JEPs I'd like to draw your attention to. Firstly, Mark Reinhold has put forward JEP 260: Encapsulate Most Internal APIs to make most of the JDK's internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality. You can find the JEP here: http://openjdk.java.net/jeps/260 - and an introductory e-mail and discussion thread on the OpenJDK jigsaw-dev mailing list, starting at http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html . If you would like to provide additional feedback, please join the jigsaw-dev mailing list, and contribute to the discussion there. Secondly, Mandy Chung has put forward JEP 259: Stack-Walking API to define an efficient standard API for stack walking that allows easy filtering of, and lazy access to, the information in stack traces. You can find the JEP here: http://openjdk.java.net/jeps/259 . If you would like to provide feedback on JEP 259, please join the OpenJDK core-libs-dev mailing list and contribute to the discussion there. Finally, we are looking for feedback via a survey on Java Style Guidelines Please see here for more details. http://mail.openjdk.java.net/pipermail/discuss/2015-August/003766.html Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev August 2015