[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on WFLY-3189:
-----------------------------------
Hi Michael:
In order to get these schema accepted into my jbt repo, I first need to get these changes accepted by the repos that hold the original files. So I'm working on that. For now, can you tell me where you got jboss-ejb-clustering_1_0.xsd from?
I've searched my entire list of existing jboss runtimes, from 3.2 through wildfly, as well as the codebases for wildfly and jboss metadata, and can't find any reference to this file at all.
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
> Attachments: p.patch
>
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[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 5:17 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* TimeScheduler3
* -Util.sleep-
* ConcurrentLinkedBlockingQueue
* -ResponseCollector-
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
* -Util.sleep-
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
[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 4:59 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* TimeScheduler3
* -Util.sleep-
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
* Util.sleep
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
[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 4:58 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* -Table-
* TimeScheduler3
* Util.sleep
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
* Util.sleep
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* 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
[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 4:55 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
* Table
* TimeScheduler3
* Util.sleep
* ConcurrentLinkedBlockingQueue
* ResponseCollector
* CreditMap
* FlowControl
* Locking
* MERGE2
* RELAY2
* StatsCollector
* RATE_LIMITER
* PERF
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
> 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
[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 4:08 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* -Discovery-: ping responses
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* Discovery: ping responses
> 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
[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 3:57 AM:
---------------------------------------------------------
Investigate:
* -Responses-
* -Promise-
* -Request (UnicastRequest, GroupRequest)-
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* -LazyRemovalCache-
* -TimeService-
* Discovery: ping responses
was (Author: belaban):
Investigate:
* -Responses-
* -Promise-
* _Request (UnicastRequest, GroupRequest)_
* -MessageDispatcher / RpcDispatcher: sync RPCs-
* -ExpiryCache-
* LazyRemovalCache
* -TimeService-
* Discovery: ping responses
> 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