[JBoss JIRA] (AS7-6432) Incorrect evaluation of sytem property for expression substitution
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-6432:
-------------------------------------
Summary: Incorrect evaluation of sytem property for expression substitution
Key: AS7-6432
URL: https://issues.jboss.org/browse/AS7-6432
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.2.0.Alpha1
Reporter: Ondřej Chaloupka
Assignee: Brian Stansberry
Finally I think that I've got a way how to resolve expressions on VM where container resides.
My test case:
https://github.com/ochaloup/jboss-as/blob/expression-substitution-run-in-...
>From this I've found issues for system property evaluation. I mean the case when System.getProperty(someName) is called.
The application should get the evaluated value from expression but instead of it it gets the default value from expression.
The problematic test cases are
testSystemPropertyEvaluation - there is defined system property by calling System.setProperty and it's expected that the expression which uses this defined property will evaluate itself to the value of the System.setProperty. For the way of :resolve-expression it works fine but for getting value with System.getProperty the old default value is returned.
setInnerExpression - it defines two levels of evaluation of expression and it seems that then the System.getProperty on the second level of evaluation does not get the evaluated/substituted value
I hope that the test code will be more comprehensible than my explanation.
--
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, 2 months
[JBoss JIRA] (AS7-5172) cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/AS7-5172?page=com.atlassian.jira.plugin.s... ]
Ondřej Chaloupka reopened AS7-5172:
-----------------------------------
I've hit this issue again. It seems that the fix does not fixes the problem. I need to add the org.jboss.msc.service.ServiceActivator to WEB-INF/classes/META-INF. The container does not activate the service when I put the file just to META-INF folder.
My test case could be found here:
https://github.com/ochaloup/jboss-as/blob/expression-substitution-run-in-...
> cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF
> ----------------------------------------------------------------------------------------
>
> Key: AS7-5172
> URL: https://issues.jboss.org/browse/AS7-5172
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.1.Final
> Reporter: John Mazzitelli
> Assignee: James Livingston
> Priority: Minor
> Fix For: 7.2.0.Alpha1
>
> Attachments: AS7-5172-fix.diff, AS7-5172-testcase.diff, ManagementService.java
>
>
> (note: I talked to dmlloyed on this in #jboss-as7 - he thinks its a bug, hence why I am filing this JIRA)
> I have a WAR. I want it to have a service activator in it (I want it to install an MSC service). So, in the WAR's META-INF directory, I create a "services/org.jboss.msc.service.ServiceActivator" file with the appropriate content.
> The service fails to activate.
> However, if I put that same META-INF content in my WAR's WEB-INF/classes directory (that is, my WAR has a WEB-INF/classes/META-INF/services/org.jboss.msc.service.ServiceActivator), my service activates fine.
> I will attach a .war file that you can use to test this. To see what I'm taking about, take the attached war and explode it inside the standalone/deployments directory in AS 7.1.1.Final. Run the app server - you will see in the output this:
> INFO [stdout] (MSC service thread 1-5) $$$$$$$$$$$$$$$$ SERVICE ACTIVATING!
> (this output comes from my ServiceActivator's activate() method - it does a System.out.println as soon as activate() is entered).
> This shows the WEB-INF/classes/META-INF/services being honored. Now shutdown the app server, cd to the deployments directory and cd down into the exploded war directory. Now move that services/ content directly up to the WAR's own META-INF directory:
> mv WEB-INF/classes/META-INF/services META-INF/
> Now run the app server again. Notice you do NOT see the "SERVICE ACTIVATING" message.
> So it appears the WAR's META-INF/services is ignored when looking for service activators, but when the same services marker file is in WEB-INF/classes/META-INF/services, it works fine.
--
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, 2 months
[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6431?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved AS7-6431.
-----------------------------------
Resolution: Won't Fix
This is not a bug, it's a request for an enhancement. It's reasonable to define one property before attempting to use it, and the ordering in the xml reflects the order of operations.
I'm resolving this as Won't Fix because even trying to support this would result in pretty major code changes. And then it still wouldn't work unless both properties were added in a composite/batch operation.
> Incorrectly evaluated expression when property is defined after the expression in xml
> -------------------------------------------------------------------------------------
>
> Key: AS7-6431
> URL: https://issues.jboss.org/browse/AS7-6431
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> There is problem in evaluation of expression in case that property for evaluation is defined after the expression.
> In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine.
> When you define system properties in xml like:
> {code}
> <system-properties>
> <property name="qa.test.property" value="${qa.test.exp:defaultValue}"/>
> <property name="qa.test.exp" value="expression.value"/>
> </system-properties>
> {code}
> you start the container and then you can check the expression evaluation in jboss-cli.sh with command:
> {code}
> :resolve-expression(expression="${qa.test.property}")
> {code}
> The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined.
> When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value).
--
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, 2 months
[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/AS7-6431?page=com.atlassian.jira.plugin.s... ]
Ondřej Chaloupka commented on AS7-6431:
---------------------------------------
Ok, new observation. The DMR operation (/system-property=qa.test.exp:add(value=expression.value)) depends on order of definition in the same way as the xml. So the substitution does not work well then.
> Incorrectly evaluated expression when property is defined after the expression in xml
> -------------------------------------------------------------------------------------
>
> Key: AS7-6431
> URL: https://issues.jboss.org/browse/AS7-6431
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> There is problem in evaluation of expression in case that property for evaluation is defined after the expression.
> In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine.
> When you define system properties in xml like:
> {code}
> <system-properties>
> <property name="qa.test.property" value="${qa.test.exp:defaultValue}"/>
> <property name="qa.test.exp" value="expression.value"/>
> </system-properties>
> {code}
> you start the container and then you can check the expression evaluation in jboss-cli.sh with command:
> {code}
> :resolve-expression(expression="${qa.test.property}")
> {code}
> The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined.
> When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value).
--
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, 2 months
[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6431?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6431:
----------------------------------
Component/s: Domain Management
(was: Console)
> Incorrectly evaluated expression when property is defined after the expression in xml
> -------------------------------------------------------------------------------------
>
> Key: AS7-6431
> URL: https://issues.jboss.org/browse/AS7-6431
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.2.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Brian Stansberry
>
> There is problem in evaluation of expression in case that property for evaluation is defined after the expression.
> In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine.
> When you define system properties in xml like:
> {code}
> <system-properties>
> <property name="qa.test.property" value="${qa.test.exp:defaultValue}"/>
> <property name="qa.test.exp" value="expression.value"/>
> </system-properties>
> {code}
> you start the container and then you can check the expression evaluation in jboss-cli.sh with command:
> {code}
> :resolve-expression(expression="${qa.test.property}")
> {code}
> The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined.
> When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value).
--
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, 2 months
[JBoss JIRA] (AS7-6431) Incorrectly evaluated expression when property is defined after the expression in xml
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created AS7-6431:
-------------------------------------
Summary: Incorrectly evaluated expression when property is defined after the expression in xml
Key: AS7-6431
URL: https://issues.jboss.org/browse/AS7-6431
Project: Application Server 7
Issue Type: Bug
Components: Console
Affects Versions: 7.2.0.Alpha1
Reporter: Ondřej Chaloupka
Assignee: Brian Stansberry
There is problem in evaluation of expression in case that property for evaluation is defined after the expression.
In case of using DMR the order of property and expression definition is not taken in consideration and substitution works fine.
When you define system properties in xml like:
{code}
<system-properties>
<property name="qa.test.property" value="${qa.test.exp:defaultValue}"/>
<property name="qa.test.exp" value="expression.value"/>
</system-properties>
{code}
you start the container and then you can check the expression evaluation in jboss-cli.sh with command:
{code}
:resolve-expression(expression="${qa.test.property}")
{code}
The expression will be evaluated as "defaultValue" what is not correct because the "qa.test.exp" is defined.
When you switch definitions of properties (switch <property> tags) then the expression will be evaluated correctly (as "expression.value).
--
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, 2 months
[JBoss JIRA] (JGRP-1577) UNICAST / UNICAST2: add better synchronization around ReceiverEntries
by Bela Ban (JIRA)
Bela Ban created JGRP-1577:
------------------------------
Summary: UNICAST / UNICAST2: add better synchronization around ReceiverEntries
Key: JGRP-1577
URL: https://issues.jboss.org/browse/JGRP-1577
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When A gets unicast messages from B, then A creates a ReceiverEntry in its recv_table for B. The creation (or fetching of the existing ReceiverEntry) is done under a lock, however, the adding and subsequent removal of messages is not done under a lock (well, actually, adding messages to ReceiverEntry.win is locked).
What could happen is the following:
* B sends messages 1,2,3 (conn-id=5)
* B closes the connection to A
* B sends messages 1,2,3 to A (new conn-id=6)
* A receives messages 1,2,3 with conn-id=5
* A grabs the ReceiverEntry for B and starts adding 1,2,3 to win
* Messages 1-3 from B with conn-id=6 are received
* This creates a new ReceiverEntry for B
* A now starts removing and passing up messages 1-3 from B with the old conn-id 5
* A receives messages 1-3 from B with conn-id=5
* Subsequently, A also receives messages 1-3 from B with conn-id=6
Not sure if this really constitutes a bug, but I nevertheless need to take a look.
Possible solution:
* Create receiverEntry for B only *once*
* Remove ReceiverEntry for B only when the view excludes B, but *not* when B sends messages with a different conn-id
* Instead, lock on the ReceiverEntry for B when messages are received:
** When a message with a different conn-id is received, only change the contents of ReceiverEntry (e.g. conn-id, reset win etc), but *don't* remove the ReceiverEntry from recv_table and create a new one
--
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, 2 months
[JBoss JIRA] (JBJCA-722) Too eager shutdown of pools through idle timeout
by Alexander Vinnik (JIRA)
[ https://issues.jboss.org/browse/JBJCA-722?page=com.atlassian.jira.plugin.... ]
Alexander Vinnik commented on JBJCA-722:
----------------------------------------
We are experiencing this problem in JBoss 6.1. The workaround is not working for us: The pool is not closed now, but when a 3rd party application is trying to access the idle connection, it fails. Is it possible to make a patch addressing this problem in 6.1?
> Too eager shutdown of pools through idle timeout
> ------------------------------------------------
>
> Key: JBJCA-722
> URL: https://issues.jboss.org/browse/JBJCA-722
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.6.Final, 1.1.0.Alpha4
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Critical
> Fix For: 1.0.7.Final, 1.1.0.Alpha5
>
>
> In order to cleanup pools with a sparse Subject/CRI coverage we shutdown the pool if it is empty.
> However, there is no reason to do so if it is the only pool available. Furthermore we should always try and allocate a connection in order to kick the allocation mechanism into effect.
--
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, 2 months