April 2009 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: JNDIBasedSecurityManagement ignoring the bean configurat

by anil.saldhana＠jboss.com

I have to give some thought on how to get this done cleanly (deprecate the JaasSecurityManagerService and configuration in the beans) after some things I am doing currently. Stefan, let me think further on this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224469#4224469 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224469

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: JNDIBasedSecurityManagement ignoring the bean configurat

by anil.saldhana＠jboss.com

"sguilhen(a)redhat.com" wrote : Original discussion from the user forum: | | http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224156 I did the movement to the beans just pretty close to AS5Beta3 and left some ends loose. We can get this fixed for AS5.1 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224468#4224468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224468

17 years

1
0
0 / 0

[Design of JBoss Portal] - JBoss Portal + CAS cause unreadable charactors when changing

by Shi Yusen

For example, change a user's firstname in Chinese and submit, the info will be changed to unreadable charactors and stored in db. I added this line in the very beginning in CASAuthenticationValve.invoke and fixed the problem: request.setCharacterEncoding("UTF-8"); Perhaps there are other ways to overcome this problem. If not, it would be better to add such a line to the source code. Regards, Shi Yusen/Beijing Langhua Ltd. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224464#4224464 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224464

17 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Improving the process of applying AnnotationPlugins on M

by jason.greene＠jboss.com

I spend some time trying to reproduce the mdr hotspot, using the Cinco deployment with 50 beans and 2000 methods, and what I found was that AOP was the primary bottleneck, hardly anytime was spent in mdr. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224463#4224463 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224463

17 years

1
0
0 / 0

[Design of Security on JBoss] - Re: JNDIBasedSecurityManagement ignoring the bean configurat

by sguilhen＠redhat.com

Original discussion from the user forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224156 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224456#4224456 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224456

17 years

1
0
0 / 0

[Design of Security on JBoss] - JNDIBasedSecurityManagement ignoring the bean configurations

by sguilhen＠redhat.com

A user has recently found out that JNDIBasedSecurityManagement is ignoring the properties that are set in its configuration (security-jboss-beans.xml). In his particular case, he wanted a specific CallbackHandler to be used but, after setting the CallbackHandler class in the bean declaration, he continued to see the standard JBossCallbackHandler being used. Some code to make things clear: first the bean declaration: | <bean name="MyCallbackHandler" class="..."/> | | <bean name="JNDIBasedSecurityManagement" | class="org.jboss.security.integration.JNDIBasedSecurityManagement"> | <property name="callbackHandler"><inject bean="MyCallbackHandler/></property> | </bean> | Our problem is that the JNDIBasedSecurityManagement bean is instantiated not only by the MC runtime, but also by the SecurityDomainObjectFactory: | private JNDIBasedSecurityManagement securityManagement = new JNDIBasedSecurityManagement(); | So, whenever a lookup is performed, the security domain that is created by this factory completely ignores the configuration properties that have been set by the user. One option to fix this would be to make the callbackHandler field static in JNDIBasedSecurityManagement, but then we would need to do that for every field that corresponds to a configuration property. The other option would be to make SecurityDomainObjectFactory an inner class of JNDIBasedSecMgmt. so that the former wouldn't need an explicit reference to the later, just like it is done in JaasSecurityManagerService. Just as a reminder, we cannot inject the JNDISecurityManagement bean into the SecurityDomainObjectFactory because we don't control the instantiation of the object factory - it is done by the JVM. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224454#4224454 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224454

17 years

1
0
0 / 0

[Design of EJB 3.0] - Re: WebServiceContext proxy

by BogusException

Me, too... This: anonymous wrote : @Stateless | @Remote(HelloWorld.class) | @WebService(targetNamespace = "http://ejb.me.org", name = "HelloWorld", serviceName = "HelloWorldService") | @SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = Use.LITERAL, parameterStyle = ParameterStyle.WRAPPED) | public class HelloWorldBean implements HelloWorld { | [...] ...yields... anonymous wrote : 12:53:39,374 WARN [StatelessBeanContext] EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected | 12:53:39,382 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container | 12:53:39,383 WARN [InterceptorsFactory] EJBTHREE-1246: Do not use InterceptorsFactory with a ManagedObjectAdvisor, InterceptorRegistry should be used via the bean container | 12:53:39,418 INFO [HelloWorldBean] in sayHello | 12:53:39,419 WARN [StatelessBeanContext] EJBTHREE-1337: do not get WebServiceContext property from stateless bean context, it should already have been injected The web service doesn't seem to be affected, but I am unable to figure out why it is carping... Do we have to comb through the jboss source? Is jboss saying I shouldn't use @WebService? pat :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224433#4224433 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224433

17 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: Problem deleting process instances

by ailing.qin

modif the "loadProcessInstance" in the bouttion "delete" jbpm-console.war/sa/t_processinstances.xhtml add "forUpdate="false" like : <j4j:loadProcessInstance id="#{pix_id}" target="#{pix}" forUpdate="false"/> View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224428#4224428 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224428

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Where are the management integration tests?

by jmesnil

"timfox" wrote : | | Can you invoke all the management operations using JMS messages? Yes, it's orthogonal: we can send core messages to manage JMS resources and vice versa. However for tests, I've tested core resources using core messages and JMS resources using JMS messages only View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224420#4224420 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224420

17 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Header key for scheduled message delivery should be defined

by gaohoward

To set a scheduled message, one has to use the key: message.setLongProperty(MessageImpl.HDR_SCHEDULED_DELIVERY_TIME.toString(), time); The header HDR_SCHEDULED_DELIVERY_TIME is defined on MessageImpl, which should be an internal class. It would be better to define it on JBossMessage? Also the header is defined as SimpleString, which is also an internal object. It should be a plain String object. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224418#4224418 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224418

17 years

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-dev-forums April 2009