[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
[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
[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
[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
[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
[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