March 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip/jar file

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-547: ------------------------------------------------ Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from POST to MODIFIED > Unable to overlay resource in subunit/zip/jar file > -------------------------------------------------- > > Key: WFCORE-547 > URL: https://issues.jboss.org/browse/WFCORE-547 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha18 > Reporter: Bartosz Baranowski > Assignee: Stuart Douglas > Fix For: 1.0.0.Beta1 > > > It is possible to overlay resource directly in deployed jar, however, same resource can not be properly overlayed if said jar is deployed as part of ear ( possibly war as well ). > Example: > jar (xxx.jar): > /org/test/ejb/EJBImpl.class > /org/test/ejb/resourceToOverlya.txt > ear(yyy.ear) - war seems to be the subject of this as well > /xxx.jar > Overlay #1( over jar) > overlay target: xxx.jar/org/test/ejb/resourceToOverlya.txt > Result: proper deployment(EJB is deployed), resource has been overlayed > Overlay #2( over jar inside ear ) > overlay target: org/test/ejb/resourceToOverlya.txt > Result: bad deployment, no EJB deployed, overlay target has been overlayed > Reason of such outcome is that VFS.exists() does not recognize JavaZipFileSystem$ZipNode/Entry as zipped archive and does not dive into children. > So what happens in here is as follows. When EAR is deployed OverlayProcessor kicks in at: > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > For this example ear/jar pair, first pair of values: > mountPoint: /content/yyy.ear/xxx.jar/org/test/ejb/resourceToOverlya.txt > parent: /content/yyy.ear/xxx.jar/org/test/ejb > Outcome of exists() call == false, should be true. > this will iterate up to parent == /content/yyy.ear/xxx.jar > At this point, 'createParents' contain some entries and > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > will create tmp/virtual mounts for: > - /content/yyy.ear/xxx.jar/org/test/ejb > - /content/yyy.ear/xxx.jar/org/test > - /content/yyy.ear/xxx.jar/org > What it will essentially do is create overlay for whole 'org' package! The VirtualFile.getChildren() will return tmp mounted VirtualFile for 'org' entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... > There is part of code which should remove 'submount' if there is directory entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... however ( if I remember correctly) 'org' tmp mount ends up twice in 'submounts' > When VirtualFile.getChildren is called for 'this' == /content/yyy.ear/xxx.jar ( in this case it is properly removed) and when 'this' == /content/yyy.ear/xxx.jar/org - in which case it derails getChildren and diverts into tmp mount. > Now about https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... > What happens here, for ear deployment - it dives recursively into 'find' until 'target' is equal to '/content/yyy.ear/xxx.jar' at this target.getParent() == 'mountPoint' == '/content/yyy.ear'. > At this point 'find' will get result ZipNode == /content/yyy.ear and fetch child 'xxx.jar' and pop back up one notch in the call stack. However the 'xxx.jar' entry does not have any children, hence there is no way to fetch next child in line 'org'. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1120046|https://bugzilla.redhat.com/show_bug.cgi?id=1120046] from POST to MODIFIED > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3483) Improve the ability to use MS Windows keystore for the web servers ssl connector

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3483?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3483: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1108310|https://bugzilla.redhat.com/show_bug.cgi?id=1108310] from POST to MODIFIED > Improve the ability to use MS Windows keystore for the web servers ssl connector > -------------------------------------------------------------------------------- > > Key: WFLY-3483 > URL: https://issues.jboss.org/browse/WFLY-3483 > Project: WildFly > Issue Type: Enhancement > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 8.1.0.Final > > > It is possible to configure the web ssl connector to use the Windows certificate keystore (access provided by the SunMSCAPI provider). However, the JSSESocketFactory checks for a keystore file. This check should likely be skipped when the connector is configured to use the Windows keystore. > Here is what the configuration looks like: > {noformat} > <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true"> > <ssl name="https" > key-alias="jbossweb" > keystore-type="Windows-MY" > protocol="TLSv1" > </connector> > {noformat} > This results in an error like this: > 13:54:01,821 ERROR [org.apache.coyote.http11] (MSC service thread 1-5) JBWEB003043: Error initializing endpoint: java.io.FileNotFoundException: C:\Users\imauser\.keystore (The system cannot find the file specified) > You can work around this issue by creating this keystore (C:\Users\imauser\.keystore). > More info on using the Windows keystores can be found here: > http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProvide... > http://www.oracle.com/technetwork/articles/javase/security-137537.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3849) logging improvement to WFLYSEC0015 (vault security exception)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3849?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3849: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 1073603|https://bugzilla.redhat.com/show_bug.cgi?id=1073603] from POST to MODIFIED > logging improvement to WFLYSEC0015 (vault security exception) > ------------------------------------------------------------- > > Key: WFLY-3849 > URL: https://issues.jboss.org/browse/WFLY-3849 > Project: WildFly > Issue Type: Enhancement > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > Description of problem (taken from bz1073603): > Include which vault property resolution has failed in following error message: > java.lang.SecurityException: JBAS013311: Security Exception > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:104) > For example, this would be helpful: > java.lang.SecurityException: JBAS013311: Security Exception (Error resolving vault property: ${VAULT:example:example:1} > How reproducible: > Using a vault property that doesn't exist will give this error message. > Steps to Reproduce: > 1. setup vault as normal > 2. use a vault property that doesn't exist > Actual results: > Get: > java.lang.SecurityException: JBAS013311: Security Exception > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:104) > Expected results: > log message that show the property that failed -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2645: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 901300|https://bugzilla.redhat.com/show_bug.cgi?id=901300] from POST to MODIFIED > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > > See JBPAPP6-1762 for details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3809) JDR incorrectly sets JBOSS_HOME path name in the jar file on Windows

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3809?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3809: ----------------------------------------------- Sat6QE Jenkins <sat6-jenkins(a)redhat.com> changed the Status of [bug 917683|https://bugzilla.redhat.com/show_bug.cgi?id=917683] from POST to MODIFIED > JDR incorrectly sets JBOSS_HOME path name in the jar file on Windows > -------------------------------------------------------------------- > > Key: WFLY-3809 > URL: https://issues.jboss.org/browse/WFLY-3809 > Project: WildFly > Issue Type: Bug > Components: JDR > Environment: All modes on Windows > Reporter: Jesse Jaggars > Assignee: Jesse Jaggars > > JDR replaces $JBOSS_HOME with the text `JBOSS_HOME` in the generated zipfile. On windows the path is improperly constructed. For example if JBOSS_HOME=/foo/bar/baz, when the file /foo/bar/baz/example.txt is copied into the JDR archive the path will be: > JBOSS_HOMEz/example.txt > It should be: > JBOSS_HOME/example.txt -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-273: ----------------------------------------- Making a list sounds good. I won't opine on "auto-start=true and not running" until I see the list, otherwise the list will just point out all the contradictions in whatever I say. ;) One other important factor in our decisions is "what do we do now?" If something isn't clearly broken, not changing behavior has a lot of merit. > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-273: ---------------------------------- Adding a server with auto-start=false then starting it, after an HC reload with --restart-servers=true, doesn't get started. I think these should get restarted if running. What about the reverse case, if auto-start=true and not running, should it be started with --restart-servers? (My initial reaction is no.) This seems to be overlapping into update-auto-start-with-server-status = true. I'll make a list of the states & outcomes with auto-start, --restart=true|false and update-auto-start-with-server-status and review. > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-273: ---------------------------------- [~bstansberry] Thanks for the info. I'd checked the zombie cases on reconnect, but not reload with --restart-servers=true, I've reopened to check those, then I'll check in with [~ehugonnet] > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ] Ken Wills reopened WFCORE-273: ------------------------------ > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 2016