[JBoss JIRA] (WFLY-7334) Elytron kerberos implementation ignore java.security.krb5.* system properties
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7334?page=com.atlassian.jira.plugin.... ]
Jan Kalina edited comment on WFLY-7334 at 10/21/16 7:05 PM:
------------------------------------------------------------
Note: About *java.security.krb5.conf* property: setting *refreshKrb5Config* option to "true" is currently required to do Config loading.
was (Author: honza889):
About *java.security.krb5.conf* property: setting *refreshKrb5Config* option to "true" is currently required to do Config loading.
> Elytron kerberos implementation ignore java.security.krb5.* system properties
> -----------------------------------------------------------------------------
>
> Key: WFLY-7334
> URL: https://issues.jboss.org/browse/WFLY-7334
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Attachments: standalone-elytron.xml
>
>
> I don't see any behavior change, when I set standard java.security.krb5.* system properties. Trying to set properties in both ways:
> * command line
> {code}
> -Djava.security.krb5.conf=/unreal/path -Djava.security.krb5.debug=true -Djava.security.krb5.kdc=wrong.kdc -Djava.security.krb5.realm=REDHAT.COM
> {code}
> * standalone.xml
> {code}
> <property name="java.security.krb5.conf" value="/etc/krb5.confBUG"/>
> <property name="java.security.krb5.kdc" value="localhost.localhostBUG"/>
> <property name="java.security.krb5.realm" value="JBOSS.ORGBUG"/>
> <property name="java.security.krb5.debug" value="true"/>
> {code}
> Biggest problem as I see is user is unable to change {{krb5.conf}} location. In legacy security solution it was possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1888) HTTP management response caching is broken
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1888:
----------------------------------------
Summary: HTTP management response caching is broken
Key: WFCORE-1888
URL: https://issues.jboss.org/browse/WFCORE-1888
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The HTTP handling for the management API supports caching of read-resource-description and read-operation-description responses. But the ETag calculation used in support of this is broken. It was written to calculate an MD5 hash of the toString() representation of a DMR response but the object being hashed got changed to an OperationResponse. The toString() representation of that is unique for each request.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7367) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7367:
-------------------------------
Description:
The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...]
{quote}
ClassLoader getNewTempClassLoader()
Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
Returns:
temporary ClassLoader with same visibility as current loader
{quote}
was:
Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...]
{quote}
ClassLoader getNewTempClassLoader()
Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
Returns:
temporary ClassLoader with same visibility as current loader
{quote}
> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7367
> URL: https://issues.jboss.org/browse/WFLY-7367
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call.
> Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
> temporary ClassLoader with same visibility as current loader
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7367) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7367:
-------------------------------
Description:
Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...]
{quote}
ClassLoader getNewTempClassLoader()
Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
Returns:
temporary ClassLoader with same visibility as current loader
{quote}
was:Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7367
> URL: https://issues.jboss.org/browse/WFLY-7367
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> Ensure that the cached temp classloader reference is cleared at undeploy time, which is when the org.jboss.as.jpa.hibernate4.HibernateAnnotationScanner#CLASSES_IN_JAR_CACHE are also cleared.
> Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...]
> {quote}
> ClassLoader getNewTempClassLoader()
> Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call.
> Returns:
> temporary ClassLoader with same visibility as current loader
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-6417) ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6417?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6417:
-------------------------------------------
This test now passes for 7.0.0.GA: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clus...
I did not see any instances of "ArrayIndexOutOfBounds" in the logs nor "getResult() called during wrong phase"
> ArrayIndexOutOfBoundsException in EJB client in 2-clusters EJB invocation graceful shutdown tests
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-6417
> URL: https://issues.jboss.org/browse/WFLY-6417
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Richard Achmatowicz
>
> I have tests that start 2 clusters and a standalone EJB client and do remote EJB invocations like this: standalone EJB client -> cluster 1 (forwarder) -> cluster 2 (target) -> back to cluster 1 -> back to standalone client.
> During a graceful shutdown variant of such tests, where the nodes of the clusters are repeatedly shut down and then brough back up to life, one node at a time, I've seen an {{ArrayIndexOutOfBoundsException}} in EJB client on one of the forwarder nodes:
> {code}
> 2016-03-21 14:26:59,050 ERROR [org.jboss.as.ejb3.invocation] (default task-110) WFLYEJB0034: EJB Invocation failed on component ForwardingBeanImpl for method public abstract java.lang.String org.jboss.qa.eap.clustering.[redacted].testApps.june2013.Bean.test(java.lang.String,long): javax.ejb.EJBException: java.lang.ArrayIndexOutOfBoundsException: 5
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:187)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 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.ArrayIndexOutOfBoundsException: 5
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy63.test(Unknown Source)
> at org.jboss.qa.eap.clustering.[redacted].testApps.june2013.ForwardingBeanImpl.test(ForwardingBeanImpl.java:30)
> at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 44 more
> {code}
> In the log, this exception is preceded by warnings about failed invocations and "No EJBReceiver available" which I don't understand -- at the time, all nodes should be up and running and seeing each other (which seems to be confirmed by the logs).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final deployment crash
by Jason Morgan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.... ]
Jason Morgan commented on WFLY-6500:
------------------------------------
No apology needed. I didn't mean to make that sound like I was upset in any way. I just wanted [~ctomc] to know that the problem is with wildfly itself and not anything else.
And no, I know what the problem is and I have disabled the deployment directory for my servers so that it doesn't happen on accident. It is something that needs to be addressed so that someone else doesn't experience the problem
> wildfly-10.0.0.Final deployment crash
> -------------------------------------
>
> Key: WFLY-6500
> URL: https://issues.jboss.org/browse/WFLY-6500
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Jason Morgan
> Assignee: Tomaz Cerar
> Fix For: 10.1.0.Final
>
>
> Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months