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

Re: [jboss-dev-forums] [EJB Development] - Allow for configuring default resource adaptor name for the EJB2 MDBs

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion "Allow for configuring default resource adaptor name for the EJB2 MDBs" To view the discussion, visit: http://community.jboss.org/message/536564#536564 -------------------------------------------------------------- > Clebert Suconic wrote: > > Right, and how do you set some.system.property.name without changing run.conf? > > > It is unacceptable to add a -D property to set this config. > > I am not saying that we should be doing it through a system property. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536564#536564] Start a new discussion in EJB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [EJB Development] - Allow for configuring default resource adaptor name for the EJB2 MDBs

by Clebert Suconic

Clebert Suconic [http://community.jboss.org/people/clebert.suconic%40jboss.com] replied to the discussion "Allow for configuring default resource adaptor name for the EJB2 MDBs" To view the discussion, visit: http://community.jboss.org/message/536563#536563 -------------------------------------------------------------- Right, and how do you set some.system.property.name without changing run.conf? It is unacceptable to add a -D property to set this config. Whatever config we choose must be done through some XML that would be read at boot time. A MC XML Bean setting a property would be fine since users are not meant to change it. a System property is not. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536563#536563] Start a new discussion in EJB Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [EJB 3.0 Development] - BOMs Away - Composing Dependency Management

by Carlo de Wolf

Carlo de Wolf [http://community.jboss.org/people/wolfc] replied to the discussion "BOMs Away - Composing Dependency Management" To view the discussion, visit: http://community.jboss.org/message/536558#536558 -------------------------------------------------------------- Right now we duplicate the versions of each components that we expose in both the bom and the profile. That's not how it's supposed to work. If I read the maven manual correctly they are saying that the user (== ejb3_1) should import the bom (== as6). Which of course can't happen. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536558#536558] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

[EJB 3.0 Development] - ejb3_1 and its relation with ejb3 bom

by jaikiran pai

jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion "ejb3_1 and its relation with ejb3 bom" To view the discussion, visit: http://community.jboss.org/message/536550#536550 -------------------------------------------------------------- Right now we are duplicating the version info for EJB3 modules/components in 2 places: 1) bom as-6 http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/components/bom/as6/t... http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/components/bom/as6/t... 2) ejb3_1 module http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/ejb3_1/pom.xml http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/ejb3_1/pom.xml The ejb3_1 module is a pom which declares all the "dependencies" that will be pulled in when some other project depends on this (ex: AS_Trunk/ejb3). On the other hand, the bom as-6 is "dependency management" which enforces the versions for ejb3 modules/components. As such, I think that the ejb3 bom as-6 should be the parent for the ejb3_1 module. That way, the ejb3_1 module pom will just declare the dependencies and let the parent bom declare the dependency versions. But then, the bom has different artifacts, one for each AS version. So making the bom as the parent of ejb3_1 won't play out well when there are multiple AS version boms. All I am trying to avoid is, having multiple poms specify the versions of EJB3 modules/components. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536550#536550] Start a new discussion in EJB 3.0 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - To scope or not to scope (domain.xml)

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "To scope or not to scope (domain.xml)" To view the discussion, visit: http://community.jboss.org/message/536534#536534 -------------------------------------------------------------- > Jason Greene wrote: > > In the discussion we had at the OA&M meeting with the JON folks, we thought that the AS perspective of management ends with the domain . "Multi-domain" management was something that JON would offer, as a compelling difference. So our admin console, cli, and domain.xml interfaces would be limited to a domain. I still think this is the "right" approach. Yes, limiting to a domain seems the right approach. But are we sure that a domain should manage a heterogenous group? Let's put it another way - should embedded jopr manage a heterogenous group? Where is the value addon from JON? How likely is it that you have multiple heterogenous configurations within a company? Isn't that just only a small percentage where you would need that? Grouping obviously seems to be a important. Where having a heterogenous configuration within a domain, makes this quickly quite big and complex. Splitting that up in smaller "manageable units", which have more in common than "just" a domain name - with clearer boundaries/responsibilities could help to make it easier to understand and reduce overall complexity. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536534#536534] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration

by Darran Lofthouse

Darran Lofthouse [http://community.jboss.org/people/darran.lofthouse%40jboss.com] replied to the discussion "JBWS-2210 : CXF Username Token JAAS integration" To view the discussion, visit: http://community.jboss.org/message/536531#536531 -------------------------------------------------------------- > I see. Perhaps in some cases no authorization will be required, so just dropping an authorization interceptor will satisfy such requirements. Yes this is where I think your two interceptor approach will help as it gives you the option of dropping the authorization one when not required. > Sure. I saw the following code line in the JBoss Native : > > securityAdaptor.pushSubjectContext(subject, principal, credential); > > this is probably to do with what you explained above. Yes that line is where we push the subject onto the ThreadLocal for the request so it is ready for further checks for subsequent calls. Following the existing code will probably help you get something up and running but do keep in mind that it was written at a time the WS stack needed to support JBoss AS 4, 5 and 6 so a final switch to the APIs recommended by Anil would be required at some point. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536531#536531] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration

by Sergey Beryozkin

Sergey Beryozkin [http://community.jboss.org/people/sergeyb] replied to the discussion "JBWS-2210 : CXF Username Token JAAS integration" To view the discussion, visit: http://community.jboss.org/message/536529#536529 -------------------------------------------------------------- Hi Darran Thanks for the comments. > The approach of having two interceptors (one for authentication and one for authorization) is probably the biggest part of this problem already solved. > > Where this becomes really apparent is where endpoints are deployed as EJB3 session beans, in this case the container can already be configured to perform authentication and authorization - as a deployed session bean can potentially be called from multiple different clients it makes sense for the authorization checks to remain with the bean. I see. Perhaps in some cases no authorization will be required, so just dropping an authorization interceptor will satisfy such requirements. > The point of these two comments really is to highlight that this is not just a case of obtaining a Subject from whatever app server you are running in but actually associating the users identity with the request so that is propagates for further calls within the application server. Using the APIs suggested from Anil should help with this so this is just something to keep in mind. Sure. I saw the following code line in the JBoss Native : > securityAdaptor.pushSubjectContext(subject, principal, credential); this is probably to do with what you explained above. > A final feature related to this that I know there is user demand for would be the ability to annotate the POJO endpoints with the same role annotations as used on EJB3 sesstion beans - we were unable to do this for our Native implementation of this as we had to support JAX-RPC as well as JAX-WS but as this would be JAX-WS only this could be an option and may help simplify the role configuration I was thinking of adding (at the CXF level) a utility AuthorizingInInterceptor subclass which would be configured with the name of the annotation such as @RolesAllowed that target POJO classes may be annotated with. This interceptor would introspect a given class and return a list of expected roles for a given method name. Perhaps it might help with addressing this requirement thanks, Sergey -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536529#536529] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - Recent changes on CXF integration

by Alessio Soldano

Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion "Recent changes on CXF integration" To view the discussion, visit: http://community.jboss.org/message/536519#536519 -------------------------------------------------------------- > Alessio Soldano wrote: > > Besides this, it's probably interesting to note that for fixing JBWS-2971 I started using another integration hook, ie. the Spring NamespaceHandlerSupport configuration. As you know, we're generating the jboss-cxf.xml file at deploy time and basically leveraging the spring configuration of CXF (in order to allow both stack agnostic deployments and cxf specific deployments to work seamlessly). > CXF has spring.handler configuration files that map namespaces for elements in the spring xml to default beans. We're now using a custom mapping for the jaxws.endpoint elements, which in the end allows us to overwrite the CXF org.apache.cxf.jaxws.EndpointImpl giving us control over the endpoint start/stop/publish/etc. while still delegating to the CXF one for the core processing. > Generally speaking, customizing the spring namespace handler configuration for loading different bean parsers is a powerful integration hook, to be considered in addition to the already used setup of CXF Configurer in the Bus. On this topic, please note the changes for JBWS-2995: * we now have a custom NamespaceHandlerResolver that is installed in the XmlBeanDefinitionReader used for parsing the jboss-cxf.xml file and controls the way Spring maps namespaces to beans. That basically makes sure our NamespaceHandler customizations are considered first, falling back to the default Spring/CXF resolution when there's nothing JBossWS specific. Before this change, the resolution (spring.handler check oreder) was erroneously depending on classloader internals * we provide a spring.handler configuration file having our customizations only, no need to merge all the single configurations coming from the CXF component jars. As a side effect, this simplifies the upgrade process when a new Apache CXF release is available. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536519#536519] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [JBoss Web Services Development] - JBWS-2210 : CXF Username Token JAAS integration

by Sergey Beryozkin

Sergey Beryozkin [http://community.jboss.org/people/sergeyb] replied to the discussion "JBWS-2210 : CXF Username Token JAAS integration" To view the discussion, visit: http://community.jboss.org/message/536512#536512 -------------------------------------------------------------- Hi Anil thanks for the link. For the moment I tried (with the help from Alessio) the approach used in JBoss Native, where AuthenticationManager is resolved via JNDI lookup. But I'll bear in mind that a newer PicketBox api is available now, I may ask for some clarifications a bit later on... cheers, Sergey -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536512#536512] Start a new discussion in JBoss Web Services Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 years

1
0
0 / 0

Re: [jboss-dev-forums] [Management Development] - ProfileService SPI impacts of domain.xml

by Emanuel Muckenhuber

Emanuel Muckenhuber [http://community.jboss.org/people/emuckenhuber] replied to the discussion "ProfileService SPI impacts of domain.xml" To view the discussion, visit: http://community.jboss.org/message/536509#536509 -------------------------------------------------------------- > Scott Stark wrote: > > I don't see that it is practical to have the original deployment state an indirection on some configuration object, so what you mean is that when we override the property value, we are doing so with an injection to a property in the domain configuration metadata object. Yes, i think using the domain configuration for this would make sense. In the end that's what matters. > Scott Stark wrote: > One of the changes we have to make to the profileservice ManagedObject implementation is to have a seperation from the runtime and configuration. The configuration is the unresolved BeanMetaData with only simple values and injection references. We cannot query the runtime state of the runtime component. Access to runtime values and operations is a seperate aspect from the configuration. A clearer separation between configuration and runtime is something missing. In the end "configuration" is what should be exposed based on the domain model and then we can look at merging runtime MOs into a composite MO - so configuration always maps back to the domain model. For runtime objects we just provide value dispatching, no persistence. So i think that full out of the box configuration support for BeanMetaData - like we have it now. Where we overwrite the MO view with the actual pojo MO view and then update BMD, is something out of the scope. It also requires classloading so that we can actually build the pojo view. However we should be able to add better support for e.g. BeanMetaDataFactories - since we basically provide a domain specific metadata to another domain specific metadata. So the domain thread pool metadata to the actual thread pool metadata bean factory. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/536509#536509] Start a new discussion in Management Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]

16 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 2010