September 2006 - jboss-dev-forums

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by thomas.heute＠jboss.com

"dhartford" wrote : anonymous wrote : 2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it. | | Seperating out the CMS "server"/repo would definately help, not only for jboss portal but also as a seperate file-repository to develop against (aka WebDAV/JCR repo for other than just portal-CMS). | | It would be great to deploy a 'Jboss Repo' that stores the CMS content and have the jboss-portal upgrades be seperated/less dependent of the repo. Could also setup CMS-bundles that are added to the repo and point to them from jboss-portal. I am not sure to get this right, the "CMS server" is already quite independent (it is JackRabbit) with a homebrew Hibernate storage. This could be interesting to discuss over the phone during a conf call. I am not even sure you and jewhit are talking about the exact same thing. Please email me if you are interested by a call, same for jewhit. anonymous wrote : As another item, would be nice to have seperate administration/backup functionality that is domain-knowledge-specific to the repository versus the portal (i.e. portal admins deal with portal stuff, storage admins deal with storage stuff). Ok, the underlying thing is to add the notion of group i guess (on top of user/role), we already talked about it and it is something that we need to allow. anonymous wrote : | my two coppers, | -D They worth a dime ;) Thanks for your input View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972837#3972837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972837

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by thomas.heute＠jboss.com

"bogdan.sulima" wrote : Hallo JBoss Team :) | | I just started to evaluate JBoss Portal Server. You did a good job and i am looking forward to help you in improving Portal. | | XML import | | "thomas.heute(a)jboss.com" wrote : | | - Change datasource (copy data over) | | - Pages definition export from database to XML (-objects.xml, -instances.xml). | | WPS (WebSphere Portal Server) has very nice XML import/export interface (XMLAccess) that allows developers and administrators to import/export entire portal configuration or desired parts of the configuration (portlet instances, pages, users and so on). Such robust xml import/export alows you to migrate to new version of the portal, switch from one DB/LDAP to another (without creating some DB-specific scripts or dumps), reproduce portal environment to local development and so on. This is what we want to do, i don't have access to WebSphere portal though so i don't know how it works for them, but i rely on your feedback to do better ;) anonymous wrote : So the idea is quite simple: | - all the data that is stored in DB should be also configurable via xml. | - unique names (not DB ids) must be provided/generated for all portal objects. | We have that - unique names offer common and simple lookup in xml scripts, render-url generation (can be used in Themes or CMS portlets for linking to portal pages/portlets). I don't get it anonymous wrote : It is possible to merge contents of the -object.xml and -instances.xml and extend it with additional data for exporting user/group information. Such "config.xml" can evolve with the new versions of the portal, but will still contain data in quite abstract format in order to provide backward compatibility between portal versions. | We had those 2 files merged (in 2.2), Julien decided to split for WSRP. We kept backward compability though. anonymous wrote : | Portal Model | | In object.xml developer may specify custom properties for dirrerent portal nodes. Is it possible to provide read access to these properties via PortalNode interface? In this case developer can access these helpfull properties in jsp (via taglib?) or portlet without using PortalObjectContainer. | | Layout | | Is it possible to use JSP in order to create custom RenderSet? This will keep layout element consistent as jsp's. Some jsp tags can be provided to access custom properties and other objects that are important for rendering. | | Bogdan. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972835#3972835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972835

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by thomas.heute＠jboss.com

