[JBoss JIRA] (AS7-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6334:
----------------------------------
Description:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups (PR #3886)
clustering/infinispan
cmp
configadmin
connector
deployment-scanner
ee
ee-deployment
ejb3
jacorb
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx (PR #3886)
jpa
jsf
jsr77 - nothing to do, empty subsystem
logging
mail
messaging - PR https://github.com/jbossas/jboss-as/pull/3887
modcluster
naming
osgi
pojo - nothing to do, empty subsystem
remoting - PR: https://github.com/jbossas/jboss-as/pull/3882
sar - nothing to do, empty subsystem
security
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts
was:
Task to track the work we've all been doing on expressions/transformers.
See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
2) Basic transformation testing against 7.1.2 and 7.1.3
3) Reject-expression testing against 7.1.2 and 7.1.3
Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
Please edit this description and put an OK after the subsystem name to indicate it's good to go.
clustering/jgroups
clustering/infinispan
cmp
configadmin
connector
deployment-scanner
ee
ee-deployment
ejb3
jacorb
jaxr OK
jaxrs - nothing to do, empty subsystem
jdr - nothing to do, empty subsystem
jmx
jpa
jsf
jsr77 - nothing to do, empty subsystem
logging
mail
messaging - PR https://github.com/jbossas/jboss-as/pull/3887
modcluster
naming
osgi
pojo - nothing to do, empty subsystem
remoting - PR: https://github.com/jbossas/jboss-as/pull/3882
sar - nothing to do, empty subsystem
security
threads
transactions (just needs AS7-6336)
web
webservices
weld - nothing to do, empty subsystem
xts
> Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6334
> URL: https://issues.jboss.org/browse/AS7-6334
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.2.0.Alpha1
>
>
> Task to track the work we've all been doing on expressions/transformers.
> See JaxrSubsystemTestCase for an example of what I'd like to see for each subsystem:
> 1) The standard subsystem test applied to a config that covers the full xsd with expressions added to each relevant attribute.
> 2) Basic transformation testing against 7.1.2 and 7.1.3
> 3) Reject-expression testing against 7.1.2 and 7.1.3
> Assigned to me but this is really a team effort, with a big chunk already done. Please use comments on this JIRA to indicate if you're looking at something.
> Please edit this description and put an OK after the subsystem name to indicate it's good to go.
> clustering/jgroups (PR #3886)
> clustering/infinispan
> cmp
> configadmin
> connector
> deployment-scanner
> ee
> ee-deployment
> ejb3
> jacorb
> jaxr OK
> jaxrs - nothing to do, empty subsystem
> jdr - nothing to do, empty subsystem
> jmx (PR #3886)
> jpa
> jsf
> jsr77 - nothing to do, empty subsystem
> logging
> mail
> messaging - PR https://github.com/jbossas/jboss-as/pull/3887
> modcluster
> naming
> osgi
> pojo - nothing to do, empty subsystem
> remoting - PR: https://github.com/jbossas/jboss-as/pull/3882
> sar - nothing to do, empty subsystem
> security
> threads
> transactions (just needs AS7-6336)
> web
> webservices
> weld - nothing to do, empty subsystem
> xts
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6319:
---------------------------------------
These tests are going to have @Ignore added to them. This should probably be scheduled for 7.2.0.Alpha1 though, unless it's clear that it's just a test problem and there is no actual regression.
> EJBEndpointAuthenticationTestCase is failing intermittently
> ------------------------------------------------------------
>
> Key: AS7-6319
> URL: https://issues.jboss.org/browse/AS7-6319
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.2.0.Alpha1
> Environment: AS7 upstream (Jan 11 2013)
> Reporter: jaikiran pai
> Assignee: Jim Ma
> Attachments: log.txt
>
>
> The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
> {code}
> java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
> {code}
> same goes also for PojoEndpointAuthenticationTestCase that fails sometimes
> {code}
> javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at $Proxy110.hello(Unknown Source)
> at org.jboss.as.test.integration.ws.authentication.PojoEndpointAuthenticationTestCase.accessHelloWithValidUser1(PojoEndpointAuthenticationTestCase.java:116)
> ...
> Caused by: java.net.SocketException: Socket Closed
> at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
> at java.net.Socket.getSoTimeout(Socket.java:1032)
> at sun.net.www.http.HttpClient.available(HttpClient.java:356)
> {code}
> It looks like the testcase expects a specific text in the exception cause.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated AS7-6319:
-----------------------------
Affects Version/s: 7.2.0.Alpha1
Description:
The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
{code}
java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
{code}
same goes also for PojoEndpointAuthenticationTestCase that fails sometimes
{code}
javax.xml.ws.WebServiceException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
at $Proxy110.hello(Unknown Source)
at org.jboss.as.test.integration.ws.authentication.PojoEndpointAuthenticationTestCase.accessHelloWithValidUser1(PojoEndpointAuthenticationTestCase.java:116)
...
Caused by: java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
at java.net.Socket.getSoTimeout(Socket.java:1032)
at sun.net.www.http.HttpClient.available(HttpClient.java:356)
{code}
It looks like the testcase expects a specific text in the exception cause.
was:
The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
{code}
java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
{code}
It looks like the testcase expects a specific text in the exception cause.
> EJBEndpointAuthenticationTestCase is failing intermittently
> ------------------------------------------------------------
>
> Key: AS7-6319
> URL: https://issues.jboss.org/browse/AS7-6319
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.2.0.Alpha1
> Environment: AS7 upstream (Jan 11 2013)
> Reporter: jaikiran pai
> Assignee: Jim Ma
> Attachments: log.txt
>
>
> The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
> {code}
> java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
> {code}
> same goes also for PojoEndpointAuthenticationTestCase that fails sometimes
> {code}
> javax.xml.ws.WebServiceException: Could not send Message.
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
> at $Proxy110.hello(Unknown Source)
> at org.jboss.as.test.integration.ws.authentication.PojoEndpointAuthenticationTestCase.accessHelloWithValidUser1(PojoEndpointAuthenticationTestCase.java:116)
> ...
> Caused by: java.net.SocketException: Socket Closed
> at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
> at java.net.Socket.getSoTimeout(Socket.java:1032)
> at sun.net.www.http.HttpClient.available(HttpClient.java:356)
> {code}
> It looks like the testcase expects a specific text in the exception cause.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6319) EJBEndpointAuthenticationTestCase is failing intermittently
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/AS7-6319?page=com.atlassian.jira.plugin.s... ]
Alessio Soldano updated AS7-6319:
---------------------------------
Assignee: Jim Ma (was: Alessio Soldano)
> EJBEndpointAuthenticationTestCase is failing intermittently
> ------------------------------------------------------------
>
> Key: AS7-6319
> URL: https://issues.jboss.org/browse/AS7-6319
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Environment: AS7 upstream (Jan 11 2013)
> Reporter: jaikiran pai
> Assignee: Jim Ma
> Attachments: log.txt
>
>
> The org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase has started failing intermittently but regularly on lightning. The failure shows messages like these:
> {code}
> java.lang.AssertionError: String 'not allowed' was expected in SocketException invoking http://127.0.0.1:8080/jaxws-authentication-ejb3/EJB3AuthService: Socket Closed
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.jboss.as.test.integration.ws.authentication.EJBEndpointAuthenticationTestCase.accessHelloForNoneWithValidRole3(EJBEndpointAuthenticationTestCase.java:352
> {code}
> It looks like the testcase expects a specific text in the exception cause.
--
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
13 years, 3 months
[JBoss JIRA] (JGRP-1564) TP: handling of message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1564:
---------------------------
Description:
When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
The unmarshalling shouldn't take long, so TP.receive() should return quickly.
This approach would allow us to send OOB messages in message batches, too (currently not allowed).
The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT etc.
Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
was:
When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message.
We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
The unmarshalling shouldn't take long, so TP.receive() should return quickly.
This approach would allow us to send OOB messages in message batches, too (currently not allowed).
The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST{2} / NAKACK{2}, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT etc.
Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
> TP: handling of message batches
> -------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT etc.
> Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
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
13 years, 3 months
[JBoss JIRA] (JGRP-1564) TP: handling of message batches
by Bela Ban (JIRA)
Bela Ban created JGRP-1564:
------------------------------
Summary: TP: handling of message batches
Key: JGRP-1564
URL: https://issues.jboss.org/browse/JGRP-1564
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3
When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message.
We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
The unmarshalling shouldn't take long, so TP.receive() should return quickly.
This approach would allow us to send OOB messages in message batches, too (currently not allowed).
The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST{2} / NAKACK{2}, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT etc.
Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
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
13 years, 3 months
[JBoss JIRA] (AS7-6120) Expand support for System Property substitution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6120?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6120:
----------------------------------
Attachment: (was: expressions.ods)
> Expand support for System Property substitution
> -----------------------------------------------
>
> Key: AS7-6120
> URL: https://issues.jboss.org/browse/AS7-6120
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Jimmy Wilson
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: eap-6.1-prd, rhq
> Fix For: 7.2.0.Alpha1
>
> Attachments: expressions.ods
>
>
> Audit the core AS and all subsystems shipped in the AS distribution for suport for expression in management resource attributes.
> The basic philosophy toward expressions in previous releases was to only push devs to add support if there was a clear important use case. Devs could choose to add support beyond that, but we wouldn't push that. This JIRA and PRODMGT-195 from which it is derived reflects a change in philosophy. Now the philosophy is to support expressions unless the dev foresees a technical or future compatibility problem arising from doing so.
> This task DOES NOT advocate adding expression support to attributes that represent references to other model elements. Such references may prove problematic in the future and should not be added. We already have some model ref attributes that support expressions; this task DOES NOT advocate removing such support, unless the support has never been provided in a Final release (i.e. it was added during 7.2 development.)
--
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
13 years, 3 months