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

[Design of Security on JBoss] - Re: Security is broken in JBoss Head

by anil.saldhana＠jboss.com

Should be fixed now, Adrian. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064980#4064980 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064980

18 years, 8 months

1
0
0 / 0

[QA of JBoss Portal] - Re: SSO Unit Testing

by sohil.shah＠jboss.com

anonymous wrote : | can we suppose of course that what you call portal1 and portal2 are plain old war files that are customized to use the correct auth config and a special servlets ? | Correct. From an SSO standpoint, there is no difference between a Portal and any other web application. I have also noticed that we can use a barebones portal which is jboss-portal.sar with only the portal-core.war and portal-server.war files and ofcourse the conf directory and lib directory for configuration and thirdparty dependencies respectively View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064977#4064977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064977

18 years, 8 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security is broken in JBoss Head

by anil.saldhana＠jboss.com

Adrian, I will fix it now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064975#4064975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064975

18 years, 8 months

1
0
0 / 0

[Design of Security on JBoss] - Security is broken in JBoss Head

by adrian＠jboss.org

JBoss Head won't even boot with the latest security changes I figured out that part of was due to this file being missing from the classpath: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/security/trun... Adding that to the classpath leads to a completely different error: | 14:39:42,912 ERROR [EJBRegistrationDeployer] Error during deploy: vfsfile:/home/ejort/jboss-head/build/output/jboss-5.0.0.Beta3/server/default/deployers/jbossweb.deployer/ | org.jboss.deployers.spi.DeploymentException: java.lang.NullPointerException | at org.jboss.ejb3.deployers.EJBRegistrationDeployer.deploy(EJBRegistrationDeployer.java:173) | at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.deploy(AbstractVFSRealDeployer.java:45) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:661) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:624) | at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:588) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:427) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:372) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247) | at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89) | at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403) | at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342) | at org.jboss.Main.boot(Main.java:210) | at org.jboss.Main$1.run(Main.java:523) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.NullPointerException | at org.jboss.util.state.StateMachine.nextState(StateMachine.java:121) | at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossPolicyConfiguration.java:211) | at org.jboss.security.jacc.JBossPolicyConfiguration.<init>(JBossPolicyConfiguration.java:69) | at org.jboss.security.jacc.JBossPolicyConfigurationFactory.getPolicyConfiguration(JBossPolicyConfigurationFactory.java:84) | at org.jboss.ejb3.security.JaccHelper.initialiseJacc(JaccHelper.java:74) | at org.jboss.ejb3.deployers.Ejb3JBoss5Deployment.createPolicyConfiguration(Ejb3JBoss5Deployment.java:74) | at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:346) | at org.jboss.ejb3.deployers.EJBRegistrationDeployer.deploy(EJBRegistrationDeployer.java:161) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064972#4064972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064972

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by alesj

"adrian(a)jboss.org" wrote : I thought I said not to add that xml config? | You're not listening to any of my objections on this which has just led to all | sorts of hacks and stupid configurations. | Yup. I did respond I'll do them both though. :-( The thing is people - like ThomasD - want to write as little code as possible to get name injected. If he needs to write the whole | <property name="name"><inject fromContext="name"/></property> | it's almost the same if he writes | <property name="name">MyBeanName</property> | Even less chars on short names. :-) But I agree auto-injection has its advantages. :-) "adrian(a)jboss.org" wrote : | 1) The name injection should be configured on a property | e.g. something like | | | <property name="name"><inject fromContext="name"/></property> | | | | You should be able to inject the bean name anywhere, e.g. | on a parameter to the constructor | | | <constructor> | | <parameter><inject fromContext="name"/></parameter> | | </constructor> | | | | and even potentially use it to resolve an alias to the real name | | | | <inject bean="SomeAlias" fromContext="name"/> | | | | 2) This just matches what should be doable and should be done via an annotation | | | @inject(fromContext="name") | | public void setName(String name); | | | Yup, I agree totally. The parameter configuration should be there. And I'm also not keen on | <inject fromContext="name"/> | So that I don't screw it up for the Nth time, what should we use then? :-) And I don't understand what you meant with alias usage? "adrian(a)jboss.org" wrote : | 3) The idea of hardwiring "setName" into the microcontainer code | as some kind of default is just stupid. | e.g. What if the bean already uses the "name" property for something else? You should be aware that setName is not used for bean name, and you actually set name-method attribute. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064966#4064966 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064966

18 years, 8 months

1
0
0 / 0

[Design of JBossCache] - Re: Consolidate delegating cache loader classes [JBCACHE-113

by manik.surtani＠jboss.com

Ok, here is what I propose: 1) Remove the DelegatingCacheLoader class. I don't see any value add here. TcpDelegatingCacheLoader and LocalDelegatingCacheLoader directly extend AbstractCacheLoader. 2) Add protected methods getCacheLoader()/setCacheLoader() to AbstractDelegatingCacheLoader so all implementors need to do - at a minimum - is to extend the class and call setCacheLoader() in the constructor to set who to delegate to. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064950#4064950 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064950

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by adrian＠jboss.org

I'm not overly keen on this syntax | <inject fromContext="name"/> | since the injection form with an explicit "bean" | <inject/> | is used for injection by type. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064947#4064947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064947

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Providing bean name aware feature

by adrian＠jboss.org

I thought I said not to add that xml config? You're not listening to any of my objections on this which has just led to all sorts of hacks and stupid configurations. The way you've done is also crippled, see below. 1) The name injection should be configured on a property e.g. something like | <property name="name"><inject fromContext="name"/></property> | You should be able to inject the bean name anywhere, e.g. on a parameter to the constructor | <constructor> | <parameter><inject fromContext="name"/></parameter> | </constructor> | and even potentially use it to resolve an alias to the real name | <inject bean="SomeAlias" fromContext="name"/> | 2) This just matches what should be doable and should be done via an annotation | @inject(fromContext="name") | public void setName(String name); | THERE SHOULD BE A CORRESPONDANCE BETWEEN THE XML AND THE ANNOTATION FEATURES. 3) The idea of hardwiring "setName" into the microcontainer code as some kind of default is just stupid. e.g. What if the bean already uses the "name" property for something else? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064946#4064946 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064946

18 years, 8 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing genrated advisors

by flavia.rainone＠jboss.com

Once when I ran the tests, you told me how important is the warmup property. What value do you advise me to use on this property, so I that the test results don't be affected by the startup phasis? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064937#4064937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064937

18 years, 8 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMSRouter refactoring

by mark.little＠jboss.com

"beve" wrote : anonymous wrote : I'm concerned you're starting to mix requirements. We have splitter and aggregator capabilities elsewhere too. | Yes, so am I. This was more of a desperate solution to get things working for me. | | Should I use the Notifiers for this? | In this case I have to add the correlation stuff and that would require some refactoring of NotifyQueue and NotifyTopics. Is this alright? | | I'll also check out the wiretap as I havn't done so yet. | Definitely look at what's already there and then come up with a proposal for reusing (and possibly refactoring) what we have. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064920#4064920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064920

18 years, 8 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 July 2007