November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9454) SecurityContext not injected

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9454?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-9454. ------------------------------------ Assignee: Darran Lofthouse Resolution: Rejected Support for JSR-375 is being added under the following Jira issue: - https://issues.jboss.org/browse/WFLY-7186 At this stage it is not a bug that injection fails as we do not support JSR-375 in WildFly 11. > SecurityContext not injected > ---------------------------- > > Key: WFLY-9454 > URL: https://issues.jboss.org/browse/WFLY-9454 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 11.0.0.CR1 > Reporter: Mike Kachalov > Assignee: Darran Lofthouse > > 11:49:28,341 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."foo-1.0.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo-1.0.ear".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type SecurityContext with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject private com.foo.bar.facade.impl.UserRegisterFacadeImpl.securityContext > it's copy issue WELD-2437 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9557) Webservice subsystem requires an undertow dependency to get the Elytron security domain.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9557?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-9557: ---------------------------------------- One thought on this, we do associate the SecurityDomain with the ClassLoader of the deployment, maybe this would be an option to obtain the SecurityDomain that was already associated? {code:java} public static SecurityDomain getCurrent() { final SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(GET_SECURITY_DOMAIN); } final Thread currentThread = Thread.currentThread(); ClassLoader classLoader; if (sm != null) { classLoader = doPrivileged((PrivilegedAction<ClassLoader>) currentThread::getContextClassLoader); } else { classLoader = currentThread.getContextClassLoader(); } return classLoader != null ? CLASS_LOADER_DOMAIN_MAP.get(classLoader) : null; } {code} Or do you require it sooner? > Webservice subsystem requires an undertow dependency to get the Elytron security domain. > ---------------------------------------------------------------------------------------- > > Key: WFLY-9557 > URL: https://issues.jboss.org/browse/WFLY-9557 > Project: WildFly > Issue Type: Task > Components: Security, Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Jim Ma > Assignee: Darran Lofthouse > > Webservice subsystem requires an undertow's dependency(ApplicationSecurityDomainService or some Service) to get Elytron security domain to do webservice layer authentication. > From Darren, elytron security resource will be added in deploymentUnit after WF 11. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9561) HttpServletRequest.login(username, passoword) not creating HttpSession if it doesn't already exist. (Elytron)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-9561: ----------------------------------- Summary: HttpServletRequest.login(username, passoword) not creating HttpSession if it doesn't already exist. (Elytron) (was: WildFly - Elytron - Programmatic login) > HttpServletRequest.login(username, passoword) not creating HttpSession if it doesn't already exist. (Elytron) > ------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9561 > URL: https://issues.jboss.org/browse/WFLY-9561 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 11.0.0.Final > Reporter: Stanislav Grushevskiy > Assignee: Darran Lofthouse > Fix For: 12.0.0.Alpha1 > > Attachments: test.zip > > > If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID". > @Path("login") > public class LoginService { > @Context > private HttpServletRequest request; > @POST > public void login(LoginForm form) throws ServletException { > request.login(form.getLogin(), form.getPassword()); > } > } > <?xml version="1.0" encoding="UTF-8"?> > <jboss-web> > <security-domain>application-security-domain</security-domain> > </jboss-web> > If I add manual interaction with Session in login method, "JSESSIONID" is set. > OR > If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set. > "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used. > Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly". > Run "mvn wildfly:deploy". > Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth". > In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below () to use old "ApplicationRealm". -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove Data content if server is in --admin-only mode

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Tomas Hofman commented on WFCORE-1392: -------------------------------------- Test case PR: https://github.com/wildfly/wildfly/pull/10671 > Undeploy doesn't remove Data content if server is in --admin-only mode > ----------------------------------------------------------------------- > > Key: WFCORE-1392 > URL: https://issues.jboss.org/browse/WFCORE-1392 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Tomas Hofman > Priority: Minor > > {noformat} > Steps to Reproduce: > 1. Start server instance using --admin-only flag > 2. Deploy application using CLI command. > ~~~ > deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war > ~~~ > 3. Undeploy application using CLI command: > ~~~ > undeploy WebApp.war > ~~~ > 4. Application will be undeployed but content from 'data' directory are not removed. > {noformat} > Lines: > https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d... > https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9568) Test case for WFCORE-1392 - Undeploy doesn't remove Data content if server is in --admin-only mode

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-9568: ---------------------------------- Summary: Test case for WFCORE-1392 - Undeploy doesn't remove Data content if server is in --admin-only mode Key: WFLY-9568 URL: https://issues.jboss.org/browse/WFLY-9568 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Tomas Hofman Assignee: Tomas Hofman -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1392) Undeploy doesn't remove Data content if server is in --admin-only mode

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1392?page=com.atlassian.jira.plugi... ] Tomas Hofman commented on WFCORE-1392: -------------------------------------- Currently the sequence of actions during deployment is: {code} DeploymentAddHandler: create deployment resource contentRepository.addContent(...) or contentRepository.syncContent(...) if (ENABLED attr is true): DeploymentHandlerUtil.deploy(...) complete step: contentRepository.addContentReference(...) DeploymentDeployHandler: set ENABLED attr to true DeploymentHandlerUtil.deploy(...) DeploymentHandlerUtil.deploy(): if (is normal server): emit notification add RUNTIME step: create and install deployment and content services {code} During undeployment: {code} DeploymentUndeployHandler: if (ENABLED attr is true): DeploymentHandlerUtil.undeploy(...) DeploymentHandlerUtil.undeploy(): if (is normal server): emit notification add RUNTIME step: remove deployment and content services DeploymentRemoveHandler: remove deployment resource if (is normal server): add RUNTIME step: if (ENABLED attr is true): remove deployment and content services complete step: contentRepository.removeContent(...) {code} So the asynchronicity is in that content is added into content repository in both, normal and admin-only mode, but is removed from content repository only in normal mode. The modifications would be purely in DeploymentRemoveHandler: {code} DeploymentRemoveHandler: remove deploymetn resource if (is normal server): add RUNTIME step: if (ENABLED attr is true): remove deployment and content services complete step: contentRepository.removeContent(...) + else: + add RUNTIME step: + complete step: + contentRepository.removeContent(...) {code} DeploymentRemoveHandler is used in both, standalone and domain servers. Host controller in domain mode already removes the content during undeployment in both modes, so no changes are necessary there. > Undeploy doesn't remove Data content if server is in --admin-only mode > ----------------------------------------------------------------------- > > Key: WFCORE-1392 > URL: https://issues.jboss.org/browse/WFCORE-1392 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 2.1.0.CR2 > Reporter: Chao Wang > Assignee: Tomas Hofman > Priority: Minor > > {noformat} > Steps to Reproduce: > 1. Start server instance using --admin-only flag > 2. Deploy application using CLI command. > ~~~ > deploy /valid/path/WebApp.war --runtime-name=WebApp.war --name=WebApp.war > ~~~ > 3. Undeploy application using CLI command: > ~~~ > undeploy WebApp.war > ~~~ > 4. Application will be undeployed but content from 'data' directory are not removed. > {noformat} > Lines: > https://github.com/wildfly/wildfly-core/blob/b1a4439f442f7984e681840c0f8d... > https://github.com/wildfly/wildfly-core/blob/e737eff554ee433ca54835154fd6... > runningMode value is ADMIN_ONLY will bypass that step in DeploymentRemoveHandler.java leads to this behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2000) Test Scenario: Not possible to use a global

