September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-31) The JBoss Modules schemas are missing from the build

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-31?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-31: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > The JBoss Modules schemas are missing from the build > ---------------------------------------------------- > > Key: WFCORE-31 > URL: https://issues.jboss.org/browse/WFCORE-31 > Project: WildFly Core > Issue Type: Bug > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 1.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-93) Server cannot start if server path contains two consecutive spaces

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-93?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-93: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > Server cannot start if server path contains two consecutive spaces > ------------------------------------------------------------------ > > Key: WFCORE-93 > URL: https://issues.jboss.org/browse/WFCORE-93 > Project: WildFly Core > Issue Type: Feature Request > Affects Versions: 1.0.0.Alpha5 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Minor > Fix For: 1.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-80) Upgrade org.apache.httpcomponents:httpclient to 4.3.2

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-80?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-80: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > Upgrade org.apache.httpcomponents:httpclient to 4.3.2 > ----------------------------------------------------- > > Key: WFCORE-80 > URL: https://issues.jboss.org/browse/WFCORE-80 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha5 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 1.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-77) We need even better reporting for failed authentications

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-77?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-77: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > We need even better reporting for failed authentications > -------------------------------------------------------- > > Key: WFCORE-77 > URL: https://issues.jboss.org/browse/WFCORE-77 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha7 > > > The following message is often the one reported to users: - > {noformat} > >> Caused by: javax.security.sasl.SaslException: Authentication failed: > >> the server presented no authentication mechanisms > {noformat} > Whilst technically it is true at that point in time this is most likely caused because other mechanisms have already been tried and failed and the list of mechanisms to try is now exhausted. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-95) PrimitiveListAttributeDefinition.Builder copy constructor does not copy the listValidator

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-95?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-95: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > PrimitiveListAttributeDefinition.Builder copy constructor does not copy the listValidator > ----------------------------------------------------------------------------------------- > > Key: WFCORE-95 > URL: https://issues.jboss.org/browse/WFCORE-95 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 1.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFCORE-94: ------------------------------- Fix Version/s: 1.0.0.Alpha7 (was: 1.0.0.Alpha6) > Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain > --------------------------------------------------------------------------- > > Key: WFCORE-94 > URL: https://issues.jboss.org/browse/WFCORE-94 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 1.0.0.Alpha7 > > > The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain. > The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3852) EJB @Schedule interleaves timer calls with @AccessTimeout(0)

by Tibor Digana (JIRA)

