JBossDeveloper

Here you will find description of the elements which can be managed via xmlaccess.

"http://publib.boulder.ibm.com/infocenter/wpdoc/v6r0/topic/com.ibm.wp.ent.doc/wps/adxmlabt.html"

After a few days working with jboss portal i still missing xsd or dtd for confgiuration files.

What the exported configuration going to look like - do we really want to export many different configuration files (object.xml, instances.xml, jboss-portlet.xml and so on)? I like "all-in-one-file" solution for export/import. When portlet is deployed, it can be still configured with multiple files.

Admins also need some way to trace import/export failures or warnings. Separate responce file (can be configured with jboss app server logging) (might be olso one responce file per import/export activity) can be used to achieve this - i am not happy with the current console logging.

It would be cool to perform import/export via the admin portlet. Each content node can get an "export" button that exports configuration of the selected portal node, child objects (pages, windows) and objects the node depends on (portlet instances, layout).

As portal role-based administration evolves, kind of configuration changes log is required - we need to know "who-what-when" changes portal configuration.

p.s.: lets define some sticky name for xml import interface.

just curious, has a general consensus been reached regarding what functionality will be proposed in future versions of ON through this discussion ?

Hi JBoss Team,

first thanks for putting so much effort in improving Jboss portal so fast!

I am evaluating this product along with others like Liferay and Google Portal. I do have some aditional suggestions, if pertinent. A lot was said so far so forgive me if I am being repetitve.

- Layout: It would be interesting to be able
1) to order the tabs in the portal. Right now, if the first letter of the page name is in caps, the order is automatically alphabetical.
2) to choose a layout in a drop down list. For example: 2 collumns (left 40%, right 60%), 2 collumns (left 50%, right 50%) and so on. This would enhance the personalization features of the portal.
3) to upload a company logo whithin the themes offered. By this I mean that I could maintain the theme and layout offered but change the JBoss Portal Logo to my company logo without having to create a new theme and hard core the new reference to the logo. This would even give me flexibilty to create my own theme and re use it within my company.

- Security:
1) I haven't explore that feature yet in Jboss but I didn't notice in the administration page a feature where I can set a group of users to see, edit or configure a portlet. I am suggesting that perhaps the granulatiry of the security could be in pages or portlets too.
2) It would be interesting to add in the documentation, if it doesn't exist, a topic on how to conifigure the portal to SSO.

Thanks for asking us for suggestions!

--Mariella.

"mmontoni" wrote:
1) to order the tabs in the portal. Right now, if the first letter of the page name is in caps, the order is automatically alphabetical.

"mmontoni" wrote:

2) to choose a layout in a drop down list. For example: 2 collumns (left 40%, right 60%), 2 collumns (left 50%, right 50%) and so on. This would enhance the personalization features of the portal.

"mmontoni" wrote:

3) to upload a company logo whithin the themes offered. By this I mean that I could maintain the theme and layout offered but change the JBoss Portal Logo to my company logo without having to create a new theme and hard core the new reference to the logo. This would even give me flexibilty to create my own theme and re use it within my company.

"mmontoni" wrote:

1) I haven't explore that feature yet in Jboss but I didn't notice in the administration page a feature where I can set a group of users to see, edit or configure a portlet. I am suggesting that perhaps the granulatiry of the security could be in pages or portlets too.

"mmontoni" wrote:

2) It would be interesting to add in the documentation, if it doesn't exist, a topic on how to conifigure the portal to SSO.

hi, i'm planing use jboss portal and server like a service for a proyect.

CMS admin, it would be nice to create instances with permisions to diferent folders by user and roles.


ADMIN, create/edit/delete portal instances, editing the portal instance database.


SECURITY: portlets permision by roles.


PORTLETS: posibility to start maximized

STAGING ENVIRONMENT
I dont really know whether this should be posted to JBoss ON or to JBoss Portal, but I find it rather an administration oriented architecture aspect.

Many Web-CMS solutions offer an editorial or staging environmet as part of the production environment where you can preview changes before they go live.

The JSR170 has the idea of versioning and on top of that staging is built.

In my opinion, if all pages and all layouts of the portal would reside in the JCR, then it would be posible for editors to easily add new pages to the portal or move around portlets, previsualize and have an optional workflow of aproval (jBPM) and then someone with the appropiate rights would just press a "publish" button and make the changes live.

Notice that here no developer is required. The editor team would just for example add a christmas offer on the homepage of the portal and link to a new page explaining the offer, all done with the current portlets available.

All of this, without managing strange XML exporting and importing... the JCR already provides a versinable storage in an elegant way.

Also, having the pages defined in the JCR would allow easierly to manage for example the validation of internal links inside HTML sections.
Portlet preferences may be stored in the JCR too.

Its all about changing the DAOs to store in JCR instead of DBs and XML files... and we get all the benefits of permision, versioning, workspaces, sibling, ,subscription to events, etc from JCR.

I am missing something?

Thanks for all your extraordinary products.

I hope this is part of monitoring and my post is proper for this topic.

