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

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

by bdaw

It doesn't matter, I had enough other to work do ;-) busy time for everybody :) Thanks for your solution approach, which confirms my understanding of the code. I already have the hibernate extension, group object, group module and portlet - for at least display/add/change/remove groups and display users within the group. | For this I extended the common files: | in: core/src/resources/portal-core-sar: | - jboss-service.xml | in: core/src/resources/portal-core-war: | - Resource.properties | - jboss-portlet.xml | - portlet.xml | - portlet-instances.xml | in identity/src/resources/hibernate: | - domain.hbm.xml | This may not be the 'non intrusive way' you proposed. It's not bad. I see that you mostly changed configuration files - natural thing to plug in new feature. As long as it doesn't change class files it's quite non intrusive ;) Only thing that may be not nice is the domain.hbm.xml file. The better way would be to create separate configuration file. So let's say we'll do something like core/src/resources/portal-core-sar/conf/hibernate/groups/hibernate.cfg.xml (your hibernate configuration) identity/src/resources/hibernate/identity/domain.hbm.xml (current file) identity/src/resources/hibernate/groups/domain.hbm.xml (your schema mapping) then you need to register 5th hibernate mbean using "org.jboss.portal.jems.hibernate.SessionFactoryBinder" in core/src/resources/portal-core-sar/META-INF/jboss-service.xml with name like "portal:service=Hibernate,type=Groups" So you will have your own SessionFactory and it will act like an addon to the portal schema. With such approach it will be easy to enable/disable your services without affecting default portal services The current content of identity package is quite fluent and may change a little. Another thing is that identity modules configuration will probably be moved from jboss-service.xml to separate a configuration file. There is early draft for that here but it's not very defined yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985070#3985070 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985070

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by arvinder

Kurt, thanks for the thoughts/work on this. There are some instructions on the wiki http://wiki.jboss.org/wiki/Wiki.jsp?page=ActiveMqIntegration, hope they will be of help. I am not around much (until after 19th Nov ) but i'll keep an eye out on email and groups. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985064#3985064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985064

19 years, 5 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Poor performance with test...

by clebert.suconic＠jboss.com

On the Benchmarks I have done I always ignored 100 first elements to be fair.. not computing ClassLoading as JDK classes get sometimes pre-loaded (Specially Serialization) Also.. I always used the same ByteArrrayOutputStream (by calling reset)... And of course my Java and JBoss examples were the same. I needed to be fair on both sides. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985060#3985060 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985060

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by scott.stark＠jboss.org

Yes, that is a bad idea as even for a given jms pvoider we potentially need alternate configurations. Also, what is the relationship between this configuration object and the service that binds the jms connection factories? I assume it can be a jca deployment, mbean, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985059#3985059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985059

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by kurt.stam＠jboss.com

I guess it's a tradeoff between keeping the configuration as simple as possible, and making things flexible. Right now we store the jndi InitialContext ctor env properties in that 'AppServerContext' class. I was just going to extent that for more 'AppServers'. Do you think it's a bad idea to store that info as static Strings for i.e. the naming context 'jboss'? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985056#3985056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985056

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-3766, port the webservice deployer

by scott.stark＠jboss.org

I'm thinking it should just be an attribute in the WebMetaData object. When I get a jbossas testcase working for this I'll let you know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985055#3985055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985055

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by genman

Couldn't you have statics work like this: PojoCache c = ...; c.registerClass(POJO.class); I suppose also you could do some tricks with the classloader, so a classloader would have a PojoCache attached to it. And at the time the class is loaded, it gets registered. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985053#3985053 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985053

19 years, 5 months

1
0
0 / 0

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

by bvogt

"bdaw" wrote : Sorry for not responding for so long. | It doesn't matter, I had enough other to work do ;-) "bdaw" wrote : | The whole idea of MembershipModule interface is to decouple Role and User. The reason is that in LDAP the relationship beetween them can be defined in several different ways - it's not so straight forward like in DB. So the main difference is NOT to have Role.getUsers() method. So Role and RoleModule know nothing about User and vice versa. And the functionallity is moved to MembershipModule to be able to resolve different ways of relationships just by swaping this module. | | I don't understand what .getName() method are you looking for there? | Thanks for the explanation, I thought that "Membership" was meant as a GroupMembership... Since it is not, I see that the getName() method is not needed. "bdaw" wrote : | I was discussing your ideas with julien. There are few things in this subject: | | 1) Roadmap and features for 2.6 are already defined and we don't want to change them. The things you propose can be discussed to be placed in 3.0 roadmap - there is a plan to rethink and redesign this part already. Adding groups in the shape you descrived will need some changes in management portlets and other work so it's not an option at the moment. | | 2) Still, you can implement this functionality and we can integrate it in portal codebase as OPTIONAL. So simply it won't be enabled by default, but it can be used by changing portal configuration. If you agreed on this your code will need to meet few conditions: | - it must be written in non intrusive way for what is in portal codebase. So it can't require changes to portal classes (or at least not much). | - if you use DB your code can't breake the current schema. So you will probably need to add separate hibernate configuration with own tables - not a big effort as currently identity, portal objects and security schemas are also separated. | | I think it can be easily done. You can just add Group object and GroupModule that manage the relationship with User and Role. We can advise you how to plug into hibernate and etc in non intrusive way. | | 3) It may be possible to achive what you want just by providing implementation of LoginModule. Look at org.jboss.portal.identity.auth.IdentityLoginModule. It's portal implementation that plugs into JAAS in AS. | So it could simply discover the group membership of the authenticating user and bind the relation with portal roles. | | How do you feal about it? | I feel good about it, because I know a bit about software development, roadmaps and "last minute add-ons"... But our customer needs it earlier, currently we decided to build a prototype with main business features based on the 2.4 CR1 codebase. Thanks for your solution approach, which confirms my understanding of the code. I already have the hibernate extension, group object, group module and portlet - for at least display/add/change/remove groups and display users within the group. For this I extended the common files: in: core/src/resources/portal-core-sar: - jboss-service.xml in: core/src/resources/portal-core-war: - Resource.properties - jboss-portlet.xml - portlet.xml - portlet-instances.xml in identity/src/resources/hibernate: - domain.hbm.xml This may not be the 'non intrusive way' you proposed. A few days ago I read, that the admin UI is being re-designed... therefore it's not wise to go ahead (or even commit the changes) with the portlet until the re-design has been finished. I'm interested in that design - will contact Roy? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985052#3985052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985052

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by scott.stark＠jboss.org

Why not just configure a provider URL that encompases the server, port, protocol and starting context? We have found in jboss that we also need the full jndi InitialContext ctor env properties to allow control over things like the initial context factory, object/state fatory paths, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985049#3985049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985049

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-3766, port the webservice deployer

by jason.greene＠jboss.com

Sure, I can make the changes after there is support for it. How should I pass the value, as an attachment? -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985048#3985048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985048

19 years, 5 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