"jewhit" wrote : unfortunately, we just purchased ON so i can't say that i have tinkered with it much, but these are the things i can identify as having the most value for our organization: No worry, it's even better if you didn't look at it, you have a fresh opinion on the subject. anonymous wrote : 1) it would be nice to be able to centralize administration of user portlets rights, etc... directly from ON, as opposed to having administrators log into each portal "instance" Ok. I also think that it makes sense. anonymous wrote : 2) CMS control - it would be cool if you could deploy a single (or clustered) CMS "server" and deploy content links as required to all instances of portal via ON. this might be a bit bloated, not sure of implications and whether portal could fully handle it. You mean the existing "CMS Admin portlet" but directly from ON ? anonymous wrote : 3) directly edit / deploy all critical XML's from ON We will do that, we also need to reflect the changes without having to restart. For example adding an intereceptor means modifying a jboss-service.xml file but would only be picked up after a restart, we also need to add the interceptor dynamically. anonymous wrote : 4) to further extend on Roy's point... if i understood him correctly... it would be absolutely bitchin if porlet instances or CMS content could be archived remotely and restored from ON. Yes, it will be priority No1 for provisioning i think. anonymous wrote : 5) this has nothing to do with portal directly... but when doing major portlet / portal code changes, the database purge / data directory remove / rebuild can be a real hassle... especially in heavy prototype / production enviornments. would it be possible to utilize ON to at the minimum "reinsert" users and roles upon redeployment... or at the click of a button in the console ? obviously, permission associations to portlets can't be restored, as portlets / portal deployment may change, but the ability to resync users and roles would be a big help. it sure beats having to create sql scripts manually to reinsert. This is more a development related thing, so not really something for administrators. This would have to be part of some "tools" any volunteer to work on the IDE that a contributor started ? I agree that we can improve on that. anonymous wrote : these are the things i can think of offhand. maybe some of these things are already possible. I will throw more things at you once i get ON installed and running... or at the minimum after i go to the roadshow tomorrow. i would guess we will do our own install late this week / early next week for our test servers. | | thanks | JW Thanks a lot for your valuable input ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972833#3972833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972833

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: does optimistic locking always work ?

by mteira

I didn't find a way to do that using JPA and Entities (the only way to lock an entity seems to be the EntityManager.lock() method, and that's just playing with the entity version, and worse than that, adquiring the Entity using EntityManager.find() and locking it are two separate calls, so we cannot make it in a atomic fashion). I expect that using Hibernate directly, there should be a way to adquire a persistent object in a fashion that maps into the DB query as a 'SELECT FOR UPDATE' clause or equivalent. But, is it correct to call this 'optimistic locking' anymore? Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972832#3972832 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972832

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: exception in HellowIPCportlet

by thomas.heute＠jboss.com

Wrong forum, moving topic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972831#3972831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972831

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Roadmap: jBPM integration.

by thomas.heute＠jboss.com

Wrong forum. Moving the topic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972830#3972830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972830

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by thomas.heute＠jboss.com

"roy.russo(a)jboss.com" wrote : One more point: XML Export of the portal config That's what i meant by "Pages definition export from database to XML (-objects.xml, -instances.xml)" it's good to define it better though. anonymous wrote : and even a versionable snapshot that I can rollback if need be. Also helps enterprise customers move their staging env to production without having to synch DBs. For versionning, shouldn't it be the administrator responsibility ? If he can get a dump of the current state of the portal at different time, he can restore the portal to whatever version he wants anonymous wrote : Thomas, do you know how much of this will be made available through ON, exclusively? No, we have to define what makes sense in ON and what makes sense in the portlet, those are 2 different concept. All monitoring (Statistics) will be in JON of course. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972829#3972829 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972829

19 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @EJB Injection Not Working

by sbublava

I fell into this trap myself. You need to use javax.ejb.EJB not javax.annotation.EJB ... Thanks, Stephan View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972828#3972828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972828

19 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: WANTED: Input from administrators & developers

by orionyiu

A "delegated administration" function, that is the ability to assign the right to a user to administer certain portal pages or portlets. Right now the administrator can manage the entire portal. However, in many organizations they would like to manage the portal at least at a departmental level. An inheritance concept, that is if a user can administer a page he/she could administer the portlets/pages underneath it would be helpful too. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972813#3972813 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972813

19 years, 6 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - change to client leasing

by tom.elrod＠jboss.com

Due to a bug with remoting regarding now client leases are managed (see http://jira.jboss.com/jira/browse/JBREM-596), the latest code base has been changed so that client leases are managed by the client invoker and not the Client classes themselves. In doing this, some behaviors related to configuration have changed slightly and am listing them here for any feedback. 1. The 'lease_period' property can be set per Client so if different clients have different values for this property, the client invoker needs to have defined rules for how to handle this. The rule I currently have defined is the lowest lease period (whether it be via Client's lease_period config or the one provided by server) wins. Then if a Client is disconnected, the next lowest lease period will be used. ... well, guess that's it. Everything else remains the same. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972805#3972805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972805

19 years, 6 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 September 2006