Tibor Digana created WFLY-3852: ---------------------------------- Summary: EJB @Schedule interleaves timer calls with @AccessTimeout(0) Key: WFLY-3852 URL: https://issues.jboss.org/browse/WFLY-3852 Project: WildFly Issue Type: Feature Request Components: EJB Affects Versions: 8.1.0.Final Environment: Win 7 x64 / i7 Reporter: Tibor Digana Assignee: David Lloyd Priority: Critical Note: The value in @AccessTimeout(value = 0) is not a real timeout. It's a marker skipping scheduler on concurrent Thread. Actual: The scheduled method is annotated with @AccessTimeout(0) and @Lock(READ). Very long calls interleave concurrently. Expected: The calls should not interleave if and only if @AccessTimeout(0) is used. Does not matter which LockType is used. According to the Javadoc "A value of 0 means concurrent access is not permitted." In other words the timer should give it up on concurrent Thread. The timer should not wait for read/write lock due to the value in the annotation is not -1. In the internal implementation of TomEE server the timer skips scheduling if Lock.tryLock() returns false in this usecase. This can be Read or Write lock - does not matter. Don't be confused with WFLY-3430. I think the fix in WFLY-3430 should only go with the annotation @AccessTimeout(0) with whatever LockType. If this annotation is not used then the next call should be concurrent / blocked depending on READ / WRITE LockType, respectively. My code: @Startup @Singleton @Lock(READ) public class MyTimer { @Schedule(minute = "*", hour = "*", persistent = false, info = "My Timer") @AccessTimeout(0) public void updateByMinutes() {} } -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1877 at 9/12/14 11:57 AM: ---------------------------------------------------------- Investigate: * -Responses- * -Promise- * -Request (UnicastRequest, GroupRequest)- * -MessageDispatcher / RpcDispatcher: sync RPCs- * -ExpiryCache- * -LazyRemovalCache- * -TimeService- * -Discovery-: ping responses * -Table- * -TimeScheduler3- * -TimeScheduler2- (not changed; deprecated) * -HashedTimingWheel- (not changed; as unsupported) * -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere) * -ResponseCollector- * -CreditMap- (only used for measuring block times) * -FlowControl- * Locking * -MERGE2- * -RELAY2- (no change; only used for stats) * -StatsCollector- * -RATE_LIMITER- * -PERF- was (Author: belaban): Investigate: * -Responses- * -Promise- * -Request (UnicastRequest, GroupRequest)- * -MessageDispatcher / RpcDispatcher: sync RPCs- * -ExpiryCache- * -LazyRemovalCache- * -TimeService- * -Discovery-: ping responses * -Table- * -TimeScheduler3- * -TimeScheduler2- (not changed; deprecated) * -HashedTimingWheel- (not changed; as unsupported) * -ConcurrentLinkedBlockingQueue- (not changed; not used anywhere) * -ResponseCollector- * -CreditMap- (only used for measuring block times) * FlowControl * Locking * -MERGE2- * -RELAY2- (no change; only used for stats) * -StatsCollector- * -RATE_LIMITER- * -PERF- > System.nanoTime() can be negative > --------------------------------- > > Key: JGRP-1877 > URL: https://issues.jboss.org/browse/JGRP-1877 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 3.5.1, 3.6 > > > According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future. > Code like the one below might fail: > {code:title=Responses.waitFor()|borderStyle=solid} > public boolean waitFor(long timeout) { > long wait_time; > final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns > lock.lock(); > try { > while(!done && (wait_time=target_time - System.nanoTime()) > 0) { > try { > cond.await(wait_time,TimeUnit.NANOSECONDS); > } > catch(InterruptedException e) { > } > } > return done; > } > finally { > lock.unlock(); > } > } > {code} > When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time. > Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JBASMP-72) enable --admin-only mode for start & run goals

by Matt Drees (JIRA)

[ https://issues.jboss.org/browse/JBASMP-72?page=com.atlassian.jira.plugin.... ] Matt Drees commented on JBASMP-72: ---------------------------------- Discussed with James yesterday. We'll add a <serverArgs> config option. > enable --admin-only mode for start & run goals > ---------------------------------------------- > > Key: JBASMP-72 > URL: https://issues.jboss.org/browse/JBASMP-72 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Reporter: Matt Drees > Assignee: Matt Drees > > It'd be handy to be able to start jboss AS in admin-only mode (https://access.redhat.com/solutions/341813). > One solution would be to add a <adminOnly>true</adminOnly> configuration option. > Another would to add a <jbossArgs> option (akin to <jvmArgs>), and I could then specify <jbossArgs>--admin-only</jbossArgs>. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JBASMP-72) enable --admin-only mode for start & run goals

by Matt Drees (JIRA)

[ https://issues.jboss.org/browse/JBASMP-72?page=com.atlassian.jira.plugin.... ] Matt Drees reassigned JBASMP-72: -------------------------------- Assignee: Matt Drees (was: James Perkins) > enable --admin-only mode for start & run goals > ---------------------------------------------- > > Key: JBASMP-72 > URL: https://issues.jboss.org/browse/JBASMP-72 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Reporter: Matt Drees > Assignee: Matt Drees > > It'd be handy to be able to start jboss AS in admin-only mode (https://access.redhat.com/solutions/341813). > One solution would be to add a <adminOnly>true</adminOnly> configuration option. > Another would to add a <jbossArgs> option (akin to <jvmArgs>), and I could then specify <jbossArgs>--admin-only</jbossArgs>. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014