PropertyFileConfiguration loaded twice for WAR Projekt that contains EJBs

Hello, We have a project with the following setup: EAR è EJB o Has access to the Utility-JAR è Utility-JAR o PropertyConfigSource named PasConfiguration.class è WAR o Has access to the Utility-JAR and the EJB All modules are CDI-enabled. When the application starts, it first starts

WebSphere: Error in deltaspike-jsf-module while stopping application under WAS 8.0.0.9

Hello, I've come across an issue when stopping an application that uses the deltaspike-jsf-module (ee6) (current SNAPSHOT of 1.1-Release). The JsfSystemEventBroadcaster tries to retrieve the BeanManager and can't do so, as an IllegalStateException is thrown. Can you elaborate whether you know

AW: WebSphere: Error in deltaspike-jsf-module while stopping application under WAS 8.0.0.9

Hey Mark, Our real project had a EJB project as well. I stripped down the problem to a single WAR inside an EAR. I used your was_bugs-project on github and created a sample to demonstrate the bug. A PMR has been opened: IllegalStateException when accessing BeanManager in JSF

Cross-Site Scripting (XSS) attack possible by manipulating the dswid request parameter, when using ds:windowId/

Hello, we've come across an issue in version 1.0.4 of the Deltaspike JSF module. In case one manipulates the dswid-Parameter generated by DeltaSpike in the following way: http://host/pages/mypage.xhtml?dswid=7479%3C/script%3E%3Cscript%3Ealert%281%29%3C/script%3E and the underlying page

0.7/0.8-SNAPSHOT - Error under WAS 8 - NullPointerException at Application Start in ViewConfigResolverProducer.createViewConfigResolver

Hello, we've come across an issue with Version 0.7 and even 0.8-SNAPSHOT under WebSphere 8 in the JSF module. When the application is started the following stack trace occurs. I've debugged into this a bit more. The SPI extension ViewConfigExtension is present and exists and the observers are

AW: 0.7/0.8-SNAPSHOT - Error under WAS 8 - NullPointerException at Application Start in ViewConfigResolverProducer.createViewConfigResolver

Hello Mark, thank you for pointing this out. This version mess in WebSphere drives me crazy. Unfortunately the development happens using liberty because its much more convinient. The integration test happens under WAS 8.0.0.8 cause it's the productive environment. I guess we have to go back

AW: 0.7/0.8-SNAPSHOT - Error under WAS 8 - NullPointerException at Application Start in ViewConfigResolverProducer.createViewConfigResolver

Hello Gerhard, thank you for your fast response. I did so and it worked, however this problem seems to occur in almost ALL AppicationScoped classes. I've come across two new ones after that: @ApplicationScoped public class WindowContextProducer { @Inject private

AW: Revisit cdiCtrl module name and how it's inconsistent with test-control?

Seems this way. I think this whole dicussion is becoming ridicuolus. Change it to comply with the rest. I personally never understood why this very lonely 'module' cdiCtrl is located elsewhere, regardless on whether it has different dependencies or not. Additionally it does not fit into the

AW: Interceptors not being called in JUnit-aware CDI environment

Hey Romain, that was the missing piece of the puzzle and lets me step down in embarrassment for such an idiotic mistake. I've had the assumtion that for a maven surefire test, the beans.xml provided in src/main/resources/META-INF which IS obviously used, is enough, but after you pointed this

AW: AW: Interceptors not being called in JUnit-aware CDI environment

Hello Mark, thank you for your input. Your idea would have been much easier than what I did :-) When you write a Junit Runner, you have the ability to control the test class creation by overwriting createTest() and returning your instance. By default this is simply the newInstance() call for

Interceptors not being called in JUnit-aware CDI environment

Hello, I've been trying to start the CDI container during Junit-Testing as described at the following page, http://struberg.wordpress.com/2012/03/27/unit-testing-strategies-for-cdi-based-projects/ though I'm using Junit 4 and implemented everything using a new Runner (to annotate tests with