Re: [jboss-user] [JBoss Tools Development] - Portlet Development is Effectively Unusable in JBoss Tools
by Robert Brown III
Robert Brown III [http://community.jboss.org/people/factor3] replied to the discussion
"Portlet Development is Effectively Unusable in JBoss Tools"
To view the discussion, visit: http://community.jboss.org/message/554546#554546
--------------------------------------------------------------
Actually, I had an OK weekend, since I was attending the memorial service of a friend/brother who recently passed away. It could have beenbetter -- but it could have been worse. Thanks for asking.
Anyway, yes I did download and utilize what should be a Portlet runtime: the JBoss (Gatein) Portlet Container runtime. I chose it because I needed to have a more lightweight system for development on the machines that I was using. This is structured like the full JBoss Gatein Portal, the only difference was the .WAR file(s) that are deployed to it.
I would consider it a bug if the portlet component checker in the JBoss Tools plugin(s) did not recognize the Portlet Container as a legitimate Portlet runtime. It runs like a JBoss Portlet and even displays JBoss Portlet pages, and you can deploy portlets to it using the same methods as you would using the full Portal. Consequently, in my opinion if the Tools do not recognize the container as a real portlet runtime, then this is definitely something that should be rectified.
Of course, I am not working on this stuff so it isn't my call. I can only suggest...
As for the alternative: I did deactivate the "check runtimes... " checkbox and the portlet facets appeared. And frankly, I agree: you probably should make this disabled by default. Not just because of the confusion, and the fact that the documentation doesn't say a word about it, but because this check ties users into developing/testing portlets only for JBoss. If someone wants to make a portlet that can work under any Portal (which is what JSR-286 portlets are supposed to be able to do) the "check runtimes... " selection will make it impossible to test the portlet on other environments from within Eclipse. In other words, that selection is providing a form of "vendor lock- in" that you people are supposed to be avoiding.
Unfortunately, there is another problem that I am encountering that is not in the documentation: the problem of having to select "user libraries" where none are available.
There is a window in the Wizard called "JBoss Portlet Capabilities" where Eclipse tries to force me to select a "user library" in order to complete the portlet facet. I find this to be extremely annoying for two reasons: (1) I thought I was including the necessary libraries for portlets when I configured the facet in the first place (compare this wizard with the one provided by the Eclipse Portal Pack plugin which works with Webspace). An Eclipse facet is supposed to provide this kind of dependency automatically when selected (Eclipse Portal Pack certainly does!), so why the necessity for pointing to a user library??? (2) when this window comes up it displays an empty list of user libraries. So where am I supposed to find the user libraries that are required???
I consider this a definite bug and a sign of improper implementation of an Eclipse facet. At least, you need to update the documentation so that a user can find and point to wherever the required JAR files are. A more acceptable solution would be to at least put the names and locations of appropriate user libraries into the Wizard so that a user can select one of them. Of course, the best solution would be to eliminate the "Portlet Capabilities" window entirely and create a proper facet that includes the correct libraries in the classpath when it is selected.
In summary: I thank you for your help and information, but despite it JBoss Tools is still unusable for portlet development, as far as I can tell. Unless, of course, there is more information about the portlet setup that I am unaware of...
Please advise.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/554546#554546]
Start a new discussion in JBoss Tools Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
[jBPM] - in jbpm 4.3, timer not firing to leave its state node.
by Tun Mang
Tun Mang [http://community.jboss.org/people/tunmang] created the discussion
"in jbpm 4.3, timer not firing to leave its state node."
To view the discussion, visit: http://community.jboss.org/message/554539#554539
--------------------------------------------------------------
Hi :
There is a timer session configured in my "jbpm.default.cfg.xml" as shown below:
....
<timer-session />
....
The core of the process definition is very simple as shown below for the timer to fire and leave the state node:
<state g="222,123,147,40" name="generate-file">
<transition g="-71,-15" name="timeout" to="remove-file">
<timer duedate="5 seconds"/>
</transition>
</state>
The next node is an action to dump message to prove the process leaving and entering a new node.
When I run it, it never leaves the state node, but the jbpm database shows a pair of parent-child entries created:
----------------------------------------------------------------------------------------------------------
DBID Activity ID State
----------------------------------------------------------------------------------------------------------
1210001 generate-file test_Timer_1.1210001 inactive-scope
1210001 generate-file test_Timer_1.1210001.generate-file active-root
----------------------------------------------------------------------------------------------------------
Is it because something missing in the "jbpm.default.cfg.xml", so it won't fire and leave ? or something else ?
Thanks for your help in advance.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/554539#554539]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months