It's about managing the content more than the instance itself, but as we may use the content to structure and build a portal, the frontier between content and jboss portal instance is difficult to fix.

The feature wished : To be able to import and export all, or part of, the JCR folders and files from dev instance to QA instance, then from QA to prod instance.
This to be able to deploy the portal to prod easily but also in a reliable way.
This is a "small" feature, but would be very usefull for provisionning.

in 2.4, when trying to export and import :
- the Title and Description are not exported in the zip file.
- the files in multiple languages (en, fr, sp...) can be exported only in one language one at a time. Need to replay the export and import for each languages.

so it is very complicated to move part of the JCR from dev to prod. And Title and Description can't be used.... as they are lost on the way.

Practical short term ideas/proposition to enhance the export feature :
- Title and Description : Could this be done with a xml descriptor of the archive export file ?
- multiple languages in one archive file : fork the folders a the root level of the exported folders, one for each languages ? Or fork the archive file, one for each language ?
- All this with options to ask the export with these "add on" in the archive, or just the plain files as it is now ?

I have seen no Jira on this ?
is it not planed yet ?
shall I post one ?

May be there are tools related to JackRabbit doing this ?

To be able to deploy the portal in a safe, reliable way, I am planning to develop something for when my project is ready to go to prod.

Thanks for this great portal !

Hello,

back to this post, when looking at the JBoss ON monitoring features...

I noticed something : about the xml export/import of the portal description.

I think the whole thing may be seen an other way.

Situation :
Since the begining, I understand it is an easy way to provide admin interface.

and I understand very well it is important that new people that want to give a try to JBoss portal can play around with the portal. Out of the box.

and even for dev, the admin GUI is very usefull for prototyping.

Since the begining, I don't like this database ;-)....
I don't understand why "all this"...

Problem :
1) no use of it, for portal that goes to prod
For a portal in prod : the new pages/windows/portlets will go through a intensive integration and testing work.

No "dev to prod" team will use the admin interface to modify anything.

They will work on the War/Sar given by the dev (after testing), and so every thing rely on the xml descriptor.

in a "simple portal" in prod : minimum integration and testing are done : if there is a problem, it goes back to the dev team for resolution.

in big portal, in big companies : huge integration and testing process, with at least a step into a stagging environement, etc...

So relying of War/Sar (with xml descriptors in it) is much more easy than [War/Sar + database]

(that's why I don't use the database... never... just playing with the GUI, once in a while, when a new version comes out... just to see "what's new"...)

2) the database is a problem in dev to prod cycle
dev to prod is a cycle, going back and forth till the new things works fine.
so having each time to "carry a database" is a burden

3) no database to run a portal

the users in a LDAP
the cms in a... cms legacy or other choice of the company (open source... or vendors).

... and no database for running a portal.

Out of 3 portal I worked on, 2 where from the start on this architecture.
one : users in legacy system, cms = Filenet
second : users in ldap, cms = legacy + choice for a new one going on
third : my own... will use ldap and a cms like Alfresco or Nuxeo, as soon as I can

so, I guess having a portal that avoid to ask for a special "one more database" is a good thing.

4) a burden for HA and admin to monitor this "one more database"
For dev, having a "one more database" is easy...
for prod, it has a cost : one more thing to care at
- architecture of system
- install, integration tests
- monitoring
- writting procedures for SLA, case of failure management

when it comes to HA and clusters of database ... work and cost is increasing :
- multiplication of database server
- multiplication of things to monitor on every day supervision
a lot to take care of every days

Resolution proposal

To consider the database way of working as an option.

Make the portal work only with the descriptor

Admin GUI on files (the war/sar files) :
- read only, for checking things (debug, etc...)
- write : on a special storing place, to then get the files (or a part of one file) and integrate in the dev working files.
- write can be done later... not fundamental... and quite complicate for storing somewhere and then impact the dev files

Admin GUI on database :
- optionnal (separate package for easy installation and desinstallation)
- for out of the box and discovery : what a nice portal !
- prototyping : working with marketing/operationnal on the design, for a proof of concept when "selling a project", etc...

As far as there is a export/import feature... make the database an option is an interesting "next step".
For prod and big portal in companies : it is a good thing.

ok, that's a long post : you understand that "since the beginning, I don't like this database".
now, after a few portal and real prod situation in companies, with cluster for HA, I know why I don't like it.

I don't like it, but I agree the Admin GUI is a major feature for "out of the box" portal. This is very important as for any open source project.

The idea is to find a way to comply to both needs : out of the box, and a portal that is built for prod

hope it helps (whatever is my personnal "I like")...

dario.liberman sayd aboud staging envionments and is quite wanted feture for production environment. Allmost all portal teams have authors and editors, and matherial get published after editor's review. It is nice idea from blogs and CMSes. Sure, this can be solved by many other ways but having such feature clearly defined and documented is good idea.

Another good idea is clear separation of public and member's content and controls. It can be understood wider - we need separate portal contents and controls for different user groups. In many cases editors and admins must publish diffirrent informayion to specific user group and user may address his posting to different groups.

I'm not sure it is exactly portal issues but portal centanly must support such operations.