December 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5321) support expressions for remote-destination-outbound-socket-binding host attrib

by John Mazzitelli (JIRA)

John Mazzitelli created AS7-5321: ------------------------------------ Summary: support expressions for remote-destination-outbound-socket-binding host attrib Key: AS7-5321 URL: https://issues.jboss.org/browse/AS7-5321 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.1.Final Reporter: John Mazzitelli I appears that remote-destination-outbound-socket-binding resources cannot have attributes that are expressions - at least the host attrtibute. In JBossAS 4.2.3, we used to have a stock email service.xml that people could customize by simply passing in new system properties (rather than editing .xml or going through a CLI to change the values). However, in AS 7.1.1.Final, we can't do this for the mail service because at least the host attribute does not appear to allow for expressions: /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp My host attribute was set to the expression ${rhq.server.email.smtp-host:localhost} and when I tried to start the server, I got: Caused by: java.net.UnknownHostException: ${rhq.server.email.smtp-host:localhost} at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) [rt.jar:1.6.0_29] at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) [rt.jar:1.6.0_29] at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1202) [rt.jar:1.6.0_29] at java.net.InetAddress.getAllByName0(InetAddress.java:1153) [rt.jar:1.6.0_29] at java.net.InetAddress.getAllByName(InetAddress.java:1083) [rt.jar:1.6.0_29] at java.net.InetAddress.getAllByName(InetAddress.java:1019) [rt.jar:1.6.0_29] at java.net.InetAddress.getByName(InetAddress.java:969) [rt.jar:1.6.0_29] at org.jboss.as.network.OutboundSocketBinding.getDestinationAddress(OutboundSocketBinding.java:146) at org.jboss.as.mail.extension.MailSessionService.getServerSocketAddress(MailSessionService.java:106) The weird thing is, the port attribute appears to allow for expressions. When my port is set to this expression: "${rhq.server.email.smtp-port:25}", the server starts up fine (that is, after I set to the host to a legitimate hostname like "localhost") This JIRA is to request that expressions be supported for the host attribute as it appears to be supported for the port attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

5
11
0 / 0

[JBoss JIRA] (AS7-5342) SAR MBean String attributes cannot be longer than about 3650 characters

by John Mazzitelli (JIRA)

John Mazzitelli created AS7-5342: ------------------------------------ Summary: SAR MBean String attributes cannot be longer than about 3650 characters Key: AS7-5342 URL: https://issues.jboss.org/browse/AS7-5342 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.1.Final Reporter: John Mazzitelli I have a SAR. One of the MBean attributes is a String (actually, for my real use-case the value is a Properties object, but due to JIRA AS7-5336, there are other problems, but let's just go with String attribute type, because the same problem I will describe happens with that type, too) If the string value is longer than around 3650 characters the beginning of the string is stripped (I can't nail it down to a specific value, but its around that number, give or take 10 characters or so) For example, if I have this in jboss-service.xml: <attribute name="MyStrAttrib"> This is a really long string. ...[lots of characters here]... It has more than 3650 characters in it. </attribute> What my MBean setter (setMyStrAttrib(String s)) will be passed is something like "aracters in it." The characters at index 0 through ~3650 are missing, I only have the parts after it. In my real example, the reason why the string is so long is that its a Properties string with lots of name/value pairs. I ended up working around AS7-5336 but then I hit this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

4
9
0 / 0

[JBoss JIRA] (AS7-6080) EJB 2.1 CMP configuration options missing

by Brad Maxwell (JIRA)

Brad Maxwell created AS7-6080: --------------------------------- Summary: EJB 2.1 CMP configuration options missing Key: AS7-6080 URL: https://issues.jboss.org/browse/AS7-6080 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.0.Alpha1, 7.1.3.Final (EAP) Reporter: Brad Maxwell Assignee: Stuart Douglas Fix For: Open To Community In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss. Should also confirm how to configure the rest of the options that were available previously. <container-configuration> <container-name>Clustered CMP 2.x EntityBean</container-name> <call-logging>false</call-logging> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name> <sync-on-commit-only>false</sync-on-commit-only> <insert-after-ejb-post-create>false</insert-after-ejb-post-create> <container-interceptors> ... </container-interceptors> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy> <container-cache-conf> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy> <cache-policy-conf> <min-capacity>50</min-capacity> <max-capacity>1000000</max-capacity> <overager-period>300</overager-period> <max-bean-age>600</max-bean-age> <resizer-period>400</resizer-period> <max-cache-miss-period>60</max-cache-miss-period> <min-cache-miss-period>1</min-cache-miss-period> <cache-load-factor>0.75</cache-load-factor> </cache-policy-conf> </container-cache-conf> <container-pool-conf> <MaximumSize>100</MaximumSize> </container-pool-conf> <commit-option>B</commit-option> </container-configuration> -- 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, 5 months

1
1
0 / 0

[JBoss JIRA] (AS7-6079) EJB 2.1 CMP configuration options missing

by Brad Maxwell (JIRA)

