[JBoss JIRA] (WFLY-490) Domain Management Role Based Access Control
by Felix Winistörfer (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Felix Winistörfer commented on WFLY-490:
----------------------------------------
Not available till 06.01.2014.
Your mail may be (or may not be) read a little bit later.
Please contact NPE.
> Domain Management Role Based Access Control
> -------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.Final
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
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, 7 months
[JBoss JIRA] (WFLY-334) HA Singleton deployer for applications
by Jochen Riedlinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-334?page=com.atlassian.jira.plugin.s... ]
Jochen Riedlinger commented on WFLY-334:
----------------------------------------
Sehr geehrte Damen und Herren, von Montag, den 23.12.2013, bis einschließlich Freitag, den 10.01.2014, bin ich nicht im Hause. In dringenden Fällen wenden Sie sich bitte an Heiner Tittelbach (IT 271) oder Bernd Kirchgäßner (IT 221). Ihre Mail wird nicht automatisch weitergeleitet. Mit freundlichen Grüßen Jochen Riedlinger
> HA Singleton deployer for applications
> --------------------------------------
>
> Key: WFLY-334
> URL: https://issues.jboss.org/browse/WFLY-334
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering, Domain Management
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployers, hasingleton
> Fix For: 8.0.0.Final
>
>
> A HASingleton deployer should be provided in standalone and domain mode.
> To be able to migrate such singleton applications from former AS versions.
--
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, 7 months
[JBoss JIRA] (WFLY-11) Bundle path for Embedded server still not working properly
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-11?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-11:
-----------------------------
Fix Version/s: 8.0.0.Final
> Bundle path for Embedded server still not working properly
> ----------------------------------------------------------
>
> Key: WFLY-11
> URL: https://issues.jboss.org/browse/WFLY-11
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Error is:
> {code} io.escalante.test.artifact.ArtifactInstallTest: bundlesDir not a directory{code}
> The problem is that the check is done in an 'assert' block and that only happens when assertions have been enabled by the user :(
> The problem comes cos bundlesDir is set to "null/bundles", even if I have not set any bundlesDir.
> Seems like bundlesDir is pre-computed too early in EmbeddedContainerConfiguration where it expects a system property, but that might not be set, it might come from arquillian.xml. So better delay until EmbeddedServerFactory.create.
--
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, 7 months
[JBoss JIRA] (WFLY-343) lower messaging's min-large-message-size value in standalone-full.xml
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-343?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-343:
------------------------------
Fix Version/s: (was: 8.0.0.CR1)
> lower messaging's min-large-message-size value in standalone-full.xml
> ---------------------------------------------------------------------
>
> Key: WFLY-343
> URL: https://issues.jboss.org/browse/WFLY-343
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Final
>
>
> AS7's messaging subsystem defines 2 attributes:
> journal-file-size => 10MiB
> min-large-message-size => 100KiB
> However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size.
> If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?)
> For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB)
--
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, 7 months
[JBoss JIRA] (WFLY-19) JMX over remoting pollutes query results with ModelController objects
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-19:
-----------------------------
Fix Version/s: 8.0.0.Final
> JMX over remoting pollutes query results with ModelController objects
> ---------------------------------------------------------------------
>
> Key: WFLY-19
> URL: https://issues.jboss.org/browse/WFLY-19
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JMX
> Reporter: NadirX
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query.
> This is a transcript of a chat we had about it on IRC:
> Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected
> Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query
> Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x
> Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI
> Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7
> Oct 15 14:53:09 <-- fnasser has quit (Changing host)
> Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7
> Oct 15 14:53:09 --- ChanServ gives voice to fnasser
> Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ?
> Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec
> t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX
> Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns
> Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query
> Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=*
> Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added
> Oct 15 14:54:32 <ttarrant> darranl, wait a sec
> Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i
> s a remoting jmx issue or pass over if it is a domain management integration issue
> Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug
> Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning
> Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m
> anagement integration
> Oct 15 14:56:42 <darranl> ok
> Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem)
> Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results
> Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well
> Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ?
> Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name
> Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-)
--
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, 7 months
[JBoss JIRA] (WFLY-29) An ear file with modules in subfolders can not deploy under AS 7.0
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-29?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-29:
-----------------------------
Fix Version/s: 8.0.0.Final
> An ear file with modules in subfolders can not deploy under AS 7.0
> ------------------------------------------------------------------
>
> Key: WFLY-29
> URL: https://issues.jboss.org/browse/WFLY-29
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Reporter: Adrian Zuo
> Assignee: David Lloyd
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
> Attachments: migrate.ear, migrate.ear
>
>
> I have an ear file names migrate.ear which contains one ejb jar (ejb.jar) and one war file (war.war), if I put the ejb jar to a ejb folder and war file to war folder, the ear can not be depoyed.
> If I move the ejb jar and war file out, it can be deployed.
> Below structuer can be deployed:
> ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war.war
>
> Below structure can not be deployed:
> ejb/
> ejb/ejb.jar
> lib/
> lib/util-1.0-SNAPSHOT.jar
> lib/version.jar
> META-INF/
> META-INF/application.xml
> META-INF/MANIFEST.MF
> war/
> war/war.war
> Below is the error:
> http://community.jboss.org/message/630869#630869
--
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, 7 months
[JBoss JIRA] (WFLY-44) unavailable datasource statistics
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-44?page=com.atlassian.jira.plugin.sy... ]
Jason Greene updated WFLY-44:
-----------------------------
Fix Version/s: 8.0.0.Final
> unavailable datasource statistics
> ---------------------------------
>
> Key: WFLY-44
> URL: https://issues.jboss.org/browse/WFLY-44
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management, JCA, JMX
> Reporter: Mathieu Lachance
> Priority: Minor
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> In the java visual vm, in the mbean tab, under the "jboss.as:subsystem=datasources,data-source=MyDataSource" mbean, attribute "statistics" is marked as "Unavailable"
> When using the spy="true" attribute in the datasource subsystem in conjunction with the "org.jboss.jca" logger set as TRACE level in the logging subsystem, statistics are outputted as follow :
> Statistics:
> ActiveCount: 1
> AvailableCount: 99
> AverageBlockingTime: 0
> AverageCreationTime: 248
> CreatedCount: 1
> DestroyedCount: 0
> MaxCreationTime: 248
> MaxUsedCount: 1
> MaxWaitCount: 0
> MaxWaitTime: 0
> TimedOut: 0
> TotalBlockingTime: 0
> TotalCreationTime: 248
> I would except to find those statistics available through separates jmx attributes when using the spy="true".
--
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, 7 months