by Ephemeris Lappis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2000?page=com.atlassian.jira.plugi... ] Ephemeris Lappis commented on DROOLS-2000: ------------------------------------------ Hello. I'm testing the last 7.4.1.Final version for a new project, and the problem seems to persist. Any fix or workaround ? Thanks. Regards. > Test Scenario: Not possible to use a global > ------------------------------------------- > > Key: DROOLS-2000 > URL: https://issues.jboss.org/browse/DROOLS-2000 > Project: Drools > Issue Type: Bug > Components: Test Scenarios Editor > Reporter: Toni Rikkola > Assignee: Jozef Marko > Priority: Blocker > > Tried with two globals. One added into a DRL file and another added with menu New->Global Variable(s). > Neither of these two show up in the Test Scenario popup. Tried a full build, reopening the test scenario and even restarting the workbench. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2150) QuartzSchedulerService NullPointerException

by Csaba Házi (JIRA)

Csaba Házi created DROOLS-2150: ---------------------------------- Summary: QuartzSchedulerService NullPointerException Key: DROOLS-2150 URL: https://issues.jboss.org/browse/DROOLS-2150 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Environment: jBPM 6 and Quartz timer Reporter: Csaba Házi Assignee: Mario Fusco 2017-11-23 10:52:11,064 INFO [org.quartz.core.JobRunShell] (JbpmScheduler_Worker-4) Job jbpm.Timer-ExpireJobContext-6 threw a JobExecutionException: : org.quartz.JobExecutionException: Exception when executing scheduled job [See nested exception: java.lang.NullPointerException] at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:341) at org.quartz.core.JobRunShell.run(JobRunShell.java:216) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549) Caused by: java.lang.NullPointerException at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:401) at org.jbpm.process.core.timer.impl.QuartzSchedulerService$InmemoryTimerJobInstanceDelegate.call(QuartzSchedulerService.java:348) at org.jbpm.process.core.timer.impl.QuartzSchedulerService$QuartzJob.execute(QuartzSchedulerService.java:322) ... 2 more -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9566) Update EclipseLink module to add dependency on javax.json.api

