March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8407) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8407?page=com.atlassian.jira.plugin.... ] Darran Lofthouse moved ELY-1015 to WFLY-8407: --------------------------------------------- Project: WildFly (was: WildFly Elytron) Key: WFLY-8407 (was: ELY-1015) > AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-8407 > URL: https://issues.jboss.org/browse/WFLY-8407 > Project: WildFly > Issue Type: Bug > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration > but it is not wired to actual client configuration. > As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8407) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8407?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-8407: ----------------------------------- Component/s: EJB > AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-8407 > URL: https://issues.jboss.org/browse/WFLY-8407 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Tomaz Cerar > Assignee: Darran Lofthouse > > jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration > but it is not wired to actual client configuration. > As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1015) AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties

by Tomaz Cerar (JIRA)

Tomaz Cerar created ELY-1015: -------------------------------- Summary: AuthenticationContext is not properly propagated in ejb client when using jboss-ejb-client.properties Key: ELY-1015 URL: https://issues.jboss.org/browse/ELY-1015 Project: WildFly Elytron Issue Type: Bug Reporter: Tomaz Cerar Assignee: Darran Lofthouse jboss-ejb-client has ElytronLegacyConfiguration is a service that implements LegacyConfiguration but it is not wired to actual client configuration. As result client auth fails in most quickstarts see JBEAP-9263 JBEAP-7279 for examples. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-995) Exploded EAR deployment error - java.util.zip.ZipException: error in opening zip file

by Pierfrancesco Girolami (JIRA)

