Chris,

Firstable, while the hyperlinks you posted in your message point to several 
documents and articles, no one of them doesn't respond to my questions. I 
patiently red these several dozens of unrelated document and I can tell you 
that none doesn't explain neither what the "*" in the *-objects.xml stands for, 
nore why once a potlet deployed, one is not able anymore to change the name in 
the file jboss-app.xml and to redeploy the portlet. Of course, I have red these 
documents before having posted my question.

Second, as you claim having red my message, it doesn't seem so. If you did, you 
would have understood that the problem doesn't have anything to do with 
Richfaces. But, in order to give to an eventual interlocutor as much details as 
possible, I explained that the application I was talking about has beed 
originally generated by the JBoss Portlet Bridge maven archetype.

Third, complaining about the poor quality of the products, even if there are 
"free", is absolutelly natural, given the huge publicity campaign you're doing 
to show how great JBoss stuff is. But from my personal experience, as well as 
the one of my colleagues at Simplex Software, a company having several very 
competent architects and developpers Java/J2EE, JBoss stuff could be 
successfully used in the simples cases, for small prototypes. But as soon as 
one needs to use them in "real life", lots of bugs apear, preventing the user 
to really take advantage. And the thing you're calling at JBoss "documentation" 
doesn't help.

We, as architects and developpers, we are aware by the fact that we don't have 
to build strategic solutions based on this kind of products, unless we are 
subscribing to your support services, in which case the total cost of the 
operations would be higher than if we were be using commercial, well documented 
products. But the management is taking "ad literam" JBoss advertizing and 
thinks that a software company may really dramatically decrease the costs by 
using a free application server and portal server. Which is not the case 
because a big effort is required in order to get things working. 

For example, in 2006 we started a portal project and, as BEA customers, we 
naturally wanted to continue using WebLogic Portal which has given to us 
entirelly satisfaction. But management forced us to use JBoss Portal because 
it's free. We spent several weeks trying to get things working and during this 
time we weren't focusing on our project. After several weeks, we went back to 
WebLogic Portal and Workshop. Now we started a new project wirh JBoss Portal 
and, as things are going, there is a very strong probability that in a couple 
of weeks to go back to BEA/Oracle stuff.

Instead of writing you're long message you could simply give the answers I was 
waiting for. But in this case we wouldn't of course buy consulting from JBoss. 
As a matter of fact, if the documentation is well done and if the forum gives 
people the answers they need, who would buy anymore consulting from you ? This 
is to say that JBoss products are free as well as they don't work and there is 
not any know-how. But if one wants them to really work, well, in this case they 
are not any more free, they become even more expansive than the comercial ones.

Now, to come back to my questions, please don't bother too much. It apears that:

i) the "*" in front of -object.xml stands for nothing.
ii) the problem that I signaled concerning the changes in jboss-app.xml 
preventing the deployment to function properly is related to the chaotic 
management by JBoss Portal of associations between portlet and portlet 
instances.

As far as I'm concerned, I won't ever go live with something like that.

Kind regards,

Nicolas

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4177327#4177327

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4177327
_______________________________________________
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to