[JBoss JIRA] (WFLY-7558) Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7558?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-7558:
-----------------------------------
Component/s: (was: Server)
> Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7558
> URL: https://issues.jboss.org/browse/WFLY-7558
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 10.1.0.Final
> Environment: OS X client, wildfly domain is running on CentOS 7
> Reporter: Jeff Scott
> Assignee: Jason Greene
>
> This is a two step problem. If an ear has been uploaded and configured to use a different runtime name that works and the domain uses the correct runtime name.
> If I replace the ear it doesn't have an input box to choose a new runtime name- yet it defaults the new runtime name to the filename that's being used to replace the deployment.
> I tried to workaround this by renaming my ear to the runtime name and using that to replace the existing deployment but that gives this exception:
> Cannot upload deployment: {"domain-failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"otherName.ear\")]' not found"}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2146) Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2146?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2146:
----------------------------------------
Component/s: Security
Assignee: Darran Lofthouse (was: Jason Greene)
> Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2146
> URL: https://issues.jboss.org/browse/WFCORE-2146
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Environment: CentOS release 6.8 (Final)
> JBoss Admin Command-line Interface
> JBOSS_HOME: /opt/wildfly/10.1.0
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: null
> java.version: 1.8.0_40
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.40-b25
> os.name: Linux
> os.version: 4.6.3-1.el6.elrepo.x86_64
> Reporter: Daniel Draper
> Assignee: Darran Lofthouse
>
> When hooking up our Wildfly Application to our SSO (CAS) for authentication and delegating Authorization to a Security Realm and then using LDAP we ran into the following problem:
> *Use Case*
> We want to use authorization inside a Security-Realm through LDAP.
> In our LDAP setup we have a Group-To-Principal matching of the form "_member=uid=x" OR "submember=uid=x_" depending on if the user was added manually or through an autodomain.
> Unfortunately as far as we could tell using two attributes in the Polish Notation (as is required by [LDAP|https://ldapwiki.com/wiki/LDAP%20filters%20Syntax%20and%20Choices]) seems to be impossible for the wildfly configuration. We tried the following in the standalone-accounting.xml (in different iterations and ways to place the parenthesis) which all lead to an 'unbalanced Parenthesis' or similar error when starting up wildfly.
> {code:xml}
> <management>
> <security-realms>
> <security-realm name="bla">
> <authorization>
> <ldap connection="ldap">
> <username-to-dn>
> <username-is-dn/>
> </username-to-dn>
> <group-search group-name="SIMPLE" iterative="false" group-dn-attribute="cn" group-name-attribute="cn">
> <group-to-principal search-by="SIMPLE" base-dn="ou=roles,***" recursive="false">
> <membership-filter principal-attribute="|(submember=uid={0})(member=uid={0})"/>
> </group-to-principal>
> </group-search>
> </ldap>
> </authorization>
> </security-realm>
> </security-realms>
> </management>
> {code}
> We then found the filterString is parsed the following way: (See [LdapGroupSearcherFactory#L115|https://github.com/wildfly/wildfly-core/blo...])
> {code:java}
> this.filterString = String.format("(%s={0})", principalAttribute);
> {code}
> which seems to make multiple attribute names as a filter impossible, which makes our use case as above impossible.
> Asked in [Forums|https://developer.jboss.org/thread/273435], but since I didn't get any answers for 3 weeks opening here.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2146) Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2146?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7842 to WFCORE-2146:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-2146 (was: WFLY-7842)
> Security-Realm Authorization over LDAP doesn't permit multiple Attribute names as filter.
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-2146
> URL: https://issues.jboss.org/browse/WFCORE-2146
> Project: WildFly Core
> Issue Type: Bug
> Environment: CentOS release 6.8 (Final)
> JBoss Admin Command-line Interface
> JBOSS_HOME: /opt/wildfly/10.1.0
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: null
> java.version: 1.8.0_40
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.40-b25
> os.name: Linux
> os.version: 4.6.3-1.el6.elrepo.x86_64
> Reporter: Daniel Draper
> Assignee: Jason Greene
>
> When hooking up our Wildfly Application to our SSO (CAS) for authentication and delegating Authorization to a Security Realm and then using LDAP we ran into the following problem:
> *Use Case*
> We want to use authorization inside a Security-Realm through LDAP.
> In our LDAP setup we have a Group-To-Principal matching of the form "_member=uid=x" OR "submember=uid=x_" depending on if the user was added manually or through an autodomain.
> Unfortunately as far as we could tell using two attributes in the Polish Notation (as is required by [LDAP|https://ldapwiki.com/wiki/LDAP%20filters%20Syntax%20and%20Choices]) seems to be impossible for the wildfly configuration. We tried the following in the standalone-accounting.xml (in different iterations and ways to place the parenthesis) which all lead to an 'unbalanced Parenthesis' or similar error when starting up wildfly.
> {code:xml}
> <management>
> <security-realms>
> <security-realm name="bla">
> <authorization>
> <ldap connection="ldap">
> <username-to-dn>
> <username-is-dn/>
> </username-to-dn>
> <group-search group-name="SIMPLE" iterative="false" group-dn-attribute="cn" group-name-attribute="cn">
> <group-to-principal search-by="SIMPLE" base-dn="ou=roles,***" recursive="false">
> <membership-filter principal-attribute="|(submember=uid={0})(member=uid={0})"/>
> </group-to-principal>
> </group-search>
> </ldap>
> </authorization>
> </security-realm>
> </security-realms>
> </management>
> {code}
> We then found the filterString is parsed the following way: (See [LdapGroupSearcherFactory#L115|https://github.com/wildfly/wildfly-core/blo...])
> {code:java}
> this.filterString = String.format("(%s={0})", principalAttribute);
> {code}
> which seems to make multiple attribute names as a filter impossible, which makes our use case as above impossible.
> Asked in [Forums|https://developer.jboss.org/thread/273435], but since I didn't get any answers for 3 weeks opening here.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7840?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7840:
----------------------------------------
Please pine me Honza if this looks like a problem in the kernel.
> elytron: authentication-context validation errors
> -------------------------------------------------
>
> Key: WFLY-7840
> URL: https://issues.jboss.org/browse/WFLY-7840
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Jan Kalina
>
> elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
> {code}
> /profile=default/subsystem=elytron/authentication-context=test123:add
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
> "rolled-back" => true
> }
> {code}
> Resource description snippet
> {code}
> "match-rules" => {
> "type" => LIST,
> "description" => "The match-rules for this authentication context.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7840) elytron: authentication-context validation errors
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7840?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-7840:
--------------------------------------
Component/s: Security
Assignee: Jan Kalina (was: Jason Greene)
> elytron: authentication-context validation errors
> -------------------------------------------------
>
> Key: WFLY-7840
> URL: https://issues.jboss.org/browse/WFLY-7840
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Jan Kalina
>
> elytron resource authentication-context has attribute match-rules marked as required=false and nillable=true, but fail to add an authentication-context with no match-rules attribute
> {code}
> /profile=default/subsystem=elytron/authentication-context=test123:add
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'match-rules' may not be null"},
> "rolled-back" => true
> }
> {code}
> Resource description snippet
> {code}
> "match-rules" => {
> "type" => LIST,
> "description" => "The match-rules for this authentication context.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-4510) "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4510?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-4510:
-------------------------------------
[~mdixit05] The batch subsystem is not part of JBoss EAP 6.4. If you're seeing this message it is likely a different cause.
> "IJ000451: The connection manager is shutdown" after disabling/enabling a datasource
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4510
> URL: https://issues.jboss.org/browse/WFLY-4510
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Environment: Windows 8.1 x64, JDK 1.8.0_20, Wildfly 8.2.0.Final
> Reporter: Renann Prado
> Assignee: James Perkins
> Fix For: 9.0.0.Beta1
>
>
> The below exception is thrown after the DataSource is disabled/enabled.
> I read that in Wildfly 9 onwards disabling/enabling a DataSource is deprecated, so *maybe* this problem won`t happen in next Wildfly version.
> {noformat}
> 2015-04-12 16:48:07,691 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /XXXXXe-web/NewServlet: javax.batch.operations.BatchRuntimeException: JBERET000622: Failed to obtain connection from org.jboss.jca.adapters.jdbc.WrapperDataSource@da89438, java:jboss/dasources/MySQL
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:802) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.JdbcRepository.insertJobInstance(JdbcRepository.java:264) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.repository.AbstractRepository.createJobInstance(AbstractRepository.java:91) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:82) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl$1.invoke(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.invokeTransaction(JobOperatorImpl.java:295) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at org.jberet.operations.JobOperatorImpl.start(JobOperatorImpl.java:79) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> at com.test.NewServlet.processRequest(NewServlet.java:64) [classes:]
> at com.test.NewServlet.doGet(NewServlet.java:95) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:154)
> at org.jberet.repository.JdbcRepository.getConnection(JdbcRepository.java:800) [jberet-core-1.0.2.Final.jar:1.0.2.Final]
> ... 36 more
> Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/dasources/MySQL
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:371)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:421)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:515)
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> ... 37 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7841) ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
by Tibor Digana (JIRA)
[ https://issues.jboss.org/browse/WFLY-7841?page=com.atlassian.jira.plugin.... ]
Tibor Digana commented on WFLY-7841:
------------------------------------
Guys, the cdi concurrency without automatically activated context is really useless.
Automatically activating the context is the idea of the word "Managed" in the executor interface; otherwise I could simply use J2SE utilities without making any difference.
As a comparison with EJB 3.0 @Schedule the request scope works and it is the only scope of the bean which makes sense; otherwise I could not imaging any other scope like session or view which has obviously no notion about HTTP. As a comparison with EJB Timer, even if you try to fetch {{SessionScoped}} EJB bean to the EJB Thread you may expect an exception. And therefore request scope in managed thread means for me that the {{#submit() method}} forks as short lifecycle as possible and I have guarantee that two calls of {{#submit() method}} successfully isolates the jobs and no data is shared which is perfect isolation which in J2SE would not be anyhow more simple without using {{ThreadLocal}} and therefore CDI is so perfect and straightforward for me.
> ManagedScheduledExecutorService could not find EntityManager produced by CDI producer. No active context.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7841
> URL: https://issues.jboss.org/browse/WFLY-7841
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Tibor Digana
> Assignee: Stuart Douglas
>
> The problem is that _EntityManager_ does not have managed delegate within a job executed by _ManagedScheduledExecutorService#scheduleAtFixedRate()_.
> The _EntityManager_ is produced by CDI producer and entire web application is able to work with injected _EntityManager_ except for the jobs.
> I tried to schedule executing the job in two ways and both finished with same issue (No managed context in _EntityManager_) :
> * _@ApplicationScoped_ job instance was passed to executor from caller.
> * The job was changed to _RequestScoped_ and _ContextProxy#createContextualProxy()_ created the Job bean instance and then I called _scheduleAtFixedRate(job, 5, 60, SECONDS)_
> It looks to me that _javax.enterprise.concurrent_ has a different _BeanManager_ and therefore has no notion about my CDI Producer of _EntityManager_. The producer is regular producer of _EntityManager_ in JavaEE.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months