[ https://issues.jboss.org/browse/AS7-995?page=com.atlassian.jira.plugin.sy... ] Pierfrancesco Girolami commented on AS7-995: -------------------------------------------- That's as Peter said. Accidentally an empy jar was included in ear lib directory so this generate the java.util.zip.ZipException. Thanks. > Exploded EAR deployment error - java.util.zip.ZipException: error in opening zip file > ------------------------------------------------------------------------------------- > > Key: AS7-995 > URL: https://issues.jboss.org/browse/AS7-995 > Project: Application Server 7 > Issue Type: Bug > Components: VFS > Affects Versions: 7.0.0.Beta3 > Environment: JBoss Tools 3.3-M6 (Eclipse Indigo, Win7 32-bit), Maven 3.0.3 application > Reporter: Peter Bocak > Labels: ear, maven, vfs > Fix For: No Release > > Attachments: deployments.zip > > > Deployment of EAR application (ejb module, JSF war module, 2 jar libraries) fails with ZipException error on JBoss AS Beta 3 and Beta-4-SNAPSHOT using standalone server with exploded archives. Application is published by JBoss Tools 3.3.M6. Content of "\jboss-7.0.0.Beta3\standalone\deployments" directory included in attachment. > 15:20:17,611 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "SNapplication-0.0.1-SNAPSHOT.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:108) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_22] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_22] > at java.lang.Thread.run(Unknown Source) [:1.6.0_22] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to process children for EAR ["/C:/Dev/jboss-7.0.0.Beta3/bin/content/SNapplication-0.0.1-SNAPSHOT.ear"] > at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:211) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:102) > ... 4 more > Caused by: java.util.zip.ZipException: error in opening zip file > at java.util.zip.ZipFile.open(Native Method) [:1.6.0_22] > at java.util.zip.ZipFile.<init>(Unknown Source) [:1.6.0_22] > at java.util.jar.JarFile.<init>(Unknown Source) [:1.6.0_22] > at java.util.jar.JarFile.<init>(Unknown Source) [:1.6.0_22] > at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:94) > at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:80) > at org.jboss.vfs.VFS.mountZip(VFS.java:428) > at org.jboss.vfs.VFS.mountZip(VFS.java:454) > at org.jboss.as.ee.structure.EarStructureProcessor.mount(EarStructureProcessor.java:216) > at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:124) > ... 5 more > 15:20:17,615 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report > Services which failed to start: > service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."SNapplication-0.0.1-SNAPSHOT.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "SNapplication-0.0.1-SNAPSHOT.ear" > ------------------------------------------------------------------------------------------------------------------ > EAR structure: > \business-0.0.1-SNAPSHOT.jar > \userweb-0.0.1-SNAPSHOT.war > \META-INF\application.xml > \META-INF\jboss-app.xml > \META-INF\MANIFEST.MF > \lib\domain-0.0.1-SNAPSHOT.jar > \lib\eclipselink-2.2.0.jar > \lib\javax.persistence-2.0.3.jar > \lib\wsclients-0.0.1-SNAPSHOT.jar > pom.xml: > <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> > <modelVersion>4.0.0</modelVersion> > <artifactId>application</artifactId> > <packaging>ear</packaging> > <name>SMS Notify Application</name> > <parent> > <groupId>sk.arsnova.sn</groupId> > <artifactId>assembly</artifactId> > <version>0.0.1-SNAPSHOT</version> > </parent> > <properties> > <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> > </properties> > <dependencies> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>business</artifactId> > <version>${project.version}</version> > <type>ejb</type> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>domain</artifactId> > <version>${project.version}</version> > <type>jar</type> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>userweb</artifactId> > <version>${project.version}</version> > <type>war</type> > <scope>compile</scope> > </dependency> > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>wsclients</artifactId> > <version>${project.version}</version> > <type>jar</type> > <scope>compile</scope> > </dependency> > </dependencies> > <build> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-compiler-plugin</artifactId> > <version>2.3.2</version> > <configuration> > <source>1.6</source> > <target>1.6</target> > </configuration> > </plugin> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-ear-plugin</artifactId> > <version>2.5</version> > <configuration> > <version>6</version> > <defaultLibBundleDir>lib</defaultLibBundleDir> > </configuration> > </plugin> > </plugins> > </build> > </project> > application.xml: > <?xml version="1.0" encoding="UTF-8"?> > <application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6"> > <display-name>application</display-name> > <module> > <ejb>business-0.0.1-SNAPSHOT.jar</ejb> > </module> > <module> > <web> > <web-uri>userweb-0.0.1-SNAPSHOT.war</web-uri> > <context-root>/userweb</context-root> > </web> > </module> > <library-directory>lib</library-directory> > </application> > Unexploded EAR deploys succesfully. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs)

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plu... ] Matt Mahoney commented on HAWKULARQE-63: ---------------------------------------- On Sat, Mar 18, 2017 at 3:22 PM, John Mazzitelli <mazz(a)redhat.com> wrote: Just released Hawkular Java Agent 0.29.1.Final that contains a new feature. To support deploying Java Agent within containers (though this feature isn't restricted to that use-case), you can configure many settings in the Java Agent YAML config with ${x} expressions (similar to how HWFA can be configured in standalone.xml). It supports getting values from system properties, environment variables, with default values optionally defined. The following expressions are supported - hopefully this is self-explanatory: ${some.system.property} ${some.system.property:a-default-value} ${ENV~SOME_ENV_VAR} ${ENV~SOME_ENV_VAR:a-default-value} Not all properties support expressions (most don't need them) but properties that define things like hosts, ports, urls, passwords, filepaths, do support expressions. If I missed any, or if you'd like a property to support expressions that does not currently, write a HWKAGENT JIRA: https://issues.jboss.org/projects/HWKAGENT > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Changes (Non JMANs)

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plu... ] Matt Mahoney updated HAWKULARQE-63: ----------------------------------- Summary: Hawkular Agent - Changes (Non JMANs) (was: Hawkular Agent - Regression Testing) > Hawkular Agent - Changes (Non JMANs) > ------------------------------------ > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8406) Referencing credential store from mail subsystem without alias results in returned password "undefined"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8406?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-8406: ----------------------------------- Affects Version/s: (was: 10.1.0.Final) > Referencing credential store from mail subsystem without alias results in returned password "undefined" > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-8406 > URL: https://issues.jboss.org/browse/WFLY-8406 > Project: WildFly > Issue Type: Bug > Components: Mail > Reporter: Martin Stefanko > Assignee: Martin Stefanko > > When using credential-reference pointing only to store without password, it results in using password "undefined" > As providing password which is incorrect one is very bad from security point of view, marking as blocker for GA. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-63) Hawkular Agent - Regression Testing

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-63?page=com.atlassian.jira.plu... ] Matt Mahoney commented on HAWKULARQE-63: ---------------------------------------- >From JMazz: The only thing added post-0.28.0.Final was this Java Agent stuff. The Wildfly Agent (the thing you've been testing with) hasn't changed - it should work the same as before. The Java Agent that was introduced should work the same as that WildFly agent except: 1) it is installed via the -javaagent option when launching a JVM, not injected in standalone.xml within WildFly itself 2) it uses its own YAML configuration file rather than XML in the standalone.xml (thought the yaml setting names mimic the XML element/attribute names - e.g. metric-set-dmr, local-dmr, etc). Example yaml files are found here (see the real-config*.yaml ones): https://github.com/hawkular/hawkular-agent/tree/master/hawkular-javaagent... 3) You cannot run Java Agent directly in a Host Controller - but since domain mode isn't supported in this Middleware Manager stuff, I doubt you care about that. Really, other than that, this Java Agent should behave just like the WildFly Agent. That is in theory - in actuality, we'll need testing to find the places that are broken But the pieces that are going to be broke are probably not in the agent directly, but in the Middleware Manager UI that hardcoded some things it expects when the agent is deployed as a WildFly subsystem. We would need to fix those kinds of things. > Hawkular Agent - Regression Testing > ----------------------------------- > > Key: HAWKULARQE-63 > URL: https://issues.jboss.org/browse/HAWKULARQE-63 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Michael Foley > > Place Holder task for now: > Changes expected to Hawkular Agent which will require full regression testing: > * Agent running on Bare Metal: Start/Stop will change - full regress needed. > * OpenShift: No expected changes, but should regression test. > *+*Development will write a blog post on the changes, once they are ready to be merged.*+* -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ] Josef Cacek closed WFCORE-2046. ------------------------------- Fix Version/s: (was: 3.0.0.Beta11) Resolution: Won't Fix Aligning the status with JBEAP-7523 - setting to "Won't fix", as the presented fix is not on EAP/WildFly side, but in on IBM java side. IBM Java users who hit this issue should upgrade the Java SDK to (at least) 8.0 SR4 FP1. > KeyManager synchronization issue when using IBM JDK > --------------------------------------------------- > > Key: WFCORE-2046 > URL: https://issues.jboss.org/browse/WFCORE-2046 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: test-app-ibm-jdk-keymanager-sync.zip > > > We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords. > As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines. > Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}). > The workflow: > # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}} > # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}} > # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore. > *Possible workaround* > We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1488) Fix JSONMarshaller.writeMap() check for double-wrapping for map values

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1488: -------------------------------------- Summary: Fix JSONMarshaller.writeMap() check for double-wrapping for map values Key: DROOLS-1488 URL: https://issues.jboss.org/browse/DROOLS-1488 Project: Drools Issue Type: Bug Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor The fix is the same as highlighted in the [closed PR #856|https://github.com/kiegroup/droolsjbpm-integration/pull/856]. While the originally proposed fix is working on serialization, it posed some issues during de-serialization side, suggesting the correction cannot be a blind-fix as per original [closed PR #856|https://github.com/kiegroup/droolsjbpm-integration/pull/856]. It is suggested to investigate further with a comprehensive test, including serialization and deserialization. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017