[JBoss Portal] - Re: Handling Portal/Portlet Preferences
by explorer
Hai Guys,
Those are really good pieces of advice for a beginner like me.
anonymous wrote :
| For just "looking at it", you can use the hypersonic database.
| it is provided with jboss portal, and is the default database.
|
Well, Antonie talked about a hypersonic DB built into JBoss, Where is that located and how should i delete the files. There is a portal-hsqldb-ds.xml and how should i configure it.
Once again thank you very much for the help.
For PeterJ: well first i was trying to figure out where i had to put the preferences,looking at the DTDs for 2.6 i tried putting them in -instances.xml but did not work out and then i put the preferences in portlet.xml, then the preferences were picked up. Then later i figured out that the problem might be related to the error being thrown. So i started the post this way.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064562#4064562
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064562
18Â years, 12Â months
[JBossCache] - Re: CR3 Listener
by jason.greeneï¼ jboss.com
"FredrikJ" wrote :
| 1. Wouldn't this be considered a major api change(?) and as such should not go in between two cr releases?
|
Unfortunately we ran into unexpected implementation problems that the current API could not address. We had to choose between complicating the system by introducing a secondary API, or breaking API compatibility and fixing the extensibility problems that lead to this issue in the first place. We decided that overall it was better to get a solid, extensible, and easy to use API with well defined behavior in the GA. Had this issue been discovered after GA, we would have not taken this option.
Before making this change, we also posted a detailed proposal and asked for feedback from everyone.
anonymous wrote :
| 2. I understand that the benefit is that you can choose to declare only those listener methods you are interested of, thus reducing the amount of empty boilerplate listener methods. However, the downpart is that we are losing type safety here and I personally do not consider this a good bargain.
|
That is one of the benefits, although the main reason is to allow easy extensibility. In this model we can add a new notification type in a future release, and it will not break existing listeners.
anonymous wrote :
| Now, isn't this exactly why we have interfaces? An interface enforces signature and types. If we fail to honor the interface we get a nice compilation error, with the annotation based model we will get runtime checking and runtime errors.
|
As mentioned above, the interface in this particular use case is not the best fit. It can't be extended, and it forces you to choose between implementing a bunch of methods you don't care about, or polluting your inheritance tree with a JBoss Cache class. The annotation model lets you choose whatever class design fits your application the best.
You do lose compile time checking, although the API is very simple and predictable. The run-time error occurs the first time you register a listener, which should be close to immediate.
Also, I should note that this is not a unique concept. EJB3 and DI frameworks use similar concepts.
anonymous wrote :
| If we look at the list of available annotations here http://labs.jboss.com/file-access/default/members/jbosscache/freezone/doc... we can see that the input ot the methods differ. Now I have to switch between my IDE and the documentation to lookup the annotation and what the proper signature is. Should I fail to comply, my IDE will not tell me since there is no compile-time checking.
|
If you point your IDE to the JBossCache javadocs, you will be able to pull up the info without leaving it, since we put docs on all the annotations. Also there is an easy convention, all notification methods take a single parameter, and its type is the annotation name + "Event".
i.e. @NodeModified public void doSomething(NodeModifiedEvent event) {}
anonymous wrote :
| Furthermore, since there is no longer a CacheListener interface, I cannot use that interface for listener-registration in layers created on top of the cache, forcing me either into allowing Object or creating my own Listener interface which will allow me at least some typesafety. But in the end I will never really know until the cache is started and every possible listener has been registered to the cache, right?
|
Yes, although typically this occurs right away. Also usually one would test their listener before going into production, as compile time safety does not promise run-time correctness.
anonymous wrote :
| Generally I'm not opposed annotations. I think they do fill a purpose, but I can't seem understand the reasons for this particular design decision.
I appreciate your feedback, and I understand your concerns. We are still open to any ideas you have that can make this better.
Here is the trail for all the design discussions that lead to these changes:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110525
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111094
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheListenerAPIProposal
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=110911
-Jason
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064559#4064559
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064559
18Â years, 12Â months
[JBoss Portal] - Re: JBoss Portal 2.6 jsf libraries confuses my other jsf war
by hartsock
Yes, I kind of figured this was a JSF bug and that it had something to do with the class loaders and that whole Deployment Isolation thing I've been reading about. Basically I figured that some class in the portal SAR was getting in the way of "normal" JSF.
It would be nice if there was a page that new to JBoss Portal people could go to learn how to build the portal.
Per your recommendation, I've checked out a version of the Portal from here:
| http://anonsvn.jboss.org/repos/portal/trunk
|
Now then, went over to the directory that I checked out the trunk from...
... huh, no install instructions... let's check out the build directory.
Ah, there's a local.properties file under trunk/build that has a bunch of build variables that I can edit. I'll run the build like this (from the trunk directory):
| $ export JBOSS_HOME=/usr/local/jboss
| $ ./build/build.sh
|
So, where did those compiled bits end up? ARG! I have no idea...
| shawn@beyonder:~/portal/trunk> find . -name "*portal*.sar"
| ./cms/output/lib/portal-cms.sar
| ./core/output/lib/jboss-portal.sar
| ./core/output/resources/jboss-portal.sar
| ./test/output/lib/portal-test.sar
| ./wsrp/output/lib/portal-wsrp.sar
| ./core-samples/output/lib/portal-basic-samples.sar
| ./core-samples/output/resources/portal-basic-samples.sar
| ./core-management/output/lib/portal-management.sar
| ./core-management/output/resources/portal-management.sar
| ./core-cms/output/lib/portal-cms.sar
| ./core-cms/output/resources/portal-cms/portal-workflow.sar
| ./core-cms/output/resources/portal-cms.sar
| ./core-cms/output/resources/portal-cms.sar/portal-workflow.sar
| ./server/output/lib/portal-server.sar
| ./core-admin/output/lib/portal-admin.sar
| ./core-admin/output/resources/portal-admin.sar
|
Okay, spiffy, one of these must be the SAR I need to replace my "broken" jboss-portal.sar ... but that jboss-portal.sar is mighty dinky at 4.8M when the one I have deployed consumes 21M ... what's going on here? Let's explode the SAR and see what's in it.
I'll quickly make a back up copy of my /usr/local/jboss/server/default and then try and swap out the JSF libs in jboss-portal.sar with the ones from the new SAR we just made... and fire everything up and see what fireworks we can see...
...hmm... obviously I need to swap out things dealing with JSF... specifically that troublesome JSFMetaBridgeFacesContextFactoryImpl class... where did that bad boy end up? Ah, somewhere inside portal/trunk/faces/output/lib/... portal-faces-lib.jar, portal-faces-loader-lib.jar, or portal-faces.war
Somewhere down in one of those is the class I need to swap out. Woah, portal-faces-loader-lib.jar is nowhere in my $JBOSS_HOME/server/default directories...
Anybody want to clue me in on how to deploy this bad boy or do I continue to fumble around like this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064556#4064556
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4064556
18Â years, 12Â months