May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1525) ageout-history does not report failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1525?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1525: ------------------------------------------------- Bartek Spyrko-Smietanko <bspyrkos(a)redhat.com> changed the Status of [bug 1331586|https://bugzilla.redhat.com/show_bug.cgi?id=1331586] from ASSIGNED to POST > ageout-history does not report failures > ---------------------------------------- > > Key: WFCORE-1525 > URL: https://issues.jboss.org/browse/WFCORE-1525 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 2.1.0.Final > Reporter: Dennis Reed > Assignee: Bartosz Spyrko-Śmietanko > > When ageout-history cannot delete the old CP files, it silently fails and returns "success". > LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the > delete failed or succeeded, but the return value from this method is ignored > in execute(...). > If recursiveDelete returns false, it should report a failure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1526) ageout-history does not report failures

by Bartosz Spyrko-Śmietanko (JIRA)

Bartosz Spyrko-Śmietanko created WFCORE-1526: ------------------------------------------------ Summary: ageout-history does not report failures Key: WFCORE-1526 URL: https://issues.jboss.org/browse/WFCORE-1526 Project: WildFly Core Issue Type: Bug Components: Patching Affects Versions: 2.1.0.Final Reporter: Bartosz Spyrko-Śmietanko Assignee: Bartosz Spyrko-Śmietanko When ageout-history cannot delete the old CP files, it silently fails and returns "success". LocalAgeoutHistoryHandler#recursiveDelete does keep track of whether the delete failed or succeeded, but the return value from this method is ignored in execute(...). If recursiveDelete returns false, it should report a failure. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6590) Client thread pool max size parameter should be possible to parametrize in CLI

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-6590?page=com.atlassian.jira.plugin.... ] Miroslav Novak moved JBEAP-4539 to WFLY-6590: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6590 (was: JBEAP-4539) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER6) > Client thread pool max size parameter should be possible to parametrize in CLI > ------------------------------------------------------------------------------ > > Key: WFLY-6590 > URL: https://issues.jboss.org/browse/WFLY-6590 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > > Based on discussion in JBEAP-2947, we should provide CLI parameter to set maximum size of client thread pool. > Currently {{-Dactivemq.artemis.client.global.thread.pool.max.size=<value>}} must be provided as system property during start of EAP 7 server. > This thread pool can be injected by Wildfly. This could be the way to limit make its size configurable by Wildfly -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6589) Add attribute to model which will indicate that backup is synchronized with live server

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-6589?page=com.atlassian.jira.plugin.... ] Miroslav Novak moved JBEAP-4538 to WFLY-6589: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6589 (was: JBEAP-4538) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) (was: ActiveMQ) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER7) > Add attribute to model which will indicate that backup is synchronized with live server > ---------------------------------------------------------------------------------------- > > Key: WFLY-6589 > URL: https://issues.jboss.org/browse/WFLY-6589 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Critical > > If HA is configured with replicated journal then it takes some time to backup to synchronize with live server. Once backup is in sync with live then following information appears in server.log: > {code} > 13:20:00,739 INFO [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server. > 13:20:01,500 INFO [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@41f992ab-83559664)) AMQ221031: backup announced > {code} > Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command? > New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}} > This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}} > Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6588) Allow configuration of rebalanceConnections activation config property in pooled-connection-factory

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-6588?page=com.atlassian.jira.plugin.... ] Miroslav Novak moved JBEAP-4537 to WFLY-6588: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6588 (was: JBEAP-4537) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.CR2) > Allow configuration of rebalanceConnections activation config property in pooled-connection-factory > --------------------------------------------------------------------------------------------------- > > Key: WFLY-6588 > URL: https://issues.jboss.org/browse/WFLY-6588 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Critical > > For inbound connections we allow to configure activation config property {{rebalanceConnections}} for MDBs which allows to rebalance inbound connection in runtime when underlying Artemis cluster topology changes. > Purpose of this RFE is to add it to configuration of inbound connections in pooled-connection-factory so it does not have to be specified in every MDB. Default should be set to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-527) Handling of SSLSessionAuthorizationCallback is missing a call to authorize()

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-527?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-527: --------------------------------- SSL session authorization is already an authorization (like AnonymousAuthorizationCallback) so a redundant authorize should not be necessary. That said if we're dropping this class in favor of proper scope auth, we'd need to go back to using AuthorizeCallback again. > Handling of SSLSessionAuthorizationCallback is missing a call to authorize() > ---------------------------------------------------------------------------- > > Key: ELY-527 > URL: https://issues.jboss.org/browse/ELY-527 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-527) Handling of SSLSessionAuthorizationCallback is missing a call to authorize()

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-527: ------------------------------------ Summary: Handling of SSLSessionAuthorizationCallback is missing a call to authorize() Key: ELY-527 URL: https://issues.jboss.org/browse/ELY-527 Project: WildFly Elytron Issue Type: Bug Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6163) Remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6163?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6163: ----------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1311733|https://bugzilla.redhat.com/show_bug.cgi?id=1311733] from ON_QA to VERIFIED > Remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-6163 > URL: https://issues.jboss.org/browse/WFLY-6163 > Project: WildFly > Issue Type: Task > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 10.1.0.Final > > > We can remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module as Santuario is not needed directly from JBossWS (it's directly used by WSS4J and CXF though). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-761: ------------------------------------------------ Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from ON_QA to VERIFIED > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Bartosz Baranowski > Assignee: Dimitris Andreadis > Priority: Critical > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[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: ------------------------------------------------ Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from ON_QA to VERIFIED > 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)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016