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

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

I've broken up the DSX stuff into two deployers DSXParserDeployer -- Responsible for parsing the *-ds(x).xml files to generate the JCADeploymentMetaData which wraps this in DSXMetaData DSXDeployer -- Receives the DSXMetaData, builds the ServiceDeployment/ServiceMetaData and then adds the result as an attachment to the DeploymentUnit. Taking a step back, is this how the stuff is supposed to work? Something just doesn't feel right. This is how the RARDeployer is built and I was using that as a working example, but I am not entirely familiar with the new deployment architecture. Shouldn't the RARDeployer and all JCA related stuff be moved over to the Structure type deployers. The RAR stuff as it is today seems pretty hackish. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989133#3989133 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989133

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by scott.stark＠jboss.org

Right, so the ServiceDeploymentDeployer sees a non-null/non-empty services list and then adds these as components to be deployed without doing any parsing: | if (services == null || services.isEmpty()) | return; | | for (ServiceMetaData service : services) | addServiceComponent(unit, service); | If you populate the ServiceDeployment services and bypass the xml config this should still work. I don't see why it would not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989131#3989131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989131

19 years, 4 months

1
0
0 / 0

[Design of JBoss Portal] - Re: LDAP Support expectations

by bdaw

Hi. I cannot respond to your every comment but I'll try to do quick reply. At first.... Thanks a lot for your post. The 2.6 roadmap is closed indeed but we'll start to define 3.0 features soon so your comments bring a lot of value! anonymous wrote : What i don`t understand right now is, why do you want to decouple Users and Roles in a MembershipModule, what is the advantage of this? The target for 2.6 was to keep current design and add LDAP support, and thats why there is no revolution here. The reason for MembershipModule is because in LDAP you can define User-Role relationship in several ways. It can be held by either user or role entry or resolved dynamically. So it's more convenient to have separate module which you can swap with different implementation of such relationship. Persistence config: It's more like this currently (and still morphing a little): http://anonsvn.jboss.org/repos/portal/trunk/identity/src/resources/test/c... standardidentity-config.xml - the file that defines different possible module configurations identity-config.xml - which selects proper modules and override only whats needed - like connection options There are some design reasons for keeping profile configuration in separate file. We want to be able to generate hibernate mappings from it dynamically for ex. - <access-mode>read-write</access-mode> - there are several reasons to keep it on per property level. Even if you don't mix LDAP with DB for storage you may want to prevent write access to specific properties. We can always add global switch also - <display-name xml:lang="EN"> or <description xml:lang="EN"> is only for imformation purposes - like for tools support. There will be UserProfileModule.getProfileInfo() where you can get info object describing such mapping - so you'll have API to discover which properties and how are mapped anonymous wrote : As i understand your implemetation, Roles and User Objects maintained in LDAP, and also the relationship. Roles are used in JBoss Portal to control access rights to portal objects. Please correct me, if i`m worng, but this would mean application dependend data has to be stored in LDAP, that is not usable in larger companies, as you already mentioned, Portal is just another client application, and we have several of it. | | Maintaining Users/Groups in LDAP and map to Roles in Portal would also increas the flexibility of LDAP configuration. We fully agree. This is something we should address in 3.0. What we could probably do for now is to add one-to-one mapping of group to role in RoleModule. So similarly to portlet.xml | <security-role-ref> | <role-name>Business Admin</role-name> | <role-link>Admin</role-link> | </security-role-ref> and it could be resolved as some kind of alias. But I'm not sure if this satisfy you. I'm trying to make the implementation extendable so you could implement your grouping for 2.6 as additional modules and plug it in (like we discussed wit bvogt). But 2.6 identity codebase is still in a state of flux a little. For your suggestion about working with principal object it's something we definitely should discuss for 3.0. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989123#3989123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989123

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

Ugh...this won't work either. In the ServiceXSLDeployer | ServiceDeployment parsed = new ServiceDeployment(); | | List<ServiceDeploymentClassPath> classPaths = parseXMLClasspath(document); | parsed.setClassPaths(classPaths); | | LoaderRepositoryConfig repository = parseLoaderRepositoryConfig(document); | if (repository != null) | parsed.setLoaderRepositoryConfig(repository); | | // We can't parse the services yet, because it requires the classloader | parsed.setConfig(document.getDocumentElement()); | | In the ServiceDeploymentDeployer | List<ServiceMetaData> services = deployment.getServices(); | if (services == null) | { | Element config = deployment.getConfig(); | if (config == null) | { | log.debug("Service deployment has no services: " + deployment.getName()); | return; | } | | ServiceMetaDataParser parser = new ServiceMetaDataParser(config); | services = parser.parse(); | deployment.setServices(services); | } | | So, basically the ServiceXSLDeployer is parsing the *-ds.xml file. Using XSLT this creates the typical MBean configuration. Once this is done, the resulting ServiceDeployment is passed off to the ServiceDeploymentDeployer. He simply parses the XML configuration generated by the XSLT. The new stuff won't have this because being that no XML is created, it's all MetaData at that point. Damnit...back to square one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989120#3989120 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989120

19 years, 4 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: Cannot install JBoss Wiki!! Help Required!

by szimano

New downloads for Portal 2.4 added in downloads section: http://labs.jboss.com/portal/jbosswiki/downloads View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989114#3989114 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989114

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

Note, because I abstracted the actual building of the underlying services, it should be relatively trivial to 'swap out' both the MetaDataParser as well as the builder. This will become more important as we port JCA over to using the MC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989099#3989099 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989099

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

Cool. Thanks Scott. I will take a look at modifying what I have. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989097#3989097 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989097

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by scott.stark＠jboss.org

I don't see a reason why you should not use ServiceDeployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989095#3989095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989095

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

In looking at more of the API, should I be using the ServiceDeployment as a wrapper for all the MBeans generated via the DSXMetaData as opposed to the ServiceMetaData directly? This is what the ServiceXSLDeployer does and would seem to make some sense since all my MBeans are interdependent and should deployed in one shot. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989088#3989088 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989088

19 years, 4 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

The horribly named, org.jboss.resource.connectionmanager.RARDeployment. This is the ManagedConnectionFactory deployment for RARs. Like the JBossManagedConnectionPool and ConnectionManager it's just a standard MBean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989084#3989084 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989084

19 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 2006