July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1652) Add an entry point on the kie-server to deploy a DMN files as a service

by Duncan Doyle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1652?page=com.atlassian.jira.plugi... ] Duncan Doyle edited comment on DROOLS-1652 at 7/7/17 4:48 PM: -------------------------------------------------------------- What should the URL look like in your opinion [~tirelli]? From a RESTful point of view, we're creating a new kie-container resource, so in theory it should be a PUT (create resource) on URL"/server/container/\{id\}" that accepts a DMN file. However, that URL already exist. We could provide support for different request bodies in that operation (e.g. a `KieContainerResource` and a `DmnKieContainerResource`), but that could become a bit nasty ... We can also use a POST on something like "/server/containers/\{id\}/resources" and have that create a container resource under "/server/containers/\{id\}" (the reason I don't like a PUT in this case is because we create the resource (container) under a different URL than our request URL). The reason for the name "resources" (plural) is that we could provide multiple resources in the body (e.g. multiple DMN files). Second, apart from the DMN XML file (or files), do we also want to be able to post more information in the body (e.g. like additional information we pass in `KieContainerResource`)? And finally, should this be part of the DMN extension or KIE-Server Commons? The argument for DMN would be that otherwise we would expect Commons to have DMN knowledge. On the other hand, it's just deploying a KIE Containerner based on a resource file. The fact that that's a DMN model does not really matter (in theory this could be any resource file). Personally KIE-Server Commons makes most sense. was (Author: mccloud): What should the URL look like in your opinion [~tirelli]? From a RESTful point of view, we're creating a new kie-container resource, so in theory it should be a PUT (create resource) on URL"/server/container/\{id\}" that accepts a DMN file. However, that URL already exist. We could provide support for different request bodies in that operation (e.g. a `KieContainerResource` and a `DmnKieContainerResource`), but that could become a bit nasty ... We can also use a POST on something like "/server/containers/\{id\}/resources" and have that create a container resource under "/server/containers/\{id\}" (the reason I don't like a PUT in this case is because we create the resource (container) under a different URL that our request URL). The reason for the name "resources" (plural) is that we could provide multiple resources in the body (e.g. multiple DMN files). Second, apart from the DMN XML file (or files), do we also want to be able to post more information in the body (e.g. like additional information we pass in `KieContainerResource`)? And finally, should this be part of the DMN extension or KIE-Server Commons? The argument for DMN would be that otherwise we would expect Commons to have DMN knowledge. On the other hand, it's just deploying a KIE Containerner based on a resource file. The fact that that's a DMN model does not really matter (in theory this could be any resource file). Personally KIE-Server Commons makes most sense. > Add an entry point on the kie-server to deploy a DMN files as a service > ----------------------------------------------------------------------- > > Key: DROOLS-1652 > URL: https://issues.jboss.org/browse/DROOLS-1652 > Project: Drools > Issue Type: Feature Request > Components: dmn engine, kie server > Affects Versions: 7.1.0.Beta3 > Reporter: Edson Tirelli > Assignee: Duncan Doyle > > Add an end point on the kie-server to deploy a DMN xml file directly as a service without the need for a kjar. > In other words, the end point would accept a POST with a DMN xml file as a payload, it would internally build a kjar in memory and deploy it as a kie-container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1652) Add an entry point on the kie-server to deploy a DMN files as a service

by Duncan Doyle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1652?page=com.atlassian.jira.plugi... ] Duncan Doyle commented on DROOLS-1652: -------------------------------------- What should the URL look like in your opinion [~tirelli]? From a RESTful point of view, we're creating a new kie-container resource, so in theory it should be a PUT (create resource) on URL"/server/container/\{id\}" that accepts a DMN file. However, that URL already exist. We could provide support for different request bodies in that operation (e.g. a `KieContainerResource` and a `DmnKieContainerResource`), but that could become a bit nasty ... We can also use a POST on something like "/server/containers/\{id\}/resources" and have that create a container resource under "/server/containers/\{id\}" (the reason I don't like a PUT in this case is because we create the resource (container) under a different URL that our request URL). The reason for the name "resources" (plural) is that we could provide multiple resources in the body (e.g. multiple DMN files). Second, apart from the DMN XML file (or files), do we also want to be able to post more information in the body (e.g. like additional information we pass in `KieContainerResource`)? And finally, should this be part of the DMN extension or KIE-Server Commons? The argument for DMN would be that otherwise we would expect Commons to have DMN knowledge. On the other hand, it's just deploying a KIE Containerner based on a resource file. The fact that that's a DMN model does not really matter (in theory this could be any resource file). Personally KIE-Server Commons makes most sense. > Add an entry point on the kie-server to deploy a DMN files as a service > ----------------------------------------------------------------------- > > Key: DROOLS-1652 > URL: https://issues.jboss.org/browse/DROOLS-1652 > Project: Drools > Issue Type: Feature Request > Components: dmn engine, kie server > Affects Versions: 7.1.0.Beta3 > Reporter: Edson Tirelli > Assignee: Duncan Doyle > > Add an end point on the kie-server to deploy a DMN xml file directly as a service without the need for a kjar. > In other words, the end point would accept a POST with a DMN xml file as a payload, it would internally build a kjar in memory and deploy it as a kie-container. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3052) Unclear failure description when adding elytron policy resource

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3052?page=com.atlassian.jira.plugi... ] Jason Greene moved WFLY-9015 to WFCORE-3052: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3052 (was: WFLY-9015) Component/s: Security (was: Security) Affects Version/s: (was: 11.0.0.Alpha1) > Unclear failure description when adding elytron policy resource > --------------------------------------------------------------- > > Key: WFCORE-3052 > URL: https://issues.jboss.org/browse/WFCORE-3052 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Kašík > Assignee: Martin Stefanko > > When adding new Elytron policy resource, operation fails with [1]. In failure message there is missing "not" and for me, a user it is confusing since it says the policy provider which I am trying to add cannot be found... > [1] > {code} > [standalone@localhost:9990 /] /subsystem=elytron/policy=foo:add() > { > "outcome" => "failed", > "failure-description" => "Could find policy provider with name [foo]", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3051) default-policy attribute value of Elytron policy resource is reverted to original value after reload

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3051?page=com.atlassian.jira.plugi... ] Farah Juma moved JBEAP-12000 to WFCORE-3051: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3051 (was: JBEAP-12000) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.ER1) > default-policy attribute value of Elytron policy resource is reverted to original value after reload > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-3051 > URL: https://issues.jboss.org/browse/WFCORE-3051 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > > When setting {{default-policy}} attribute to a new value, it reverts back to default value '{{policy}}' after reload is performed on server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3050) Upgrade jboss-logmanager from 2.0.6.Final to 2.0.7.Final

