[JBoss JIRA] Updated: (GPD-216) jBPM build destroys user eclipse installation
by Koen Aers (JIRA)
[ https://jira.jboss.org/jira/browse/GPD-216?page=com.atlassian.jira.plugin... ]
Koen Aers updated GPD-216:
--------------------------
Fix Version/s: jBPM jPDL Designer 3.1.4
> jBPM build destroys user eclipse installation
> ---------------------------------------------
>
> Key: GPD-216
> URL: https://jira.jboss.org/jira/browse/GPD-216
> Project: JBoss jBPM GPD
> Issue Type: Bug
> Reporter: Thomas Diesler
> Assignee: Koen Aers
> Priority: Critical
> Fix For: jBPM jPDL Designer 3.1.4
>
>
> [13:09:35] Thomas Diesler: The bpm build destroys my eclipse installation
> [13:09:47] Tom Baeyens: ouch
> [13:10:07] ... which target did you use ?
> [13:10:19] ... that should not happen
> [13:10:33] Thomas Diesler: [tdiesler@tddell jpdl]$ /usr/java/eclipse/eclipse
> bash: /usr/java/eclipse/eclipse: No such file or directory
> [13:10:51] ... the default target
> [13:11:03] Tom Baeyens: in the build dir ?
> [13:11:31] Thomas Diesler: it seems to remove my eclipse executable and copies some windows .exe into the eclipse dir
> [13:11:47] ... yes, int the build dir
> [13:11:48] Tom Baeyens: i'll look at it right away
> [13:11:57] Thomas Diesler: 3.2.2.GA
> [13:12:48] Tom Baeyens: i know we have targets that can create an eclipse installation, but it should definitely not be in the default build
> [13:14:24] Thomas Diesler: on a linux system, it should never copy eclipse.exe
> [13:14:33] Tom Baeyens: right
> [13:17:17] Thomas Diesler: # the eclipse home property has to end with 'eclipse' since the folders in the eclipse
> # distribution package start with eclipse and that package will be unzipped in
> # ${software.installation.dir}/eclipse/..
> # preferrably
> eclipse.home=${software.installation.dir}/eclipse
> [13:18:54] ... phu ... I think I need to nuke my eclipse install and rebuild it again, adding all my plugins
> [13:21:59] ... also, the build cannot assume a certain eclipse version, can it?
> [13:31:48] Tom Baeyens: i verified it with koen
> [13:31:59] ... it's different on head
> [13:32:08] ... but still an extra check needs to be added
> [13:32:26] ... basically the eclipse is needed to build the process designer
> [13:32:41] ... but the jbpm build should not build the process designer from source
> [13:32:49] ... instead it should be taken from the repository
> [13:33:22] ... that's why on head, the gpd should not be build from source
> [13:33:41] ... apart from that, an extra check will be included (koen will make a jira for that)
> [13:34:02] ... that check will see if the eclipse installation present is one created for the build or another one (like yours)
> [13:34:19] ... if it finds another eclipse installation, the build will fail
> [13:34:47] ... (currently it wipes the eclipse installation)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Updated: (GPD-179) pages.xml doesn't work with pageflow editor
by Koen Aers (JIRA)
[ https://jira.jboss.org/jira/browse/GPD-179?page=com.atlassian.jira.plugin... ]
Koen Aers updated GPD-179:
--------------------------
Fix Version/s: (was: jBPM jPDL Designer 3.1.4)
> pages.xml doesn't work with pageflow editor
> -------------------------------------------
>
> Key: GPD-179
> URL: https://jira.jboss.org/jira/browse/GPD-179
> Project: JBoss jBPM GPD
> Issue Type: Bug
> Components: jpdl
> Reporter: Max Rydahl Andersen
> Assignee: Koen Aers
>
> a pages.xml with a proper page flow syntax does not have the pageflow editor in the right click menu.
> and when using Open with... and choosing jBpm pageflow designer (not the correct name is it ?) I get
> java.lang.NullPointerException
> at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addProcessDiagramDimension(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowContentProvider.addGraphicalInfo(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowGraphicalEditorPage.initInput(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowGraphicalEditorPage.init(Unknown Source)
> at org.eclipse.ui.part.MultiPageEditorPart.addPage(MultiPageEditorPart.java:186)
> at org.jbpm.ui.pageflow.editor.PageFlowEditor.addGraphPage(Unknown Source)
> at org.jbpm.ui.pageflow.editor.PageFlowEditor.createPages(Unknown Source)
> at org.eclipse.ui.part.MultiPageEditorPart.createPartControl(MultiPageEditorPart.java:283)
> at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:661)
> at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592)
> at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:263)
> at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2721)
> at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Created: (JBADMCON-154) Internationalisation (i18n) patch for web- and jmx-console
by Sean Flanigan (JIRA)
Internationalisation (i18n) patch for web- and jmx-console
----------------------------------------------------------
Key: JBADMCON-154
URL: http://jira.jboss.com/jira/browse/JBADMCON-154
Project: JBoss Admin Console
Issue Type: Patch
Environment: Developed and tested under Red Hat Enterprise Linux 5.1
Reporter: Sean Flanigan
G'day all,
I'm part of the Red Hat internationalisation team, and I've been working on internationalising the JBoss consoles (web and JMX, not the new admin-console). I was initially working against EAP 4.3, but we decided that we should be following the standard practice of starting with jboss.org, and later putting it into jboss.com releases (like the Fedora->Red Hat process). So I have ported my i18n work to the consoles in AS 5. Fortunately for me, these consoles haven't changed much in years.
I am attaching a patch with my internationalisation changes. I'm still waiting on some actual translations from the localisation team, but in the meantime I have generated a simple pseudolocalisation for the locale 'xxx'. If you run the consoles and select the 'xxx' locale, any _static_ text which is still in English but doesn't have lots of "x"s is probably an internationalisation bug. (Dynamically generated text such as MBean information or System properties will not be translated, but labels and headers should be. Note also that the applet will appear in the default language of the server, not the locale of the browser-user. At least for now.)
It's not included in this patch, but I have also written an Ant task (Regex2PotTask) which can extract English strings from JSPs which use the scheme described below, and an Ant build script which can run Regex2Pot to extract English, and later convert translated PO files into ResourceBundles (using the native GNU gettext utility "msgcat"). For now, internationalisation is a step which is separate from the build process, and my Ant script doesn't even live inside the jbossas directory tree.
Perhaps internationalisation should be kept separate from development concerns. As I said above, "msgcat" is a native utility. I believe Cygwin has a version of msgcat, but I'm not sure how well it would fit into the JBoss build. So integrating string extraction and conversion might be a lot of work. I would appreciate any advice. Or even some help!
Known issues:
1. String extraction and conversion is separate from the JBoss build process. This may or may not be a bad thing.
2. String conversion is not pure Java - it requires "msgcat" from the GNU gettext utilities. It should be possible to write a pure-Java replacement. This would probably be a requirement if we wanted to integrate i18n into the JBoss build.
3. The console applet is always in the server's default locale. At present, a lot of the strings shown in the applet are generated in the server, so the applet is forced to use the server's locale in all cases for consistency. I think the strings in question are transferred over JMX, so I'm a little afraid of breaking the JMX semantics. I could either add a Locale parameter to all of the affected JMX calls, assuming I can find them, or perhaps try to defer the ResourceBundle lookup until the last minute, on the client-side. It may not be worth it, since I suspect the average JBoss installation will only be administered in a single language.
4. JBoss AS's log messages and error messages are still in English. That's another project!
Regards,
Sean.
Technical explanation follows:
Technical details:
The JSPs are internationalised with the help of an entity resolver for the unified expression language (EL). The approach was partially inspired by the Seam i18n mechanism, and looks like this:
<title>JBoss Management Console - Server Information</title>
becomes:
<title>${messages["JBoss Management Console - Server Information"]}</title>
The entity resolver also supports MessageFormat arguments:
<h1><center>${messages["J2EE Application ''{0}''"][appName]}</center></h1>
For plain-Java code called by the JSPs (or embedded in scriptlets), there are some facade classes in front of ResourceBundle, whose main purpose is to handle missing resources/bundles more appropriately. These facades are in the classes org.jboss.console.I18n and org.jboss.jmx.console.I18n, along with a servlet filter, the entity resolver and other helpers in the package org.jboss.varia.i18n.
Technical rationale:
I really, really tried to use a standard mechanism for internationalising plain-old-JSPs, particularly JSTL, but in the end I had to make something which was inspired by the Seam i18n mechanism: an EL entity resolver which looks up ResourceBundles and formats messages with dynamic values.
I had a few main goals:
1. make things easy for programmers: don't make the code hard to read or maintain.
2. fit in with Red Hat's translation workflow: we need to be able to extract English text to GNU "gettext" POT files.
3. no cheating: don't add scriptlets to the JSPs
4. don't break JBoss!
For point 1, I think it's very important to keep the English text in the source code, which is where developers are used to seeing it.
Externalising the English text into ResourceBundles, with artificial keys like "label.OK" is definitely the default option in Java, encouraged by Sun's JavaDocs, but it is fairly unusual in open-source internationalisation outside Java-land. Managing artificial string keys (creating, purging, ...) is quite difficult in a closed corporate setting, and even harder in the case of distributed development. I know IDEs like Eclipse have tooltip support for looking up ResourceBundles, but only if you fit into the Eclipse i18n scheme. Unfortunately, the Eclipse i18n scheme is a little too closely-coupled to Eclipse's needs. (For instance, it doesn't really support the idea of a server whose clients are using different locales.)
For point 2, Red Hat's translation team is used to working with "gettext" POT/PO files, with translation editors and other infrastructure which process them. Gettext also provides a number of command-line utilities which help with merging and cleaning translation/PO files. The approach I chose *does not* use gettext at runtime, nor depend on gettext jars, but it does allow for gettext POT files to be extracted from the source code, and to generate ordinary ResourceBundles (.properties) from the translated PO files.
As for point 4, I mentioned that the i18n effort was initially intended for EAP 4.3. This is part of the reason I avoided adding runtime dependencies.
Re: Testing - where possible, I have tested things myself, but I don't have the expertise to exercise the consoles fully. In particular, I couldn't get the JMS-related pages to work, even without i18n changes - they seem to depend on extra JMS jars being available; even then I would need to create JBoss MQ channels before the page will render without errors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years
[JBoss JIRA] Created: (JBREM-1010) Add feature to declaratively turn on leasing for 2.2.2
by Jay Howell (JIRA)
Add feature to declaratively turn on leasing for 2.2.2
------------------------------------------------------
Key: JBREM-1010
URL: http://jira.jboss.com/jira/browse/JBREM-1010
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: general
Affects Versions: 2.2.2.SP7
Reporter: Jay Howell
We have a request to declaratively turn on leasing. Currently you can only do it via debugging.
Here's the conversation from Ron so far. It says more than I could.
--------------------------------------------------------------
The problem lies in org.jboss.aspects.remoting.InvokeRemoteInterceptor, which (1) opens an org.jboss.remoting.Client, (2) makes the invocation, and (3) closes the Remoting client. I guess that's because there's no notion of a "session" or a "lifetime" with EJBs, so there's no other natural place to close the Client.
The other part of the story is the relationship between Client and the actual invoker, org.jboss.remoting.transport.socket.MicroSocketClientInvoker in this case. Multiple Clients connected to the same server will share an invoker, increasing its reference count. So if multiple threads were calling on the same EJB at the same time, closing the connection after an invocation wouldn't close the MicroSocketClientInvoker (and its cache of connections) if another thread was in the middle of another invocation.
The gap in my explanation is the lack of evidence of multithreading in the example. I don't know what method1() is doing. But if there were some simultaneous processing going on, then enabling leasing would add an extra invocation to the process of connecting and disconnecting, thereby changing the timing of things, which might then lead to keeping a MicroSocketClientInvoker alive long enough to be reused.
Unfortunately, there's no declarative way to turn on leasing. Just an oversight, I guess, and it's never come up so I never thought about fixing it. I could, though.
However, there's a more direct approach. I put a feature in Remoting 2.4 which makes it possible to configure Client.disconnect() to delay the destruction of the client invoker by putting it in a TimerTask: JBREM-877 "New Socket Connection is being Created for Every Client Request to the Server". On the EJB3 forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130264, I asked the EJB3 guys to create a JBPAPP issue if they wanted the same feature in Remoting 2.2, but it never happened so I never did it.
Since it's certainly a Remoting feature, and not really an EJB3 bug, I guess it's a judgment call whether to go ahead and make the change in Remoting 2.2. But Jay, if you create the JIRA issue(s), I'll be happy to do it and attach a preview jboss-remoting.jar.
--------------------------------------------------------------
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years