December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6221) JCA workmanager and bootstrap-context "name" attributes are read-write

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6221: ------------------------------------- Summary: JCA workmanager and bootstrap-context "name" attributes are read-write Key: AS7-6221 URL: https://issues.jboss.org/browse/AS7-6221 Project: Application Server 7 Issue Type: Bug Components: Domain Management, JCA Reporter: Brian Stansberry Assignee: Stefano Maestri Fix For: 7.3.0.Alpha1 The "name" attributes for workmanager and bootstrap-context resources are read-write and should be read-only. They represent the value of the last element of the resource address and thus should not be changed independently of adding/removing the resource. Where we find these "name" attributes we've been converting their handling such that when they get registered in ManagementResourceRegistration, it is done like this: mrr.registerReadOnlyAttribute(NAME, ReadResourceNameOperationStepHandler.INSTANCE); where "NAME" is an AttributeDefinition. With that, the "add" handler for the resource shouldn't store the name in the model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6192) Upgrade JGroups to 3.2.5.Final

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-6192?page=com.atlassian.jira.plugin.s... ] Paul Ferraro commented on AS7-6192: ----------------------------------- This version isn't yet supported by Infinispan (as of 5.2.0.Beta6). > Upgrade JGroups to 3.2.5.Final > ------------------------------ > > Key: AS7-6192 > URL: https://issues.jboss.org/browse/AS7-6192 > Project: Application Server 7 > Issue Type: Component Upgrade > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 7.2.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6220) WebJASPIAuthenticator ignores descriptor roles if GroupPrincipalCallback is not empty

by Stefan Guilhen (JIRA)

Stefan Guilhen created AS7-6220: ----------------------------------- Summary: WebJASPIAuthenticator ignores descriptor roles if GroupPrincipalCallback is not empty Key: AS7-6220 URL: https://issues.jboss.org/browse/AS7-6220 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.3.Final (EAP) Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP) The fix for AS7-5735 introduced a regression in the TCK tests because now the WebJASPIAuthenticator is ignoring the descriptor roles when a non-empty GroupPrincipalCallback is returned from the JASPI authentication. The authenticator must add the descriptor roles to the set of roles retrieved from the GroupPrincipalCallback -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6068) jar file system is broken again (regression)

by Alvin Thompson (JIRA)