by James Perkins (JIRA)

James Perkins created WFCORE-3050: ------------------------------------- Summary: Upgrade jboss-logmanager from 2.0.6.Final to 2.0.7.Final Key: WFCORE-3050 URL: https://issues.jboss.org/browse/WFCORE-3050 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade JBoss Log Manager from 2.0.6.Final to 2.0.7.Final. There are only a few [changes|https://github.com/jboss-logging/jboss-logmanager/compare/2.0.6.F...] however LOGMGR-163 may be important as log file rotations by month lose log messages. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9053) AbstractMethodError with Hibernate 5.2

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9053?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9053: ------------------------------------ Understood, thanks for checking. I asked in case there was more. > AbstractMethodError with Hibernate 5.2 > -------------------------------------- > > Key: WFLY-9053 > URL: https://issues.jboss.org/browse/WFLY-9053 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Alpha1 > Reporter: Giovanni Lovato > Assignee: Scott Marlow > > I'm deploying an EAR specifying in its {{persistence.xml}} to use Hibernate 5.2 as JPA provider: > {code:xml} > <property name="jboss.as.jpa.providerModule" value="org.hibernate:5.2" /> > {code} > Hibernate 5.2 modules are placed in the {{modules}} directory. > This configuration works in 10.1.0.Final but in 11.0.0.Alpha1 I get this error at deployment: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.unit."oss-application-ear-1.0.0.ear".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of deployment "oss-application-ear-1.0.0.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.AbstractMethodError: org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.beanManagerLifeCycle(Ljavax/enterprise/inject/spi/BeanManager;)Ljava/lang/Object; > at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.<init>(PhaseOnePersistenceUnitServiceImpl.java:89) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deployPersistenceUnitPhaseOne(PersistenceUnitServiceHandler.java:485) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:279) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleEarDeployment(PersistenceUnitServiceHandler.java:228) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135) > at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165) > ... 5 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned WFLY-442: ------------------------------------- Assignee: (was: Darran Lofthouse) > Review of AccessController and PrivilegedAction use across AS7 > -------------------------------------------------------------- > > Key: WFLY-442 > URL: https://issues.jboss.org/browse/WFLY-442 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Labels: investigation_required > > The following needs reviewing across AS7: - > - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable). > - Use of AccessController even though there is no SecurityManager set. > - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED > - Utility methods with visibility too high. > - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction. > - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated WFLY-442: ---------------------------------- Fix Version/s: (was: 11.0.0.Beta1) > Review of AccessController and PrivilegedAction use across AS7 > -------------------------------------------------------------- > > Key: WFLY-442 > URL: https://issues.jboss.org/browse/WFLY-442 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Labels: investigation_required > > The following needs reviewing across AS7: - > - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable). > - Use of AccessController even though there is no SecurityManager set. > - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED > - Utility methods with visibility too high. > - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction. > - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-379) Fix & re-enable ignored security tests

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-379?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned WFLY-379: ------------------------------------- Assignee: (was: Darran Lofthouse) > Fix & re-enable ignored security tests > -------------------------------------- > > Key: WFLY-379 > URL: https://issues.jboss.org/browse/WFLY-379 > Project: WildFly > Issue Type: Sub-task > Components: Security > Affects Versions: 8.0.0.Alpha1 > Environment: AS8 with undertow > Reporter: Tomaz Cerar > > AS8 with undertow fails few security tests. > This issue is here just for tracking what they are so they can be fixed > Still disabled tests: > {noformat} > SPNEGOLoginModuleTestCase > AdvancedLdapLoginModuleTestCase > StackingJASPITestCase > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-487) Verify audit implications and required APIs

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-487?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved WFLY-487. ----------------------------------- Resolution: Out of Date > Verify audit implications and required APIs > ------------------------------------------- > > Key: WFLY-487 > URL: https://issues.jboss.org/browse/WFLY-487 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 11.0.0.Beta1 > > > Auditing may be logging as the user that executes a request, if we have used a trust relationship for a request to be run as a different user we need to be able to track back to identify how the user for the request was selected. > i.e. If userA runs something as userB and does something bad we must be able to track back that it was userA making the overall request without userB getting the blame. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 July 2017