[JBoss JIRA] (WFLY-349) FreeBSD isThreadCpuTimeSupported
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-349?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-349:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> FreeBSD isThreadCpuTimeSupported
> --------------------------------
>
> Key: WFLY-349
> URL: https://issues.jboss.org/browse/WFLY-349
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: FreeBSD 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
> openjdk6/openjdk7
> Reporter: Alexander Yerenkow
> Fix For: 8.0.0.CR1
>
>
> Platform Tests should be modified, since it's not respecting when isThreadCpuTimeSupported = false (It continues run some test with isThreadCpuTimeSupported, which produces Exceptions, and all test failed);
> Simple test:
> ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean();
> System.out.println("threadMXBean.isThreadCpuTimeSupported() = " + threadMXBean.isThreadCpuTimeSupported());
> System.out.println("threadMXBean.isThreadCpuTimeEnabled() = " + threadMXBean.isThreadCpuTimeEnabled());
> Result:
> threadMXBean.isThreadCpuTimeSupported() = false
> Exception in thread "main" java.lang.UnsupportedOperationException: Thread CPU time measurement is not supported
> at sun.management.ThreadImpl.isThreadCpuTimeEnabled(ThreadImpl.java:98)
> at Test.main(Test.java:19)
--
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
11 years, 3 months
[JBoss JIRA] (WFLY-364) a "failure-causes-rollback="false"" attribute for the filesystem scanner
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-364:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> a "failure-causes-rollback="false"" attribute for the filesystem scanner
> ------------------------------------------------------------------------
>
> Key: WFLY-364
> URL: https://issues.jboss.org/browse/WFLY-364
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Max Rydahl Andersen
> Fix For: 8.0.0.CR1
>
>
> JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments.
> Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback.
> Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work.
--
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
11 years, 3 months
[JBoss JIRA] (WFLY-377) Provide "destroy-queue" and "destroy-topic" operations to CLI
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-377?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-377:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Provide "destroy-queue" and "destroy-topic" operations to CLI
> -------------------------------------------------------------
>
> Key: WFLY-377
> URL: https://issues.jboss.org/browse/WFLY-377
> Project: WildFly
> Issue Type: Feature Request
> Components: CLI, JMS
> Reporter: Miroslav Novak
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.CR1
>
>
> Operations "destroy-queue" and "destroy-topic" would destroy queue/topic with all its messages and subscriptions.
> They would be used under for example /subsystem=messaging/hornetq-server=default/jms-queue=testQueue or /subsystem=messaging/hornetq-server=default/jms-topic=testTopic.
> The goal is to provide a simple way how to get rid of those objects to administrators.
--
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
11 years, 3 months
[JBoss JIRA] (WFLY-368) Naming subsystem <lookup> could use LinkRef/Reference
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-368?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-368:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Naming subsystem <lookup> could use LinkRef/Reference
> -----------------------------------------------------
>
> Key: WFLY-368
> URL: https://issues.jboss.org/browse/WFLY-368
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Reporter: James Livingston
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
>
> NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it.
> It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead.
> Where this could make a difference is when Context.lookupLink() is called instead.
> Currently if you have
> <simple name="java:/v" value="hello"/>
> <lookup name="java:/a" lookup="java:/b"/>
> lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b.
> We need to decide whether a <lookup> should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value.
--
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
11 years, 3 months