March 2008 - jboss-dev-forums - Jboss List Archives

[Design of Security on JBoss] - Re: Security Injection in AS5

by sguilhen＠redhat.com

Forgot to disable HTML, so my last sentence was not correctly displayed. It should read "started getting a parse error saying the {urn:jboss:security-config:5.0} policy was not found as a child of {urn:jboss:bean-deployer:2.0} property". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138777#4138777 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138777

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3Deployer and EJB3ClientDeployer order

by scott.stark＠jboss.org

I'll add this scenario to the RefResolutionUnitTestCase I'm working on. The dependencies are being moved to the container level, not the module/deployment level so this is not a circular ref unless its truly a beanA to beanB to beanA reference. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138776#4138776 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138776

16 years, 6 months

1
0
0 / 0

[Design of Security on JBoss] - Re: Security Injection in AS5

by sguilhen＠redhat.com

Here is some background information As part of http://jira.jboss.org/jira/browse/JBAS-5312, I've created a new file, security-policies-beans.xml and configured the DynamicLoginConfig as a bean: | <?xml version="1.0" encoding="UTF-8"?> | | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <bean name="StandardLoginConfig" class="org.jboss.security.auth.login.DynamicLoginConfig"> | <property name="policyConfig"> | <jbsx:policy | xsi:schemaLocation="urn:jboss:security-config:5.0 resource:security-config_5_0.xsd" | xmlns:jbsx="urn:jboss:security-config:5.0" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> | <jbsx:application-policy name="jboss-web-policy" extends="other"> | <jbsx:authentication> | </jbsx:authentication> | <jbsx:authorization> | <jbsx:policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/> | </jbsx:authorization> | </jbsx:application-policy> | <jbsx:application-policy name="jboss-ejb-policy" extends="other"> | <jbsx:authentication> | </jbsx:authentication> | <jbsx:authorization> | <jbsx:policy-module code="org.jboss.security.authorization.modules.DelegatingAuthorizationModule" flag="required"/> | </jbsx:authorization> | </jbsx:application-policy> | </jbsx:policy> | </property> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | <property name="loginConfigService">jboss.security:service=XMLLoginConfig</property> | <property name="securityManagerService">jboss.security:service=JaasSecurityManager</property> |  | <depends>jboss.security:service=XMLLoginConfig</depends> | </bean> | | </deployment> | This file replaced the old security-policies-service.xml, that was used to configure the DynamicLoginConfig as an MBean. I have tested this new configuration in many ways to make sure it was being properly parsed and the bean was being properly created. Before committing the changes, I've decided to update the AS workspace to make sure everything was still working. I then started getting the parse error saying that was not found as child of . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138774#4138774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138774

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: beanfactory injection

by alesj

"alesj" wrote : "adrian(a)jboss.org" wrote : | | We should add something to the "toHumanReadableString()" for the "anonymous inject" to ask whether they intended that it or just forgot to give a bean name. :-) | | | | | | | Bean2TypePool -> injection by interface org.jboss.beans.metadata.spi.factory.BeanFactory (or did you forget to supply a bean name for the injection?) {Installed:** NOT FOUND **} | | | | | | | Otherwise we're going to get lots of FAQs :-) | I'll update the toString/toHumanString for class dependency items. This will require update to DeployersImpl: | dependency = iDependOn.toString(); | ControllerContext other = controller.getContext(iDependOn, null); | if (other == null) | actualStateString = "** NOT FOUND **"; | I guess this is what we want: | actualStateString = "** NOT FOUND " + item.toHumanReadableString() + " **"; | On a different note, looking at | Object iDependOn = item.getIDependOn(); | if (iDependOn == null) | { | dependency = "<UNKNOWN>"; | actualStateString = "** UNRESOLVED " + item.toHumanReadableString() + " **"; | } | and a default impl of toHumanReadableString | public String toHumanReadableString() | { | StringBuilder builder = new StringBuilder(); | builder.append("Depends on '").append(getIDependOn()); | return builder.toString(); | } | it seams meaningless, since getIDependOn will return null. :-) OK, but that's impl detail. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138760#4138760 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138760

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Shared Transport in JGroups

by bstansberry＠jboss.com

A reason I asked whether you guys planned to use 2.6.2 as your default in your standalone version is the weirdness described in my second post at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132159. The weirdness where the AS impl of ChannelFactory will return a shared transport JChannel from createMultiplexerChannel is an AS-only behavior. The standard impl of ChannelFactory that ships with JGroups will return a MuxChannel. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138758#4138758 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138758

