[JBoss JIRA] (AS7-6257) AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6257:
-------------------------------------
Summary: AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION
Key: AS7-6257
URL: https://issues.jboss.org/browse/AS7-6257
Project: Application Server 7
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Fix For: 7.3.0.Alpha1
AttributeDefinition.validateOperation currently only converts a string to an expression if the attribute supports expressions. It should convert any time it sees the syntax. This way if a STRING attribute that doesn't support expressions finds one, it will reject it instead of accepting it as a raw string.
Scheduling for 7.3 out of concern this may break things in 7.2 without time to notice/adapt.
--
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, 4 months
[JBoss JIRA] (AS7-5311) Deployment of multiple .rar's with ironjacamar.xml
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-5311?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-5311:
--------------------------------------
it seems to me a regression on master (code rewritten for new DMR APIs). I've fixed it, but I'll open another issue for that.
It should not happen in 7.1.x
> Deployment of multiple .rar's with ironjacamar.xml
> --------------------------------------------------
>
> Key: AS7-5311
> URL: https://issues.jboss.org/browse/AS7-5311
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Priority: Critical
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in
> {noformat}
> 11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> {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
11 years, 4 months
[JBoss JIRA] (JGRP-1557) SUPERVISOR: protocol to check conditions and perform corrective actions if needed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1557?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1557.
----------------------------
Resolution: Done
> SUPERVISOR: protocol to check conditions and perform corrective actions if needed
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1557
> URL: https://issues.jboss.org/browse/JGRP-1557
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> SUPERVISOR is a protocol anywhere in the stack that passes messages up and down by default; it doesn't take part in message processing.
> However, it handles events ADD_RULE / REMOVE_RULE, which adds/removes rules. A rule is a condition with a name, an interval and an (optional) action.
> When the interval for a condition has elapsed, it is triggered and (if true) it'll invoke the associated action. A condition can be triggered by an interval elapsed or perhaps also when a event is received (e.g. a view change).
> Example:
> - Condition: check if FD is present in the stack. If it is and fd.isMonitorRunning() == false and fd.getView().size() > 1, then call action fd.startFailureDetection() and log an error message.
> The error messages are stored in a bounded list, so the last N error messages can be retrieved, e.g. via probe.sh.
> A rule should be able to be invoked manually, e.g. via probe.
> SUPERVISOR could be configured with a file which lists the rules to be created (class name, interval, description etc) at startup.
--
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, 4 months
[JBoss JIRA] (AS7-6256) Problem while accessing local interface using context.lookup
by Gaurav Gupta (JIRA)
Gaurav Gupta created AS7-6256:
---------------------------------
Summary: Problem while accessing local interface using context.lookup
Key: AS7-6256
URL: https://issues.jboss.org/browse/AS7-6256
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final
Reporter: Gaurav Gupta
Assignee: jaikiran pai
11:31:05,795 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/protectoria]] (MSC service thread 1-1) Exception sending context initialized event to listener instance of class no.messageman.protectoria.core.security.CacheResourceRoleMapping: java.lang.ClassCastException: no.messageman.protectoria.core.security.IRBAC$$$view18 cannot be cast to no.messageman.protectoria.core.security.IRBAC
--
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, 4 months
[JBoss JIRA] (AS7-6139) ModelTypeValidator is overly lenient about numeric types
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-6139?page=com.atlassian.jira.plugin.s... ]
Chao Wang updated AS7-6139:
---------------------------
Attachment: AS7-6139.patch
Is the patch file a suitable way to check the numeric type? Comparing two different types are equal in value
> ModelTypeValidator is overly lenient about numeric types
> --------------------------------------------------------
>
> Key: AS7-6139
> URL: https://issues.jboss.org/browse/AS7-6139
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Priority: Minor
> Attachments: AS7-6139.patch
>
>
> ModelTypeValidator does some conversion checks to see if a passed in ModelNode meets the requirements of the valid type. These checks are overly lenient when it comes to numeric types as they rely only on the ModelNode.asXXX() methods not failing. But those methods don't fail even if the conversion involves a narrowing.
> For example, calling new ModelNode(Long.MAX_LONG).asInt() will not fail, but if the user passed in such a value for use in an attribute of type INT the stored value would not be what was expected.
> Note this is minor as in many, many cases ModelTypeValidator subclasses like IntRangeValidator are used, and those subclasses enforce ranges.
--
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, 4 months
[JBoss JIRA] (AS7-5842) Upgrade to joda time 2.1
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5842?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-5842:
---------------------------------------
Please send an email about this to the jboss-as7-dev mailing list. This library is a dependency of a number of other AS dependencies, and the leads responsible for integrating those dependencies need to agree to this update. It is not a direct dependency of the AS itself.
Here are the modules that depend on the org.joda.time module:
build/src/main/resources/modules/org/apache/cxf/impl/main/module.xml: <module name="org.joda.time" />
build/src/main/resources/modules/org/apache/ws/security/main/module.xml: <module name="org.joda.time" />
build/src/main/resources/modules/org/codehaus/jackson/jackson-mapper-asl/main/module.xml: <module name="org.joda.time"/>
build/src/main/resources/modules/org/hibernate/validator/main/module.xml: <module name="org.joda.time"/>
build/src/main/resources/modules/org/opensaml/main/module.xml: <module name="org.joda.time"/>
> Upgrade to joda time 2.1
> ------------------------
>
> Key: AS7-5842
> URL: https://issues.jboss.org/browse/AS7-5842
> Project: Application Server 7
> Issue Type: Component Upgrade
> Affects Versions: 7.1.1.Final
> Environment: -
> Reporter: Wouter Oet
>
> JBoss AS 7.1.1 ships with Joda-time 1.6.2, however the newer version 2.1 is available and contains bugfixes and improvements.
--
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, 4 months
[JBoss JIRA] (AS7-6251) SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS defined incompatible ModelType and ParameterValidator
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6251?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6251:
---------------------------------------
The xs:nonNegativeInteger type is not limited to the upper range of a Java int.
http://books.xmlschemata.org/relaxng/ch19-77247.html
"The value space of xsd:nonNegativeInteger includes the set of all the integers greater than or equal to zero, with no restriction of range."
> SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS defined incompatible ModelType and ParameterValidator
> ----------------------------------------------------------------------------------------------------------
>
> Key: AS7-6251
> URL: https://issues.jboss.org/browse/AS7-6251
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> The SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS is defined :
> {code:title=org.jboss.as.connector.subsystems.common.pool.Constants.java|borderStyle=solid}
> public static final SimpleAttributeDefinition BACKGROUNDVALIDATIONMILLIS = new SimpleAttributeDefinition(BACKGROUNDVALIDATIONMILLIS_NAME, Validation.Tag.BACKGROUND_VALIDATION_MILLIS.getLocalName(), new ModelNode(), ModelType.LONG, true, true, MeasurementUnit.MILLISECONDS, new IntRangeValidator(1, true, true));
> {code}
> The ModelType should be an integer value as defined in jboss-as-datasources_1_1.xsd:
> {code:xml}
> <xs:element name="background-validation-millis" type="xs:nonNegativeInteger" minOccurs="0">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[[
> The background-validation-millis element specifies the amount of
> time, in millis, that background validation will run.
> ]]>
> </xs:documentation>
> </xs:annotation>
> </xs:element>
> {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
11 years, 4 months
[JBoss JIRA] (AS7-6254) Memory leak caused by retained connection ids in RemotingConnectorServer superclass
by Taras Tielkes (JIRA)
[ https://issues.jboss.org/browse/AS7-6254?page=com.atlassian.jira.plugin.s... ]
Taras Tielkes edited comment on AS7-6254 at 1/1/13 8:25 AM:
------------------------------------------------------------
Note that this issue is still present in 7.1.3 EAP.
Steps to reproduce:
# Install clean 7.1.3 JBoss instance
# Add JMX user using the provided admin script
# Run a client that repeatedly creates a JMX connection (using the {{service:jmx:remoting-jmx}} protocol, using the provided {{jboss-client.jar}} library)
After sufficient time, depending on the configured heap size, you'll see the JBoss server JVM run out of memory.
I have an {{hprof}} heap dump that shows the leak reproduced by the steps above. If you're interested in looking at that, let me know where to upload it.
was (Author: taras.tielkes):
Note that this issue is still present in 7.1.3 EAP.
Steps to reproduce:
1) Install clean 7.1.3 JBoss instance
2) Add JMX user using the provided admin script
3) Run a client that repeatedly creates a JMX connection (using the {{service:jmx:remoting-jmx}} protocol, using the provided {{jboss-client.jar}} library)
After sufficient time, depending on the configured heap size, you'll see the JBoss server JVM run out of memory.
I have an {{hprof}} heap dump that shows the leak reproduced by the steps above. If you're interested in looking at that, let me know where to upload it.
> Memory leak caused by retained connection ids in RemotingConnectorServer superclass
> ------------------------------------------------------------------------------------
>
> Key: AS7-6254
> URL: https://issues.jboss.org/browse/AS7-6254
> Project: Application Server 7
> Issue Type: Bug
> Components: JMX
> Affects Versions: 7.1.1.Final
> Reporter: Taras Tielkes
> Assignee: Stuart Douglas
>
> We're running 7.1.1, with a patch applied for REMJMX-45 to limit the worst leaks coming from the JMX subsystem.
> However, even with this patch applied we can only survive for a few days in a production-like scenario.
> It seems that {{org.jboss.remotingjmx.RemotingConnectorServer}} never calls the {{connectionClosed()}}/{{connectionFailed()}} methods in its superclass.
> As such, the connection ids that are stored in the field {{javax.management.remote.JMXConnectorServer#connectionIds}} are never released.
> Given sufficient connections made to a running instance of 7.1.1 (for example, various monitoring tools), an out-of-memory end-state is inevitable.
--
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, 4 months