November 2007 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Misleading error when StructuraDeployer throws an except

by scott.stark＠jboss.org

I would say 2 is the better behavior. Adding a deployer should be a privileged operation that can result in bad behavior. Maybe we want to get into notions like user space deployers to allow for better isolation for non-core deployers, but in this case it is a core deployer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104365#4104365 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104365

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Problem with custom login modules

by anil.saldhana＠jboss.com

Marcus, let me take a look at how the module option semantics were weaved into get into all login modules before you proceed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104362#4104362 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104362

18 years, 4 months

1
0
0 / 0

[Design of JBossCache] - Re: Optimising contents of a prepare call - JBCACHE-611

by genman

When I looked at this bug, I'm curious if there are real-world application use cases that would benefit from transaction compacting. For those applications that don't use JBoss Cache directly, would any of the following benefit from this: Hibernate 2nd level cache, HTTP session cache, POJO cache? I guess what I wonder is if there is common use case, you could benchmark it, make some compacting optimizations, then see if the changes actually had any significant impact. My money is on not much benefit of this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104352#4104352 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104352

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Problem with custom login modules

by mmoyses

JIRA issue created: http://jira.jboss.com/jira/browse/JBAS-4969 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104346#4104346 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104346

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Problem with custom login modules

by anil.saldhana＠jboss.com

This is basically a workaround to deal with morons who write login modules who get choked with additional module options (that they do not know about). You are given a map of options. Just take the ones you want and ignore the rest. Why is that difficult? I think a bug report should be filed with the IBM JDK. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104345#4104345 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104345

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Problem with custom login modules

by sguilhen＠redhat.com

When Marcus and I discussed this issue earlier today, we first considered adding some kind of check (for example, to make sure the login module is not the IBM Kerberos LM) in the AuthenticationInfo class before setting the security-domain name option, to avoid this kind of problem. This approach has a clear downside: if later on we find out about another login module that doesn't accept extra options, we will have to change our check and the code will have to be re-compiled. Thus, I think the approach Marcus is suggesting is better, as it will allow users to specify that they don't want security domain name to be automatically inserted as a module option in the configuration file. This way, no code has to re-compiled or changed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104344#4104344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104344

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - default-activation-config?

by adrian＠jboss.org

What's the purpose of this? The schema defines it as a different type, but the new metadata classes just use the spec type. This fails, the child is a plain activation-config-property. | Caused by: org.jboss.xb.binding.JBossXBRuntimeException: {http://www.jboss.com/xml/ns/javaee}default-activation-config-property not found as a child of {http://www.jboss.com/xml/ns/javaee}default-activation-config | at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:396) | at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:407) | Also, from what I can tell, it isn't a "default" at all. The default properties override the normal properties. e.g. org.jboss.ejb3.mdb.MDB | | public Map getActivationConfigProperties() | { | HashMap result = new HashMap(); | MessageDriven mdAnnotation = (MessageDriven) resolveAnnotation(MessageDriven.class); | for (ActivationConfigProperty property : mdAnnotation.activationConfig()) | { | addActivationSpecProperty(result, property); | } | | DefaultActivationSpecs defaultSpecsAnnotation = (DefaultActivationSpecs)resolveAnnotation(DefaultActivationSpecs.class); | if (defaultSpecsAnnotation != null) | { | for (ActivationConfigProperty property : defaultSpecsAnnotation.value()) | { | addActivationSpecProperty(result, property); | } | } | | return result; | } | Where addActivationSpecProperty() does a map.put() which replaces things with the same key. I don't see any reason why an annotation (class level) should override the xml (instance level)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104340#4104340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104340

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Problem with custom login modules

by anil.saldhana＠jboss.com

| (3:59:29 PM) Marcus: stefan and I were discussing our options in the kerberos case and we came up with 3 options... do you have time now to talk about it? | (3:59:35 PM) anil_msn: k | (4:00:10 PM) Marcus: option 1 is to remove the debug message (undo the jira issue) | (4:01:20 PM) Marcus: option 2 is to assume only jboss login modules will have that option, so we filter the login modules by the class name and only add the option to the map if the package is org.jboss.security | (4:03:13 PM) Marcus: option 3 we modify the security_config.xsd to add an attribute to the <login-module> element to specify if the login module accepts the debug option. this attribute will not be required and defaults to true. in a rare case like this, the costumer can set this attribute to false so that the option will not be added to the map | (4:05:15 PM) anil_msn: I was thinking about option 2 in the afternoon | (4:05:38 PM) anil_msn: but I think we need option 3 because customers who have written their own login module can get the sec domain | (4:08:18 PM) Marcus: option 3 is probably the best in our opinion. everything keeps working as it is and only in the rare occasion where a custom login module has this problem we have a workaround | (4:09:45 PM) Marcus: with option 2, custom login modules that extend one of our own will print null for the config name, because the option will not be in the map View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104338#4104338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104338

18 years, 4 months

1
0
0 / 0

[Design of Security on JBoss] - Problem with custom login modules

by mmoyses

On a recent support case the costumer is using IBM's Kerberos login module which was working fine in JBoss AS 4.0.4. Now he migrated to JBoss AS 4.2.0 and the login module fails with this stack trace: javax.security.auth.login.LoginException: Bad JAAS configuration: unrecognized option: jboss.security.security_domain at com.ibm.security.jgss.i18n.I18NException.throwLoginException(I18NException.java:7) at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:622) at com.ibm.security.auth.module.Krb5LoginModule.a(Krb5LoginModule.java:416) at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:238) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709) at java.security.AccessController.doPrivileged(AccessController.java:242) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706) at javax.security.auth.login.LoginContext.login(LoginContext.java:603) at org.epoline.security.sso.spnego.Configuration.login(Configuration.java:305) ... 101 more This option is related to this jira issue: http://jira.jboss.com/jira/browse/JBAS-1477 To resolve this issue AuthenticationInfo now puts an extra entry in all login modules options map to set the security-domain name. This extra entry is not recognized as a valid option in this specific login module thus the exception. The problem is specific to this particular login module but could lead to problems in others as well. A proposed solution could be modify the security-config schema so that an extra attribute is included in the <login-module> element. This attribute should be a boolean indicating if the login module accepts the security-domain name entry in the options map. The attribute should not be required and defaults to true, this way everything keeps working as they are. Whenever this problem occurs, the costumer has the option to set this attribute to false so that AuthenticationInfo doesn't put the entry in the map. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104337#4104337 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104337

18 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Setting load-balance-policy

by bstansberry＠jboss.com

anonymous wrote : Shouldn't there be two policies anyway like EJB2? Seems like there should be. Cleaner too. The @Clustered annotation currently only exposes one attribute as well, but that's fixable. anonymous wrote : I'd make the getter and setter for loadBalancePolicy alias | the bean policy from EJB2. Yep, that's how I'd done it. OK, seems I didn't miss anything blindingly obvious. I'll attack this with a unit test and trace logging from JBossXB. Thanks. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4104333#4104333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4104333

18 years, 4 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-dev-forums November 2007