[JBoss JIRA] (JBJCA-1222) Make sure that Subject operations runs as privileged
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1222?page=com.atlassian.jira.plugin... ]
Jesper Pedersen updated JBJCA-1222:
-----------------------------------
Summary: Make sure that Subject operations runs as privileged (was: org.jboss.jca.adapters.jdbc.WrapperDataSource#getConnection() requires unusual permissions)
Description:
Requirements
* SubjectFactory operations
* Methods on Subject instance
was:
The WrapperDataSource calls AbstractConnectionManager#allocateConnection() which in turn causes JBossSecuritySubjectFactory#createSubject() to be called. This method requires special/unusual permissions that a user deployment cannot be expected to configure.
The connection manager and/or the wrapper data source should probably check a more pedestrian "get connection" sort of permission, and then do the rest of the work in a privileged context.
> Make sure that Subject operations runs as privileged
> ----------------------------------------------------
>
> Key: JBJCA-1222
> URL: https://issues.jboss.org/browse/JBJCA-1222
> Project: IronJacamar
> Issue Type: Bug
> Reporter: David Lloyd
> Assignee: Jesper Pedersen
>
> Requirements
> * SubjectFactory operations
> * Methods on Subject instance
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (WFLY-2358) setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2358?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2358:
-----------------------------------------------
Martin Velas <mvelas(a)redhat.com> changed the Status of [bug 1022240|https://bugzilla.redhat.com/show_bug.cgi?id=1022240] from ON_QA to VERIFIED
> setting <jacc-star-role-allow> in jboss-web.xml does not set allRolesMode to "authOnly"
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-2358
> URL: https://issues.jboss.org/browse/WFLY-2358
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web)
> Affects Versions: 8.0.0.Beta1
> Reporter: Derek Horton
> Assignee: Remy Maucherat
>
> I am trying to get only authentication (no authorization) to work for web application.
> In EAP 5, all that was required was to set the <role-name> to a '*' in
> the <security-constraint> of the web.xml. I tried this in EAP 6,
> however, it did not work.
> I then found the <jacc-star-role-allow> setting that goes in the
> jboss-web.xml. Unfortunately, adding this option did not cause the
> wildcard ('*') role-name to work for allowing any authenticated user
> to access the web application.
> Using the following system property does appear to work:
> org.apache.catalina.realm.RealmBase.ALL_ROLES_MODE=authOnly
> How reproducible:
> Everytime.
> Steps to Reproduce:
> 1. Set <role-name>*</role-name> in the security-contraint
> 2. Set <jacc-star-role-allow>true</jacc-star-role-allow> in jboss-web.xml
> 3. Set the security-domain so that no roles are assigned to a user
> 4. Attempt to access the web app
> Actual results:
> 403 - access denied
> Expected results:
> 200 - access allowed
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Shashank Agarwal updated DROOLS-618:
------------------------------------
Description:
Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
Name: http-54350-Processor15
State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
Name: http-54350-Processor18
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
Name: http-54350-Processor20
State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
We do not have definite threads to re-produce the issue.
But deadlocks are happening repeatedly on our production.
Regarding out environment details:
1. We have windows box on which application runs.
2. The rules used are kept in .drl and .xls formats
3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
4. Setup a few session globals as well.
was:
Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
Name: http-54350-Processor15
State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
Name: http-54350-Processor18
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
Name: http-54350-Processor20
State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
Regarding out environment details:
# We have windows box on which application runs.
# The rules used are kept in .drl and .xls formats
# Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
# Setup a few session globals as well.
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> We do not have definite threads to re-produce the issue.
> But deadlocks are happening repeatedly on our production.
> Regarding out environment details:
> 1. We have windows box on which application runs.
> 2. The rules used are kept in .drl and .xls formats
> 3. Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> 4. Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
[ https://issues.jboss.org/browse/DROOLS-618?page=com.atlassian.jira.plugin... ]
Shashank Agarwal updated DROOLS-618:
------------------------------------
Attachment: http-54350-Processor15.txt
http-54350-Processor18.txt
http-54350-Processor20.txt
> Thread deadlock on org.drools.util.CompositeClassLoader
> -------------------------------------------------------
>
> Key: DROOLS-618
> URL: https://issues.jboss.org/browse/DROOLS-618
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.6.0.Final
> Environment: drools expert
> Reporter: Shashank Agarwal
> Assignee: Mark Proctor
> Attachments: http-54350-Processor15.txt, http-54350-Processor18.txt, http-54350-Processor20.txt
>
>
> Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
> Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
> Name: http-54350-Processor15
> State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
> Name: http-54350-Processor18
> State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
> Name: http-54350-Processor20
> State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
> Regarding out environment details:
> # We have windows box on which application runs.
> # The rules used are kept in .drl and .xls formats
> # Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
> # Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (DROOLS-618) Thread deadlock on org.drools.util.CompositeClassLoader
by Shashank Agarwal (JIRA)
Shashank Agarwal created DROOLS-618:
---------------------------------------
Summary: Thread deadlock on org.drools.util.CompositeClassLoader
Key: DROOLS-618
URL: https://issues.jboss.org/browse/DROOLS-618
Project: Drools
Issue Type: Bug
Affects Versions: 5.6.0.Final
Environment: drools expert
Reporter: Shashank Agarwal
Assignee: Mark Proctor
Sometimes we are facing issues of thread deadlock due to which our application goes unresponsive. Drools version 5.6.0
Below is the deadlock statements detected by jconsole, also attached full tread dumps. There three threads are deadlocked triangularly.
Name: http-54350-Processor15
State: BLOCKED on org.drools.rule.JavaDialectRuntimeData$PackageClassLoader@1d5787a owned by: http-54350-Processor18
Name: http-54350-Processor18
State: WAITING on java.util.concurrent.locks.ReentrantLock$NonfairSync@3cda324d owned by: http-54350-Processor15
Name: http-54350-Processor20
State: BLOCKED on org.drools.util.CompositeClassLoader@61269654 owned by: http-54350-Processor15
Regarding out environment details:
# We have windows box on which application runs.
# The rules used are kept in .drl and .xls formats
# Call StatefulKnowledgeSession session = base.newStatefulKnowledgeSession();
# Setup a few session globals as well.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months
[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Dirk Franssen (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Dirk Franssen commented on WFLY-2387:
-------------------------------------
Just for info: injection in an entity listener on Glassfish 4.1 doesn't work either. (@Inject seems to be ignored and the field stays null, resulting in nullpointer exceptions)
Currently I also use the BeanManager workaround on Wildfly 8.1.0.Final. This BeanManager can be injected though, so no need for a jndi lookup.
{code:title=MyEntityListener.java|borderStyle=solid}
...
@Inject
BeanManager beanManager; //Workaround WFLY-2387
...
protected String getPrincipalName() {
//Workaround WFLY-2387
Set beans = beanManager.getBeans(Principal.class);
Bean bean = (Bean) beans.iterator().next();
CreationalContext ctx = beanManager.createCreationalContext(bean);
Principal principal = (Principal) beanManager.getReference(bean, Principal.class, ctx);
return principal.getName();
}
{code}
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 9.0.0.Beta1
>
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 4 months