[JBoss JIRA] (DROOLS-439) Package builder unable to find declared array class
by Mark Sullivan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-439?page=com.atlassian.jira.plugin... ]
Mark Sullivan commented on DROOLS-439:
--------------------------------------
Confirmed build with these changes has fixed this issue for my test cases. I'm now able to remove my workaround, thanks Davide.
> Package builder unable to find declared array class
> ---------------------------------------------------
>
> Key: DROOLS-439
> URL: https://issues.jboss.org/browse/DROOLS-439
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Mark Sullivan
> Assignee: Mark Proctor
>
> When declaring a fact type with an array field, where the array type is declared in the same package, for example:
> {code}
> declare Owner
> name : String
> end
> declare Pet
> owners : Owner[]
> end
> {code}
> The following build error occurs:
> {code}
> [Message [id=1, level=ERROR, path=pets.drl, line=5, column=0
> text=Unable to find class 'Owner']]
> {code}
> This error doesn't always occur when an array field is declared. It's dependent on the order in which each fact type is processed.
> PackageBuilder attempts to order fact types for processing based on the declared super type and attribute types.
> The following loop in *PackageBuilder.sortByHierarchy()* processes each field looking for field type dependencies:
> {code}
> for (TypeFieldDescr field : tdescr.getFields().values()) {
> QualifiedName typeName = new QualifiedName(field.getPattern().getObjectType());
> if (!hasCircularDependency(name, typeName, taxonomy)) {
> supers.add(typeName);
> }
> }
> {code}
> However I don't think it correctly spots the dependency when the field type is an array.
> This issue can be worked around by declaring an unused field of the same type as the array:
> {code}
> declare Owner
> name : String
> end
> declare Pet
> owners : Owner[]
> _unused: Owner
> end
> {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, 4 months
[JBoss JIRA] (WFLY-3008) System property substitution does not work in subnet-match
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-3008:
----------------------------------
Summary: System property substitution does not work in subnet-match
Key: WFLY-3008
URL: https://issues.jboss.org/browse/WFLY-3008
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Final
Reporter: Rich DiCroce
Specifying a system property in subnet-match when defining an interface causes an exception on startup. Example:
{code:xml}
<property name="subnet" value="192.168.0.0/16"/>
...
<interface name="public">
<subnet-match value="${subnet}"/>
</interface>
{code}
Causes:
{code}
12:36:13,457 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[311,46]
Message: JBAS014693: Invalid 'value' ${subnet} -- must be of the form address/mask
at org.jboss.as.server.parsing.CommonXml.validateAddressMask(CommonXml.java:605) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.CommonXml.parseSimpleInterfaceCriterion(CommonXml.java:587) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.CommonXml.parseInterfaceCriteria(CommonXml.java:467) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.CommonXml.parseInterfaces(CommonXml.java:644) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:465) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Final.jar:8.0.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Final.jar:8.0.0.Final]
... 3 more
{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, 4 months
[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1797:
--------------------------------
I added a msg to stdout in {{receive()}} as well, and it *is* called !
SHARED_LOOPBACK is not invoked because {{loopback}} is true, so multicasts are not going through the SHARED_LOOPBACK logic.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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, 4 months
[JBoss JIRA] (WFLY-2936) "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2936?page=com.atlassian.jira.plugin.... ]
Eduardo Martins reassigned WFLY-2936:
-------------------------------------
Assignee: Eduardo Martins
> "Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction" error in migrated seam 2.2.2 application
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2936
> URL: https://issues.jboss.org/browse/WFLY-2936
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64bit
> Java 1.7.0_51
> WildFly 8.0.0.Final
> JBoss Seam 2.2.2.Final
> Reporter: Dimitris Keramidas
> Assignee: Eduardo Martins
> Attachments: Auth.java, Authenticator.java, components.xml, jboss-deployment-structure.xml, server.log
>
>
> The error is fired when attempting to call a transaction-enabled EJB method, from a seam component. Specifically the authentication component.
> In order to get to this position, the project's deployment descriptors had to be migrated. Furthermore, mojarra version 1.2_15 was deployed to WildFly, as described by this link: https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature
> Please see attached logs and descriptors.
--
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, 4 months
[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1797:
-------------------------------------------
In the message handler for each channel (ReceiverPeer), add a line of code to indicate that the handler is called. When I run it, I never see any such messages, which indicates to me that the receiver is not getting called. I also instrumented SHARED_LOOPBACK with some logging - when the groups are being joined, there is traffic over the SHARED_LOOPBACK transport; when the test is going on and messages being sent, no traffic. The traffic resumes when the members leave the group.
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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, 4 months
[JBoss JIRA] (JGRP-1799) RpcDispatcher test fails when working with large values
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1799?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1799:
--------------------------------
Most likely the box on which the timeout occurs is loaded. No, the response value is not an exception, but null because we haven't received a response. Timeout exceptions are only thrown on unicast invocations.
> RpcDispatcher test fails when working with large values
> -------------------------------------------------------
>
> Key: JGRP-1799
> URL: https://issues.jboss.org/browse/JGRP-1799
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL, Win, Solaris
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> The two tests:
> * testLargeReturnValue
> * testLargeReturnValueUnicastCall
> make RPC calls with values which are increasingly large.
> The values used are in this range:
> {noformat}
> SIZES={10000, 20000, 40000, 80000, 100000, 200000, 400000, 800000,1000000, 2000000, 5000000}
> {noformat}
> The tests have been see to fail with the values 1000000, 2000000 and 5000000, always with the same error in each case.
> In the case of testLargeReturnValue, the test fails because one of the returned values from the RPC is null.
> In the case of testLargeReturnValueUnicastCall, the test fails due to a timeout while sending the RPC.
>
--
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, 4 months
[JBoss JIRA] (WFLY-3007) Ipv6 addresses may not be canonized properly
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-3007:
---------------------------------------
Summary: Ipv6 addresses may not be canonized properly
Key: WFLY-3007
URL: https://issues.jboss.org/browse/WFLY-3007
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
On an ipv6 environment we may obtain IP addresses that are not properly canonized which may lead to strange issue with http proxies since the JDK ProxySelector relies on char per char matching.
All call to InetAddress.getHostName() may produce such an uncanonized address.
--
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, 4 months
[JBoss JIRA] (JGRP-1797) NakackTest testReceptionOfAllMessages fails to receive all messages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1797?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1797:
--------------------------------
I streamlined (a.k.a. simplified) the test a bit, but it never fails for me. I don't follow you when you say the messages are never received... (?)
Pases 50+ times easily, not a single failure
> NakackTest testReceptionOfAllMessages fails to receive all messages
> -------------------------------------------------------------------
>
> Key: JGRP-1797
> URL: https://issues.jboss.org/browse/JGRP-1797
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL (5/24), Solaris (6/24), HPUX (1/2) where x/y means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
> Attachments: stdout.txt
>
>
> This test does the following:
> - involves channels A, B, and C where only B and C are senders and all are receivers
> - B and C send 1000 multicast messages
> - checks that all messages are received and in the correct order
> This test is failing intermittently but quite often.
--
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, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1795 at 2/24/14 11:41 AM:
---------------------------------------------------------------------
Running locally is no problem - but more often than not, the errors do not appear locally.
I'm currently running the testsuite on a RHEL5 machine in the QA lab and the tests passed; but this doesn't stop them from failing on other hosts :-)
I guess what I mean to say is that, with these particular issues, in the best case, I need to confirm that they have disappeared from all platforms.
was (Author: rachmato):
Running locally is no problem - but more often than not, the errors do not appear locally.
I'm currently running the testsuite on a RHEL5 machine in the QA lab and the tests passed; but this doesn't stop them from failing on other hosts :-)
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
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, 4 months