16 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Shared Transport in JGroups

by bstansberry＠jboss.com

[OT] Wow, firefox crashed about 3/4 way through this long response. Restarted it and when it restored the tab it resurrected my in progress response. :-) "clebert.suconic(a)jboss.com" wrote : I have been testing JGroups 2.6.2 and it is working fine without any problems. Great. :-) anonymous wrote : I'm a little confused to what will replace the multiplexor. Basically, JGroups maintains a static Map<String, TP> (where TP is the base class for all transport protocols, i.e. UDP and TCP). If you add a singleton_name="xxx" attribute to your UDP or TCP protocol config, JGroups sees that and checks the map for xxx before instantiating an instance of the protocol, uses the existing protocol if it finds one. So, say the JBC cache used for session repl needs a channel. It's configured to use the "udp" stack. So, it does this: Channel ch = channelFactory.createMultiplexerChannel("udp", .......); ch.connect("Tomcat-DefaultPartition"); If JBM also wanted to use the "udp" config, your code could: Channel ch = channelFactory.createMultiplexerChannel("udp", .......); ch.connect("JBM-CTRL"); In the AS, each service will have it's own channel. Only thing shared would be the UDP protocol at the bottom of the protocol stack. That's because the config of the UDP protocol in the "udp" stack includes singleton_name="udp". Let's make it more interesting. Say JBM doesn't want to use the "udp" stack; you want a customized stack, say w/o STATE_TRANSFER. So you'd added a "jbm-ctrl" stack to the -stacks.xml file and instead of the above you do this: Channel ch = channelFactory.createMultiplexerChannel("jbm-ctrl", .......); ch.connect("JBM-CTRL"); Now two different channels with separate UDP protocols. OK, but maybe not ideal, since admins now have to work harder to isolate AS clusters from each other, since there are now multiple mulitcast sockets being created. But, if you guys and I came to an agreement where we realized the same configuration *of just the UDP protocol* was fine for the "udp" and "jbm-xxx" stacks, then we could specify the same UDP config in all of them. And change the value of the singleton name, for example to singleton_name="shared-udp". Now JBC and JBM once again share a UDP protocol. anonymous wrote : Whatever it is we need the stack we currently use available on JBAS 5. Please send me whatever you want to use and I'll make sure it's integrated. Let's continue this dialogue re: shared transport to see if we can agree on a common config for a shared UDP protocol (or not). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138755#4138755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138755

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: beanfactory injection

by alesj

"adrian(a)jboss.org" wrote : | We should add something to the "toHumanReadableString()" for the "anonymous inject" to ask whether they intended that it or just forgot to give a bean name. :-) | | | | Bean2TypePool -> injection by interface org.jboss.beans.metadata.spi.factory.BeanFactory (or did you forget to supply a bean name for the injection?) {Installed:** NOT FOUND **} | | | | Otherwise we're going to get lots of FAQs :-) I'll update the toString/toHumanString for class dependency items. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138745#4138745 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138745

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanFactory and IoC annotations support

by alesj

"adrian(a)jboss.org" wrote : For the simple BeanFactory case (i.e. no factory injection in its constructor), | we can add the "bean class" as a related class automatically to the | GenericBeanFactoryMetaData | OK, this needs to be done. :-) Since if Scott wants to use our beanfactory as a way to create/pool beans, this is a must to have. e.g. applying @EJB on enterprise beans I can have a hack at that, unless Kabir wants to resolve this task personally. ;-) But I would need some instructions, since it's out of the scope of my simple IoC annotations handling. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138743#4138743 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138743

16 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3Deployer and EJB3ClientDeployer order

by alex.loubyansky＠jboss.com

What I'm seeing now is that if I have two EJB JARs in an EAR and each JAR has an EJB that has an ejb-ref to an EJB in the other JAR (creating circular dependency), the deploy will fail. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138741#4138741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138741

16 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: BeanFactory and IoC annotations support

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | This was initially raised for AOP where we need to know that com.acme.Main | instantiates a com.acme.Related programmatically and that Related has aspects | whose dependencies need to be satisifed before we deploy/invoke on Main. | So its not just annotation defined depdencies, we also need to ask aop to give its dependencies for that class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4138740#4138740 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4138740

16 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008