by Lukas Jungmann (JIRA)

[ https://issues.jboss.org/browse/WFLY-9566?page=com.atlassian.jira.plugin.... ] Lukas Jungmann reassigned WFLY-9566: ------------------------------------ Assignee: Scott Marlow (was: Jason Greene) > Update EclipseLink module to add dependency on javax.json.api > ------------------------------------------------------------- > > Key: WFLY-9566 > URL: https://issues.jboss.org/browse/WFLY-9566 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Lukas Jungmann > Assignee: Scott Marlow > > MOXy part of EclipseLink does depend on javax.json APIs but these are not found if used -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9567) Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set

by Lukas Jungmann (JIRA)

Lukas Jungmann created WFLY-9567: ------------------------------------ Summary: Setting 'eclipselink.archive.factory' property should NOT depend on 'eclipselink.target-server' being set Key: WFLY-9567 URL: https://issues.jboss.org/browse/WFLY-9567 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Lukas Jungmann Assignee: Scott Marlow After applying patch from https://bugs.eclipse.org/bugs/show_bug.cgi?id=414974 on EclipseLink side and removing 'eclipselink.archive.factory' from WildFly's JVM options, 99,9% of tests started to fail on the server. Problem is that majority of our PU's do have set 'eclipselink.target-server' property (for various reasons) - in this case container as of[1] won't pass its 'eclipselink.archive.factory' to EclipseLink and deployments fail with: {noformat} [EL Severe]: 2017-11-23 13:14:31.974--ServerSession(1652754085)--Local Exception Stack: Exception [EclipseLink-28014] (Eclipse Persistence Services - 2.7.1.qualifier): org.eclipse.persistence.exceptions.EntityManagerSetupException Exception Description: Exception was thrown while processing property [eclipselink.descriptor.customizer.Project] with value [org.eclipse.persistence.testing.models.jpa.advanced.Customizer]. Internal Exception: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader] at org.eclipse.persistence.exceptions.EntityManagerSetupException.failedWhileProcessingProperty(EntityManagerSetupException.java:199) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2941) ... at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.ClassNotFoundException: Project from [Module "deployment.eclipselink-advanced-model.ear.eclipselink-advanced-model_ejb.jar" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:165) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClass(EntityManagerSetupImpl.java:1321) at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.processDescriptorCustomizers(EntityManagerSetupImpl.java:2938) ... 82 more {noformat} [1]: https://github.com/wildfly/wildfly/blob/a10034a/jpa/eclipselink/src/main/... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017