[ https://issues.jboss.org/browse/AS7-6068?page=com.atlassian.jira.plugin.s... ] Alvin Thompson edited comment on AS7-6068 at 12/19/12 12:04 PM: ---------------------------------------------------------------- Test case? Add a security provider jar to your war/ear and attempt to use it. I used bouncycastle but I imagine it doesn't make a difference. Before the security provider can load, the jar needs to be validated. This is done by accessing the files through the jar file system (provided by jboss) and inspecting them (I imagine it does something like comparing the file's checksum to a known value). Apparently, the jar file system does not properly handle the "jar within a jar" scenario. Please look at the related bug for details. was (Author: alvint): Test case? Add a security provider jar to your war/ear and attempt to use it. I used bouncycastle but I imagine it doesn't make a difference. Before the security provider can load, the jar needs to be validated. This is done by accessing the files through the jar file system (provided by jboss) and inspecting them (I imagine it does something like comparing the file's checksum to a known value). Apparently, the jar file system does not properly handle the "jar within a jar" scenario. > jar file system is broken again (regression) > -------------------------------------------- > > Key: AS7-6068 > URL: https://issues.jboss.org/browse/AS7-6068 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Reporter: Alvin Thompson > Assignee: JBoss SET > Priority: Critical > > Similar to issue JBAS-7882, you cannot bundle a security provider in a WAR/EAR, because JBOSS's jar file system becomes confused when there are JARs nested in other JARs/WARs/EARs, which is pretty much always. > This was supposedly fixed in previous versions, but it's back in 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6068) jar file system is broken again (regression)

by Alvin Thompson (JIRA)

[ https://issues.jboss.org/browse/AS7-6068?page=com.atlassian.jira.plugin.s... ] Alvin Thompson commented on AS7-6068: ------------------------------------- Test case? Add a security provider jar to your war/ear and attempt to use it. I used bouncycastle but I imagine it doesn't make a difference. Before the security provider can load, the jar needs to be validated. This is done by accessing the files through the jar file system (provided by jboss) and inspecting them (I imagine it does something like comparing the file's checksum to a known value). Apparently, the jar file system does not properly handle the "jar within a jar" scenario. > jar file system is broken again (regression) > -------------------------------------------- > > Key: AS7-6068 > URL: https://issues.jboss.org/browse/AS7-6068 > Project: Application Server 7 > Issue Type: Bug > Affects Versions: 7.1.1.Final > Reporter: Alvin Thompson > Assignee: JBoss SET > Priority: Critical > > Similar to issue JBAS-7882, you cannot bundle a security provider in a WAR/EAR, because JBOSS's jar file system becomes confused when there are JARs nested in other JARs/WARs/EARs, which is pretty much always. > This was supposedly fixed in previous versions, but it's back in 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6218) allow expressions in the infinispan subsystem

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/AS7-6218?page=com.atlassian.jira.plugin.s... ] Radoslav Husar reassigned AS7-6218: ----------------------------------- Assignee: Richard Achmatowicz (was: Radoslav Husar) > allow expressions in the infinispan subsystem > --------------------------------------------- > > Key: AS7-6218 > URL: https://issues.jboss.org/browse/AS7-6218 > Project: Application Server 7 > Issue Type: Sub-task > Components: Clustering, Domain Management > Reporter: Jeff Mesnil > Assignee: Richard Achmatowicz > Fix For: 7.2.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6218) allow expressions in the infinispan subsystem

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/AS7-6218?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz commented on AS7-6218: ------------------------------------------ I spoke to Brian about this last week and it's in progress. > allow expressions in the infinispan subsystem > --------------------------------------------- > > Key: AS7-6218 > URL: https://issues.jboss.org/browse/AS7-6218 > Project: Application Server 7 > Issue Type: Sub-task > Components: Clustering, Domain Management > Reporter: Jeff Mesnil > Assignee: Radoslav Husar > Fix For: 7.2.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6218) allow expressions in the infinispan subsystem

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/AS7-6218?page=com.atlassian.jira.plugin.s... ] Jeff Mesnil commented on AS7-6218: ---------------------------------- radoslav told me he will do it and coordinate with the team > allow expressions in the infinispan subsystem > --------------------------------------------- > > Key: AS7-6218 > URL: https://issues.jboss.org/browse/AS7-6218 > Project: Application Server 7 > Issue Type: Sub-task > Components: Clustering, Domain Management > Reporter: Jeff Mesnil > Assignee: Radoslav Husar > Fix For: 7.2.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s... ] Thomas Diesler edited comment on AS7-5951 at 12/19/12 11:21 AM: ---------------------------------------------------------------- I think we need more data here. I updated the framework and bootstrap integration code to produce better logging. You should now see something like this {code} [tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of" 17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL 17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE 17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE 17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE 17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE 17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE {code} The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules. For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue. The related code change is [here|https://github.com/jbossas/jboss-as/pull/3713] was (Author: thomas.diesler): I think we need more data here. I updated the framework and bootstrap integration code to produce better logging. You should now see something like this {code} [tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of" 17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL 17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE 17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE 17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE 17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE 17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE {code} The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules. For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue. > Cannot reliably deploy OSGi host and fragment bundles on server restart > ----------------------------------------------------------------------- > > Key: AS7-5951 > URL: https://issues.jboss.org/browse/AS7-5951 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows XP SP3 > Reporter: Paul Illingworth > Assignee: Thomas Diesler > Labels: OSGI > Attachments: this_one_failed.txt, this_one_worked.txt > > > If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist (fragment) into the "deployments" folder then the there is no guarantee the fragments will be installed before the host and so they may not be attached to the host when it resolves. > This happens on starting the application server. Sometimes the fragments are attached, sometimes they aren't. > If I install the bundles into the "bundles" folder structure and add capability entries to the standalone.xml file then it works as expected. > I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-5951) Cannot reliably deploy OSGi host and fragment bundles on server restart

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/AS7-5951?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-5951: ------------------------------------- I think we need more data here. I updated the framework and bootstrap integration code to produce better logging. You should now see something like this {code} [tdiesler@tdmac jboss-as-7.2.0.Alpha1-SNAPSHOT]$ cat standalone/log/server.log | grep "on behalf of" 17:00:43,353 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Install bootstrap deployments [[org.apache.felix.log:1.0.0,location=org.apache.felix.log], [jboss-osgi-logging:1.0.0,location=org.jboss.osgi.logging], [org.apache.felix.configadmin:1.2.8,location=org.apache.felix.configadmin], [jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT,location=org.jboss.as.osgi.configadmin]] on behalf of jbosgi.BootstrapBundles.INSTALL 17:00:43,379 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Resolve bootstrap bundles on behalf of jbosgi.BootstrapBundles.RESOLVE 17:00:43,481 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-3) Activate bootstrap bundles on behalf of jbosgi.BootstrapBundles.ACTIVATE 17:00:43,487 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Complete bootstrap bundles on behalf of jbosgi.BootstrapBundles.COMPLETE 17:00:43,502 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Install persistent deployments [] on behalf of jbosgi.PersistentBundles.INSTALL 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Resolve persistent bundles on behalf of jbosgi.PersistentBundles.RESOLVE 17:00:43,503 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-7) Activate persistent bundles on behalf of jbosgi.PersistentBundles.ACTIVATE 17:00:43,504 DEBUG [org.jboss.osgi.framework] (MSC service thread 1-8) Complete persistent bundles on behalf of jbosgi.PersistentBundles.COMPLETE {code} The idea is that the persistent bundles get installed only after the bootstrap bundles (i.e. the configured capabilities) complete. Also, no persistent bundle should resolve before not all persistent bundles are installed. Could you please verify you output according to these rules. For a fragment that does not attach, we need to find out why it is not included in the resolve attempt. If it is included, it might be a resolver issue. > Cannot reliably deploy OSGi host and fragment bundles on server restart > ----------------------------------------------------------------------- > > Key: AS7-5951 > URL: https://issues.jboss.org/browse/AS7-5951 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.2.0.Alpha1 > Environment: Windows XP SP3 > Reporter: Paul Illingworth > Assignee: Thomas Diesler > Labels: OSGI > Attachments: this_one_failed.txt, this_one_worked.txt > > > If I deploy guice-3.0.0 (host bundle), guice-servlet (fragment) and guice-persist (fragment) into the "deployments" folder then the there is no guarantee the fragments will be installed before the host and so they may not be attached to the host when it resolves. > This happens on starting the application server. Sometimes the fragments are attached, sometimes they aren't. > If I install the bundles into the "bundles" folder structure and add capability entries to the standalone.xml file then it works as expected. > I am using 7.2.0-Alpha1 built from cb72a7cd1669131b28a552f1dbf3c2582ad19813. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

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 December 2012