Brad Maxwell created AS7-6079: --------------------------------- Summary: EJB 2.1 CMP configuration options missing Key: AS7-6079 URL: https://issues.jboss.org/browse/AS7-6079 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.3.Final (EAP), 7.1.0.Alpha1 Reporter: Brad Maxwell Assignee: Stuart Douglas Fix For: Open To Community In JBoss AS 7, EJB 2.1 CMP beans cannot configure some options such as sync-on-commit-only and insert-after-ejb-post which were configurable in previous versions of JBoss. Should also confirm how to configure the rest of the options that were available previously. <container-configuration> <container-name>Clustered CMP 2.x EntityBean</container-name> <call-logging>false</call-logging> <invoker-proxy-binding-name>clustered-entity-rmi-invoker</invoker-proxy-binding-name> <sync-on-commit-only>false</sync-on-commit-only> <insert-after-ejb-post-create>false</insert-after-ejb-post-create> <container-interceptors> ... </container-interceptors> <instance-pool>org.jboss.ejb.plugins.EntityInstancePool</instance-pool> <instance-cache>org.jboss.ejb.plugins.EntityInstanceCache</instance-cache> <persistence-manager>org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager</persistence-manager> <locking-policy>org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock</locking-policy> <container-cache-conf> <cache-policy>org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy</cache-policy> <cache-policy-conf> <min-capacity>50</min-capacity> <max-capacity>1000000</max-capacity> <overager-period>300</overager-period> <max-bean-age>600</max-bean-age> <resizer-period>400</resizer-period> <max-cache-miss-period>60</max-cache-miss-period> <min-cache-miss-period>1</min-cache-miss-period> <cache-load-factor>0.75</cache-load-factor> </cache-policy-conf> </container-cache-conf> <container-pool-conf> <MaximumSize>100</MaximumSize> </container-pool-conf> <commit-option>B</commit-option> </container-configuration> -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-184) Javassist ProxyFactory does not handle interfaces with generics correctly.

by Eduardo Macarron (JIRA)

Eduardo Macarron created JASSIST-184: ---------------------------------------- Summary: Javassist ProxyFactory does not handle interfaces with generics correctly. Key: JASSIST-184 URL: https://issues.jboss.org/browse/JASSIST-184 Project: Javassist Issue Type: Bug Affects Versions: 3.17.0-GA Reporter: Eduardo Macarron Assignee: Shigeru Chiba We included the support for Javassit in MyBatis 3.2.0. We had an issue regarding generics. http://code.google.com/p/mybatis/issues/detail?id=664 We have isolated it and looks like this is a problem in Javassist. CGlib works fine in the same scenario. -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] (JBRULES-3700) Deadlock between AbstractWorkingMemory and DefaultAgenda in Fusion

by Winfried Umbrath (JIRA)

Winfried Umbrath created JBRULES-3700: ----------------------------------------- Summary: Deadlock between AbstractWorkingMemory and DefaultAgenda in Fusion Key: JBRULES-3700 URL: https://issues.jboss.org/browse/JBRULES-3700 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.5.0.Final Reporter: Winfried Umbrath Assignee: Mark Proctor I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur: 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820) acquires lock in AbstractWorkingMemory 2. [timer-thread] DefaultAgenda.fireActivation() call of synchronized method 3. [rule firing thread] DefaultAgenda.fireActivation() synchronized method, wait for other thread to exit synchornized method 4. [timer-thread] AbstractWorkingMemory.getGlobal() tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread --> Deadlock Excerpt from thread dump: "http-thread-pool-8082(374)": at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264) - waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679) at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234) at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102) at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32) at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155) at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76) at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821) "pool-4251-thread-1": at sun.misc.Unsafe.park(Native Method) - parking to wait for 0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634) at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda) at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344) - locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda) at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6078) Allow expressions in messaging subsystem

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-6078: -------------------------------- Summary: Allow expressions in messaging subsystem Key: AS7-6078 URL: https://issues.jboss.org/browse/AS7-6078 Project: Application Server 7 Issue Type: Feature Request Reporter: Jeff Mesnil Fix For: 7.2.0.Alpha1 allow expressions for attributes in the messaging subsystem unless it makes sense *not* to (eg attributes that represent references to other configuration items). -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (AS7-6038) Remove DeploymentScanner's bootTimeScan method

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-6038: ------------------------------------- Summary: Remove DeploymentScanner's bootTimeScan method Key: AS7-6038 URL: https://issues.jboss.org/browse/AS7-6038 Project: Application Server 7 Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Priority: Minor Fix For: 7.3.0.Alpha1 The DeploymentScanner interface's bootTimeScan method isn't implemented and isn't used and should be removed. -- 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, 5 months

2
4
0 / 0

[JBoss JIRA] (AS7-6077) :read-resource(recursive=true, include-defaults=true) - include-defaults=true does not get propagated to children

by Kabir Khan (JIRA)

Kabir Khan created AS7-6077: ------------------------------- Summary: :read-resource(recursive=true,include-defaults=true) - include-defaults=true does not get propagated to children Key: AS7-6077 URL: https://issues.jboss.org/browse/AS7-6077 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.3.Final (EAP), 7.1.2.Final (EAP) Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 7.2.0.Alpha1 -- 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, 5 months

1
2
0 / 0

[JBoss JIRA] (JBLOGGING-88) Support setting the logging provider via a resource file

by Jérôme Delagnes (JIRA)

Jérôme Delagnes created JBLOGGING-88: ---------------------------------------- Summary: Support setting the logging provider via a resource file Key: JBLOGGING-88 URL: https://issues.jboss.org/browse/JBLOGGING-88 Project: JBoss Logging Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.1.2.GA Reporter: Jérôme Delagnes Assignee: David Lloyd Logging provider can be set via the system property {{org.jboss.logging.provider}}. It could be nice if the provider could be also set via the resource {{META-INF/services/org.jboss.logging.provider}} or others. The algorithm used to locate the provider: # system property # resource file # existing logic -- 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, 5 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2012