[JBoss JIRA] (DROOLS-11) ArrayIndexOutOfBoundsException when calling a method with more than two varargs parameters
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-11?page=com.atlassian.jira.plugin.... ]
Mario Fusco commented on DROOLS-11:
-----------------------------------
The fix is in mvel, not in drools. The only workaround I can suggest is wait for mvel-2.1.4.Final (I think I'll drop the new release tomorrow or next week at latest) end replace the version of mvel used by drools adding the new version to your pom file.
> ArrayIndexOutOfBoundsException when calling a method with more than two varargs parameters
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-11
> URL: https://issues.jboss.org/browse/DROOLS-11
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Andreas Bentele
> Assignee: Mario Fusco
> Fix For: 6.0.0.Alpha1
>
>
> I have a rule which uses a Java Interface ILogService with Varargs Parameter. When the rule is evaluated, an ArrayIndexOutOfBoundsException is thrown within MVEL2 code which evaluates the varargs parameters. The MVEL2 code works with two varargs parameters, but not with more than two varargs parameters.
> Drools Version: 5.5.0.Final
> {code}
> // Java Interface ILogService with varargs
> public interface ILogService {
> public void debug(String logMessage, Object... arg);
> ...
> }
> // Global definition ILogService
> global ILogService log;
> rule "..."
> ruleflow-group " ... "
> no-loop true
> salience 2
> when
> ...
> then
> log.debug("{} {} {}", operation.getOrderNumber(), operation.getOperationNumber(), Long.valueOf($operationId));
> end
> {code}
> * Breakpoint in org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.executeAll(Object, VariableResolverFactory, Method), Line 149:
> {code}
> for (int i = 0; i < vararg.length; i++) vararg[i] = parms[parms.length - length + i].getValue(ctx, vars);
> {code}
> * Debugging of this context:
> {code}
> vararg.length = 3
> parms.length = 4
> length = 2
> i = 0 => vararg[0] = parms[4-2+0].getValue(ctx, vars);
> i = 1 => vararg[1] = parms[4-2+1].getValue(ctx, vars);
> i = 2 => vararg[2] = parms[4-2+2].getValue(ctx, vars); => vararg[2] = parms[4].getValue(ctx, vars); => java.lang.ArrayIndexOutOfBoundsException: 4 (because params is an array of length 4 and maximum index 3.
> {code}
> Complete Stacktrace:
> {code}
> MethodAccessor.executeAll(Object, VariableResolverFactory, Method) line: 149
> MethodAccessor.getValue(Object, Object, VariableResolverFactory) line: 48
> VariableAccessor.getValue(Object, Object, VariableResolverFactory) line: 37
> ASTNode.getReducedValueAccelerated(Object, Object, VariableResolverFactory) line: 108
> MVELRuntime.execute(boolean, CompiledExpression, Object, VariableResolverFactory) line: 85
> CompiledExpression.getDirectValue(Object, VariableResolverFactory) line: 123
> CompiledExpression.getValue(Object, VariableResolverFactory) line: 119
> MVEL.executeExpression(Object, Object, VariableResolverFactory) line: 930
> MVELConsequence.evaluate(KnowledgeHelper, WorkingMemory) line: 104
> DefaultAgenda.fireActivation(Activation) line: 1287
> DefaultAgenda.fireNextItem(AgendaFilter) line: 1221
> DefaultAgenda.fireAllRules(AgendaFilter, int) line: 1456
> ReteooStatefulSession(AbstractWorkingMemory).fireAllRules(AgendaFilter, int) line: 710
> ReteooStatefulSession(AbstractWorkingMemory).fireAllRules() line: 674
> StatefulKnowledgeSessionImpl.fireAllRules() line: 230
> ...
> {code}
> I tried to create a simple test case to reproduce it, but the test case always worked - no Exception. but there was also another Stacktrace when stopping at a breakpoint in the LogService:
> {code}
> LogService.info(String, Object...) line: 60
> Rule_Hello_World_4df945f15bc043ef85d8e1317cd461f1.defaultConsequence(KnowledgeHelper, ILogService) line: 7
> Rule_Hello_World_4df945f15bc043ef85d8e1317cd461f1DefaultConsequenceInvokerGenerated.evaluate(KnowledgeHelper, WorkingMemory) line: not available
> Rule_Hello_World_4df945f15bc043ef85d8e1317cd461f1DefaultConsequenceInvoker.evaluate(KnowledgeHelper, WorkingMemory) line: not available
> DefaultAgenda.fireActivation(Activation) line: 1287
> DefaultAgenda.fireNextItem(AgendaFilter) line: 1221
> DefaultAgenda.fireAllRules(AgendaFilter, int) line: 1456
> {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, 2 months
[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
by Martin Keller (JIRA)
[ https://issues.jboss.org/browse/AS7-6419?page=com.atlassian.jira.plugin.s... ]
Martin Keller commented on AS7-6419:
------------------------------------
Hello Stefano,
We did some more tests with your proposed changes again, and it still did not work.
Also searching in the documentation did not help us.
Then we switched on more JBoss debug traces, but were not able to find the reason for the Validation exception.
We did upload the logfile to ftp://ftp.ts.fujitsu.com/outgoing/Jboss-server.31-01-2013.log.zip and did mark three lines with these labels:
PFA: Starting Deployment of HelloWorld.ear
PFA: Starting message driven bean HelloWorld
PFA: ERROR
We did expect to find some records beetween the "Starting message driven bean" and the "ERROR" mark that would help us.
We found a lot of "Finding class xxx" and corresponding "Class xxx not found" pairs but don not know if this could be the problem in the last few record before the "ERROR" mark.
Can You please help us ?
> Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-6419
> URL: https://issues.jboss.org/browse/AS7-6419
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.2.0.Alpha1
> Environment: Configuration:
> JDK-Version: 1.6.0_33
> Operating System: Windows 7 (32 Bit)
> JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012)
> JDK-Version: 1.6.0_33
> Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu)
> Reporter: Martin Keller
> Assignee: Stefano Maestri
>
> Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included.
> Starting an application using our JCA 1.6 resource adapter fails with
> java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment:
> GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12.
> Questions:
> What could be the cause for this exception?
> Can we switch off the validation?
> What is missing to run the validation successful?
> Details:
> The full stack is:
> 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> ... 7 more
> Caused by: javax.resource.ResourceException: IJ000852: Validation exception
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175)
> ... 8 more
> Caused by: javax.validation.ValidationException: Unable to find a default provider
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:]
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51)
> at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63)
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135)
> ... 9 more
--
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] (SECURITY-723) SPNEGO backport of additional Kerberos ticket decoding
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/SECURITY-723?page=com.atlassian.jira.plug... ]
Tom Fonteyne updated SECURITY-723:
----------------------------------
Steps to Reproduce:
- Use either a combination of Windows 2003 Active Directory and a Windows XP client, or Windows 2008 and a Vista/Windows7 client
- setup JBoss EAP 5.2.0 with SPNEGO pointed to the AD server.
- "host" security domain
- "SPNEGO" security domain
- a simple properties based setup for spnego roles, with (for example)
tom(a)JBOSSUK.REDHAT.COM=Users
- test with the SPNEGO toolkit that all 3 tests are working ok.
MORE TO COME
was:TO BE ADDED SOON
> SPNEGO backport of additional Kerberos ticket decoding
> ------------------------------------------------------
>
> Key: SECURITY-723
> URL: https://issues.jboss.org/browse/SECURITY-723
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_1_3
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
>
> /jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java
> is lacking additional decoding of the Kerberos ticket.
> This patch backports the missing code from trunk
> Testing: the standard unit test for remote EJB calls over SPNEGO.
--
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] (SECURITY-723) SPNEGO backport of additional Kerberos ticket decoding
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/SECURITY-723?page=com.atlassian.jira.plug... ]
Tom Fonteyne updated SECURITY-723:
----------------------------------
Security: Public (was: JBoss Internal)
Steps to Reproduce: TO BE ADDED SOON
Affects Version/s: Negotiation_2_1_3
Component/s: Negotiation
> SPNEGO backport of additional Kerberos ticket decoding
> ------------------------------------------------------
>
> Key: SECURITY-723
> URL: https://issues.jboss.org/browse/SECURITY-723
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_1_3
> Reporter: Tom Fonteyne
> Assignee: Tom Fonteyne
>
> /jboss-negotiation-spnego/src/main/java/org/jboss/security/negotiation/spnego/encoding/TokenParser.java
> is lacking additional decoding of the Kerberos ticket.
> This patch backports the missing code from trunk
> Testing: the standard unit test for remote EJB calls over SPNEGO.
--
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-6428) Using Session Scope CDI bean does not work in a HttpSessionListener
by nicolas marchais (JIRA)
[ https://issues.jboss.org/browse/AS7-6428?page=com.atlassian.jira.plugin.s... ]
nicolas marchais updated AS7-6428:
----------------------------------
Issue Type: Bug (was: Feature Request)
> Using Session Scope CDI bean does not work in a HttpSessionListener
> -------------------------------------------------------------------
>
> Key: AS7-6428
> URL: https://issues.jboss.org/browse/AS7-6428
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 7.1.1.Final
> Environment: linux 64bits, win7 64 bits
> Reporter: nicolas marchais
> Assignee: Stuart Douglas
> Fix For: No Release
>
>
> JBoss AS 7.1.x has a bug with using session bean scope in a HttpSessionListener.
> When i inject a session scope bean in a HttpSessionListener and i try to populate attribute in sessionCreated() method many HttpSession are created by JBoss AS. Is it normal the a web server create many Http session for the same request ?
> Normally, this behaviour should work. See : http://docs.jboss.org/cdi/api/1.1-PRD/javax/enterprise/context/SessionSco...
> I did a light Web Project to explain the problem with 1 JSP, 1 SessionScope bean and 1 HttpSessionListener.
> Here is the code.
> JSP page :
> <%@ page language="java" contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>Insert title here</title>
> </head>
> <body>
> </body>
> </html>
> SessionScope bean :
> @Named
> @SessionScoped
> public class UserState implements Serializable {
> private int state;
> public int getState() {
> return state;
> }
> public void setState(int state) {
> this.state = state;
> }
> }
> HttpSessionListener :
> @WebListener
> public class SessionListener implements HttpSessionListener {
> @Inject private UserState userState;
>
> @Override
> public void sessionCreated(HttpSessionEvent event) {
> System.out.println("New HTTP Session created : " + event.getSession().getId());
> userState.setState(2);
> }
> @Override
> public void sessionDestroyed(HttpSessionEvent event) {}
> }
> After execution, you can read in the console at least 2 http session creation like this :
> New HTTP Session created : zvlF6vGLP1AaXM-rzFU02wAJ.undefined
> New HTTP Session created : TlrmmA8Eu4v32SHDT0QBBZza.undefined
> The first session seams to be the one which is used by the client. There is one more problem : The polutated attributes of the session scope bean are ignored after HttpSessionListener execution. At the end all session scope attributes are null.
--
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-6428) Using Session Scope CDI bean does not work in a HttpSessionListener
by nicolas marchais (JIRA)
nicolas marchais created AS7-6428:
-------------------------------------
Summary: Using Session Scope CDI bean does not work in a HttpSessionListener
Key: AS7-6428
URL: https://issues.jboss.org/browse/AS7-6428
Project: Application Server 7
Issue Type: Feature Request
Components: CDI / Weld
Affects Versions: 7.1.1.Final
Environment: linux 64bits, win7 64 bits
Reporter: nicolas marchais
Assignee: Stuart Douglas
Fix For: No Release
JBoss AS 7.1.x has a bug with using session bean scope in a HttpSessionListener.
When i inject a session scope bean in a HttpSessionListener and i try to populate attribute in sessionCreated() method many HttpSession are created by JBoss AS. Is it normal the a web server create many Http session for the same request ?
Normally, this behaviour should work. See : http://docs.jboss.org/cdi/api/1.1-PRD/javax/enterprise/context/SessionSco...
I did a light Web Project to explain the problem with 1 JSP, 1 SessionScope bean and 1 HttpSessionListener.
Here is the code.
JSP page :
<%@ page language="java" contentType="text/html; charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Insert title here</title>
</head>
<body>
</body>
</html>
SessionScope bean :
@Named
@SessionScoped
public class UserState implements Serializable {
private int state;
public int getState() {
return state;
}
public void setState(int state) {
this.state = state;
}
}
HttpSessionListener :
@WebListener
public class SessionListener implements HttpSessionListener {
@Inject private UserState userState;
@Override
public void sessionCreated(HttpSessionEvent event) {
System.out.println("New HTTP Session created : " + event.getSession().getId());
userState.setState(2);
}
@Override
public void sessionDestroyed(HttpSessionEvent event) {}
}
After execution, you can read in the console at least 2 http session creation like this :
New HTTP Session created : zvlF6vGLP1AaXM-rzFU02wAJ.undefined
New HTTP Session created : TlrmmA8Eu4v32SHDT0QBBZza.undefined
The first session seams to be the one which is used by the client. There is one more problem : The polutated attributes of the session scope bean are ignored after HttpSessionListener execution. At the end all session scope attributes are null.
--
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-6334) Ensure there is expression testing, basic transformation testing and reject-expression transformation testing for all subsystems
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-6334?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar 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 [OK]
clustering/infinispan
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - PR https://github.com/jbossas/jboss-as/pull/3969
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail done - will send PR together with WS
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads - WIP Brian
transactions [OK]
web [OK]
webservices - almost done, problem with recursive discard transformation [tomaz]
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
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 [OK]
clustering/infinispan
cmp [OK]
configadmin [OK]
connector/datasource
connector/jca [OK]
connector/resource-adapter
deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
ee - PR https://github.com/jbossas/jboss-as/pull/3969
ejb3 [OK]
jacorb - Just a note: the 'security' attribute transformation is not tested
jaxr [OK]
jaxrs [OK] empty subsystem
jdr - [OK] empty subsystem
jmx [OK]
jpa [OK]
jsf [OK]
jsr77 [OK] empty subsystem
logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
mail
messaging [OK]
modcluster [OK]
naming [OK]
osgi [OK]
pojo [OK] empty subsystem
remoting - [OK]
sar [OK] empty subsystem
security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
threads - WIP Brian
transactions [OK]
web [OK]
webservices - WIP Kabir
weld [OK] empty subsystem
xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
> 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 [OK]
> clustering/infinispan
> cmp [OK]
> configadmin [OK]
> connector/datasource
> connector/jca [OK]
> connector/resource-adapter
> deployment-scanner - https://github.com/jbossas/jboss-as/pull/3970 this cannot be used in domain mode and gives an error when initializing the extension. I created a nicer error message.
> ee - PR https://github.com/jbossas/jboss-as/pull/3969
> ejb3 [OK]
> jacorb - Just a note: the 'security' attribute transformation is not tested
> jaxr [OK]
> jaxrs [OK] empty subsystem
> jdr - [OK] empty subsystem
> jmx [OK]
> jpa [OK]
> jsf [OK]
> jsr77 [OK] empty subsystem
> logging - PR sent https://github.com/jbossas/jboss-as/pull/3930
> mail done - will send PR together with WS
> messaging [OK]
> modcluster [OK]
> naming [OK]
> osgi [OK]
> pojo [OK] empty subsystem
> remoting - [OK]
> sar [OK] empty subsystem
> security [PR sent - https://github.com/jbossas/jboss-as/pull/3941 - needs more work as mentioned in https://issues.jboss.org/browse/AS7-6407]
> threads - WIP Brian
> transactions [OK]
> web [OK]
> webservices - almost done, problem with recursive discard transformation [tomaz]
> weld [OK] empty subsystem
> xts - [OK] susbystem model has not changed since 7.1.2 & 7.1.3
--
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