[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2474?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2474:
-----------------------------
Component/s: Domain Management
> Security subsystem does not handle acl's module properly
> --------------------------------------------------------
>
> Key: WFLY-2474
> URL: https://issues.jboss.org/browse/WFLY-2474
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
> However in the acl resource this is called login-module=acl.
> WHen marshalling
> {code}
> <acl>
> <acl-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </acl-module>
> </acl>
> {code}
> becomes
> {code}
> <acl>
> <login-module name="acl" code="AclThingy" flag="required" module="test">
> <module-option name="d" value="r"/>
> </login-module>
> </acl>
> {code}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2475) Bad marshalling of identity-trust's module
by Kabir Khan (JIRA)
Kabir Khan created WFLY-2475:
--------------------------------
Summary: Bad marshalling of identity-trust's module
Key: WFLY-2475
URL: https://issues.jboss.org/browse/WFLY-2475
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Beta1
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 8.0.0.CR1
{code}
<identity-trust>
<trust-module name="acl" code="AclThingy" flag="required" module="test">
<module-option name="d" value="r"/>
</trust-module>
</identity-trust>
{code}
becomes
{code}
<identity-trust>
<login-module name="acl" code="AclThingy" flag="required" module="test">
<module-option name="d" value="r"/>
</login-module>
</identity-trust>
{code}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-1716) NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-1716:
----------------------------------
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1716
> URL: https://issues.jboss.org/browse/WFLY-1716
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.Alpha3
> Environment: Win 7, JEE 6, JDK 7
> Reporter: Oliver Pfau
> Assignee: Stuart Douglas
> Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> ... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>
> <all other services>
> ]
> }
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2474) Security subsystem does not handle acl's module properly
by Kabir Khan (JIRA)
Kabir Khan created WFLY-2474:
--------------------------------
Summary: Security subsystem does not handle acl's module properly
Key: WFLY-2474
URL: https://issues.jboss.org/browse/WFLY-2474
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Beta1
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 8.0.0.CR1
The parsed add is done for /subsystem=security/security-domain=other/acl=classic/acl-module=acl
However in the acl resource this is called login-module=acl.
WHen marshalling
{code}
<acl>
<acl-module name="acl" code="AclThingy" flag="required" module="test">
<module-option name="d" value="r"/>
</acl-module>
</acl>
{code}
becomes
{code}
<acl>
<login-module name="acl" code="AclThingy" flag="required" module="test">
<module-option name="d" value="r"/>
</login-module>
</acl>
{code}
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2472) jboss-as-xts_1_0.xsd in WildFly modified since EAP release
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2472?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2472:
----------------------------------------
Hello Tom,
Yes it is something along those lines - overall the changes need to be reviewed in a but more detail to get to the bottom of the exact change needed.
In some cases we have found that actually parsers were supporting features not documented in the schema, in that case we can sometimes get away with just updating the schema in all locations - our main concern is backwards compatibility so if the parser was supporting something then updating the schema is just really updating docs to reflect it.
On the other hand once a schema makes it into a Final or GA release it needs to be considered frozen for backwards compatibility purposes and only compatible changes should be made at that point e.g. correcting documentation.
At this point any schema changes in WildFly should actually result in a schema in the 2.x range (All should be no more than 2.0 at this point as we have not had the first Final release) - this then leaves EAP free to continue to add additional 1.x schemas without conflict. Of course if we know a change being made to a subsystem is going to be made in exactly the same way in EAP we can sometimes add a 1.x schema to WildFly and add the same to EAP.
Sorry for not being precise with a response, unfortunately this area is a little complex with some decisions needed on a case by case basis with the main rule being compatibility once it reaches a GA or Final release.
In this case it is about the additional elements added in WildFly - a configuration based on that schema that is working in WildFly would fail on EAP despite the schema with the same namespace being supported on EAP.
Maybe also get a thread started in wildfly-dev(a)lists.jboss.org - I can be contacted in IRC but we may also want some input from Brian as well.
> jboss-as-xts_1_0.xsd in WildFly modified since EAP release
> ----------------------------------------------------------
>
> Key: WFLY-2472
> URL: https://issues.jboss.org/browse/WFLY-2472
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Darran Lofthouse
> Assignee: Tom Jenkinson
> Fix For: 8.0.0.CR1
>
>
> The schema 'jboss-as-xts_1_0.xsd' has been modified in WildFly making it incompatible with the version in EAP - additional elements have been added.
> The following commit is where additional elements were added: -
> https://github.com/wildfly/wildfly/commit/09dda67ed71b9f5cf4c9f865f08bbe3...
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on WFLY-2426:
-----------------------------------
> resp. https://github.com/jbossas/jboss-eap/blob/b8f636d9a765fcfe67cf0a8e2ff2804...
This file is already scanned by our tools to get the information. There were previous bugs in our implementation regarding our incorrect implementation of it (see JBIDE-14993, there was a 2nd jira about it but i cant find it). We had previously been looking in "modules/system/layers/" + layer + "/org/jboss/as/product/" + layer + "/dir/META-INF"; but it seems we should have been looking in "modules/system/layers/" + layer + "/org/jboss/as/product/" + slot + "/dir/META-INF";
I don't think this file needs to be moved to root. It's useful where it is now, since all finally agree on where this file should live. But I believe this needs to be more official and perhaps have some type of unit test if it's at all possible to ensure that every release has this file in the proper location. It's pretty official now, and more people do depend on it, so it seems it's pretty stable at this point and won't need to be moved up to root.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-2427) Launcher API
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on WFLY-2427:
-----------------------------------
I agree with all points here above. As far as the way jbt currently works, the areas that we constantly have to replicate each time a new app server comes out is getting:
1) The required classpath
2) The default launch program args
3) The default vm args
If we were only using this to acquire the default arguments, then it seems useful for us. I'm sure others may use the launch() method, but not tools, as has been said above.
I agree that which vm to use is out of scope, but, if in any situation the arguments will change based on the VM, then we (tools) should be given the opportunity to pass in a VM location. I'm not sure if this is easily accomplished on the utility lib's end, though. If we were to pass to you a specific VM root directory, would you be able to figure out how to customize the args based on that?
> Launcher API
> ------------
>
> Key: WFLY-2427
> URL: https://issues.jboss.org/browse/WFLY-2427
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Rob Stryker
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
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
12 years, 8 months
[JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-795:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1028412
> jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements
> --------------------------------------------------------------------------------------
>
> Key: WFLY-795
> URL: https://issues.jboss.org/browse/WFLY-795
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: James Livingston
> Assignee: David Lloyd
> Fix For: 8.0.0.CR1
>
>
> In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute.
> This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate.
--
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
12 years, 8 months