[JBoss JIRA] (WFLY-1477) JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
by Steve S (JIRA)
[ https://issues.jboss.org/browse/WFLY-1477?page=com.atlassian.jira.plugin.... ]
Steve S commented on WFLY-1477:
-------------------------------
[~rmaucher] can you provide more information on the official fix that went into the web subsystem? Thanks.
> JACC HttpServletRequestPolicyContextHandler removal on single application undeploy impacting all other deployed applications
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1477
> URL: https://issues.jboss.org/browse/WFLY-1477
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Alpha1
> Environment: CentOS 6.x, JBoss AS 7.1.1.Final
> Reporter: Steve S
> Assignee: Remy Maucherat
> Labels: domain, jaas, jboss, jbossweb, login, module, security
>
> Please see the following forum post for a detailed explanation and findings(and potential workaround):
> https://community.jboss.org/message/822054#822054
> If multiple WARs are deployed that depend on a login module leveraging:
> HttpServletRequest request = (HttpServletRequest)PolicyContext.getContext("javax.servlet.http.HttpServletRequest");
> then upon undeploy of any web application in the container the HttpServletRequestPolicyContextHandler is removed(deregistered) in the stop() lifecycle method of the JBossWebRealmService, resulting in:
> 13:03:35,335 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (ajp--0.0.0.0-8009-1) Login failure: javax.security.auth.login.LoginException: java.lang.IllegalArgumentException: No PolicyContextHandler for key=javax.servlet.http.HttpServletRequest at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:117)
> for any webapps still deployed for every subsequent access to them.
> Simply redeploying any ONE of the remaining webapps or the previously undeployed webapp causes this problem to go away for all deployed applications.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-2398) org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
by Jeff Zhang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2398?page=com.atlassian.jira.plugin.... ]
Jeff Zhang commented on WFLY-2398:
----------------------------------
I insert some log information into:
Set<String> ids = repository.getResourceAdapters(javax.jms.MessageListener.class);
assertNotNull(ids);
assertEquals(1, ids.size());
11:36:54,559 INFO [stdout] (pool-2-thread-1) $$$[org.jboss.as.test.smoke.deployment.rar.inflow.PureInflowResourceAdapter#1, org.hornetq.ra.HornetQResourceAdapter#1]
For full profile, the ids size should be 2 since it includes "HornetQResourceAdapter" also.
I think we need to modify the testcase to check if it is "web-profile" or "full-profile".
If you think this approach is fine, I will submit patch.
> org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase fails
> ------------------------------------------------------------------------
>
> Key: WFLY-2398
> URL: https://issues.jboss.org/browse/WFLY-2398
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA, Test Suite
> Affects Versions: 8.0.0.Beta1
> Environment: Solaris SPARC 10, Oracle Java 1.7.0_45
> Reporter: Frank Langelage
> Assignee: Jeff Zhang
> Attachments: org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase-output.txt, org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase.txt
>
>
> Running a build of current sources with complete testsuite this test is failing with
> testRegistryConfiguration(org.jboss.as.test.smoke.deployment.rar.tests.inflow.InflowTestCase): expected:<1> but was:<2>
--
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
10 years, 5 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-216?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-216.
-----------------------------------
Fix Version/s: 3.18.2-GA
3.19.0-GA
Resolution: Done
> A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
> ------------------------------------------------------------------------
>
> Key: JASSIST-216
> URL: https://issues.jboss.org/browse/JASSIST-216
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.18.2-GA, 3.19.0-GA
>
>
> (The original report is Maximilian Scherr.)
> When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
> protected void toString2(StringBuffer sbuf) {
> super.toString2(sbuf);
> sbuf.append(", incoming{");
> for (int i = 0; i < entrances.length; i++)
> sbuf.append(entrances[i].position).append(", ");
> sbuf.append("}");
> }
> It appears catcher blocks have a single predecessor (instead of 0) that is "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
10 years, 5 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-216?page=com.atlassian.jira.plugi... ]
Shigeru Chiba closed JASSIST-216.
---------------------------------
> A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
> ------------------------------------------------------------------------
>
> Key: JASSIST-216
> URL: https://issues.jboss.org/browse/JASSIST-216
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
> Fix For: 3.18.2-GA, 3.19.0-GA
>
>
> (The original report is Maximilian Scherr.)
> When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
> protected void toString2(StringBuffer sbuf) {
> super.toString2(sbuf);
> sbuf.append(", incoming{");
> for (int i = 0; i < entrances.length; i++)
> sbuf.append(entrances[i].position).append(", ");
> sbuf.append("}");
> }
> It appears catcher blocks have a single predecessor (instead of 0) that is "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
10 years, 5 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-216?page=com.atlassian.jira.plugi... ]
Shigeru Chiba updated JASSIST-216:
----------------------------------
Issue Type: Bug (was: Feature Request)
> A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
> ------------------------------------------------------------------------
>
> Key: JASSIST-216
> URL: https://issues.jboss.org/browse/JASSIST-216
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.1-GA
> Reporter: Shigeru Chiba
> Assignee: Shigeru Chiba
> Priority: Minor
>
> (The original report is Maximilian Scherr.)
> When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
> protected void toString2(StringBuffer sbuf) {
> super.toString2(sbuf);
> sbuf.append(", incoming{");
> for (int i = 0; i < entrances.length; i++)
> sbuf.append(entrances[i].position).append(", ");
> sbuf.append("}");
> }
> It appears catcher blocks have a single predecessor (instead of 0) that is "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
10 years, 5 months
[JBoss JIRA] (JASSIST-216) A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
by Shigeru Chiba (JIRA)
Shigeru Chiba created JASSIST-216:
-------------------------------------
Summary: A NullPointerException thrown in javassist.bytecode.analysis.ControlFlow
Key: JASSIST-216
URL: https://issues.jboss.org/browse/JASSIST-216
Project: Javassist
Issue Type: Feature Request
Affects Versions: 3.18.1-GA
Reporter: Shigeru Chiba
Assignee: Shigeru Chiba
Priority: Minor
(The original report is Maximilian Scherr.)
When analyzing a method with exception handler, printing the exception handler block caused a NullPointerException here (line 248):
protected void toString2(StringBuffer sbuf) {
super.toString2(sbuf);
sbuf.append(", incoming{");
for (int i = 0; i < entrances.length; i++)
sbuf.append(entrances[i].position).append(", ");
sbuf.append("}");
}
It appears catcher blocks have a single predecessor (instead of 0) that is "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
10 years, 5 months
[JBoss JIRA] (WFLY-671) Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.s... ]
Andre Dietisheim edited comment on WFLY-671 at 12/1/13 5:21 PM:
----------------------------------------------------------------
There's more complex oddity in there, it seems like tests behave differently when run at different hours. I currently have #testWithStartInTheFutureAndLaterSchedule running successfully but #testWithStartInThePast is now failing:
{code}
java.lang.AssertionError: Unexpected first schedule if start date is in the past, must be at 00:00 but is java.util.GregorianCalendar[time=1383264020304,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Africa/Abidjan",offset=0,dstSavings=0,useDaylight=false,transitions=3,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2013,MONTH=10,WEEK_OF_YEAR=44,WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=305,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=20,MILLISECOND=304,ZONE_OFFSET=0,DST_OFFSET=0]
{code}
was (Author: adietish):
There's more complex oddity in there, it seems like tests behave differently when run at different hours. I currently have #testWithStartInTheFutureAndLaterSchedule running successfully but #testWithStartInThePast is now failing.
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
> Key: WFLY-671
> URL: https://issues.jboss.org/browse/WFLY-671
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Carlo de Wolf
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests: testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-671) Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.s... ]
Andre Dietisheim commented on WFLY-671:
---------------------------------------
There's more complex oddity in there, it seems like tests behave differently when run at different hours. I currently have #testWithStartInTheFutureAndLaterSchedule running successfully but #testWithStartInThePast is now failing.
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
> Key: WFLY-671
> URL: https://issues.jboss.org/browse/WFLY-671
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Carlo de Wolf
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests: testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-671) Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/WFLY-671?page=com.atlassian.jira.plugin.s... ]
Andre Dietisheim edited comment on WFLY-671 at 12/1/13 5:15 PM:
----------------------------------------------------------------
in the latest wildfly I see CalendarBasedTimeoutTestCase#testWithStartInTheFutureAndLaterSchedule failing with
{code}
java.lang.AssertionError: Unexpected first schedule if start date is in the past, must be at 00:00 but is 1. 0:50
{code}
(notice the erroneous assertion text, which talks of start time in the past where it actually is in the future. I guess a simple copy/paste error when copying the similar assertion in #testWithStartInThePast)
was (Author: adietish):
in the latest wildfly I see CalendarBasedTimeoutTestCase#testWithStartInTheFutureAndLaterSchedule failing with
{code}
java.lang.AssertionError: Unexpected first schedule if start date is in the past, must be at 00:00 but is 1. 0:50
{code}
> Failure in CalendarUtilTestCase.testEveryMinuteEveryHourEveryDay
> ----------------------------------------------------------------
>
> Key: WFLY-671
> URL: https://issues.jboss.org/browse/WFLY-671
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Carlo de Wolf
> Priority: Minor
> Fix For: Awaiting Volunteers
>
>
> I'm unable to compile AS 7.
> {noformat}
> Failed tests: testEveryMinuteEveryHourEveryDay[379](org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase): Unexpected timeout value: java.util.GregorianCalendar[time=1314918060000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="Asia/Gaza",offset=7200000,dstSavings=3600000,useDaylight=true,transitions=144,lastRule=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=60000,startTimeMode=0,endMode=3,endMonth=8,endDay=1,endDayOfWeek=6,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2011,MONTH=8,WEEK_OF_YEAR=36,WEEK_OF_MONTH=1,DAY_OF_MONTH=2,DAY_OF_YEAR=245,DAY_OF_WEEK=6,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=1,HOUR_OF_DAY=1,MINUTE=1,SECOND=0,MILLISECOND=0,ZONE_OFFSET=7200000,DST_OFFSET=0] expected:<60000> but was:<3660000>
> {noformat}
--
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
10 years, 5 months
[JBoss JIRA] (JASSIST-213) jvmvrfy012 stack shape inconsistent
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-213?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-213:
---------------------------------------
Yes, because the internal compiler does not support the syntax of Java 5 or later.
> jvmvrfy012 stack shape inconsistent
> -----------------------------------
>
> Key: JASSIST-213
> URL: https://issues.jboss.org/browse/JASSIST-213
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA
> Reporter: Diego Correnti
> Assignee: Shigeru Chiba
> Priority: Critical
>
> I get jvmvrfy012 stack shape inconsistent from this code:
> String method ="public Object evaluate(Object owner){return owner.toString().length() <= 10;}";
> ClassPool pool = ClassPool.getDefault();
> CtClass newClass = pool.makeClass("MyExpression");
> newClass.setInterfaces(new CtClass[] {pool.get("magnum.commands.IExpression")});
> CtMethod newmethod = CtNewMethod.make(method,newClass);
> newClass.addMethod(newmethod);
> Class<?> cClass = newClass.toClass();
> Object snippet = cClass.newInstance();
> public interface IExpression<TypeIn,TypeOut>
> {
> TypeOut evaluate(TypeIn owner);
> }
> Caused by: java.lang.VerifyError: JVMVRFY012 forma stack non coerente; classe=MyExpression, metodo=evaluate(Ljava/lang/Object;)Ljava/lang/Object;, pc=17
> at java.lang.J9VMInternals.verifyImpl(Native Method)
> at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
> at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1325)
--
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
10 years, 5 months