[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years