November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBFORUMS-230) configure JavaBuilder into .project files

by Luca Stancapiano (JIRA)

configure JavaBuilder into .project files ----------------------------------------- Key: JBFORUMS-230 URL: http://jira.jboss.com/jira/browse/JBFORUMS-230 Project: JBoss Forums Issue Type: Patch Affects Versions: 1.0.1 RC Environment: jboss forums from http://anonsvn.labs.jboss.com/branches/forums101P26 eclipse 3.2.2 Reporter: Luca Stancapiano Assigned To: Ryszard Kozmik Fix For: 1.0.1 RC hi ......I think is better to configure .project files to build with eclipse as jbossportal does.....So is simpliest to build sources with eclipse. I added theese rows into .project files of forums project and authz-jaae-plugin project. Tell me if you are agree: <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> -- 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

17 years, 1 month

2
13
0 / 0

[JBoss JIRA] Created: (JBFORUMS-254) ClassCastException in org.jboss.portlet.forums.ui.PortalUtil in function getPoster

by Lukasz Wiktor (JIRA)

ClassCastException in org.jboss.portlet.forums.ui.PortalUtil in function getPoster ---------------------------------------------------------------------------------- Key: JBFORUMS-254 URL: http://jira.jboss.com/jira/browse/JBFORUMS-254 Project: JBoss Forums Issue Type: Bug Affects Versions: 1.0.0 GA Environment: JBoss Portal 2.6.1.GA bundled with JBoss AS 4.2.1 and integrated with OpenLDAP Reporter: Lukasz Wiktor Assigned To: Ryszard Kozmik In class org.jboss.portlet.forums.ui.PortalUtil in function getPoster() userId is casted to Long. That causes ClassCastException when userId is for example type of String (in LDAP). 2007-10-04 15:35:07,700 ERROR [org.jboss.portlet.forums.ui.JSFUtil] org.jboss.portlet.forums.ui.JSFUtil java.lang.ClassCastException: java.lang.String at org.jboss.portlet.forums.ui.PortalUtil.getPoster(PortalUtil.java:467) ... It prevents from e.g. creating new topic. See my posts on the forum. I have proposed the solution. -- 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

17 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBFORUMS-263) French translation

by Luc Boudreau (JIRA)

French translation ------------------ Key: JBFORUMS-263 URL: http://jira.jboss.com/jira/browse/JBFORUMS-263 Project: JBoss Forums Issue Type: Patch Components: Forum View Layer Affects Versions: 1.0.1 RC Environment: Any Reporter: Luc Boudreau Assigned To: Ryszard Kozmik Priority: Optional Here's a french translation of the forum. The web.xml file also has to be modified to tell the forum webapp that the 'fr' locale is supported. WARNING. It is useless to apply this patch unless the graphics are also translated. I've added a comment on this matter on JBFORUMS-151. It looks completely ridiculous to translate the text and not the buttons, since these don't have any link equivalents. Therefore, I would also like ton contribute images of translated buttons, but in order to do that, I'll need the original image files. Working with GIF files is a sure failure to produce even fair quality work. This translation IS NOT FINAL. I've advised your team that some strings are not present in the bundle and should be added to it before I submit a final version of this translation. You can find details on this at : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=120699 -- 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

17 years, 1 month

2
9
0 / 0

[JBoss JIRA] Created: (JBAS-4957) We shouild always look at the old MDB metadata for JMS MDBs

by Adrian Brock (JIRA)

We shouild always look at the old MDB metadata for JMS MDBs ----------------------------------------------------------- Key: JBAS-4957 URL: http://jira.jboss.com/jira/browse/JBAS-4957 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3 The change in jboss-head to only look at the old JMS tags in ejb-jar.xml (like message-destination-type) when there is no mesaging-type is invalid. We still need to look at the old tags (EJB1.1/2.0) even if there is a messaging-type (EJB2.1). The user should be able to choose to use the old tags or the activation-config-properties. -- 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

17 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4959) Need to parse the activation-config-propertys in the invoker-proxy-binding for MDBs

by Adrian Brock (JIRA)

Need to parse the activation-config-propertys in the invoker-proxy-binding for MDBs ----------------------------------------------------------------------------------- Key: JBAS-4959 URL: http://jira.jboss.com/jira/browse/JBAS-4959 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3 We still need to parse the activation-config-propertys in the invoker-proxy-binding for EJB2. This is currently not working because the ActivationConfigProperty no longer implements importXML() -- 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

17 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1788) Workflow Approval Content must be improved

by Edgar Silva (JIRA)

Workflow Approval Content must be improved ------------------------------------------ Key: JBPORTAL-1788 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1788 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Reference Guide Environment: Any Reporter: Edgar Silva Assigned To: Julien Viet Priority: Critical Fix For: 2.6.3 Final In the JBoss Portal reference guide, there is a chapter covering the Workflow approval feature, but first of all it is now working according the doc, besides there's not screenshots showing this feature really working. IMHO it must be improved in the documentation, putting screeshots and everything else to help the users enable this feature in JBoss Portal. -- 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

17 years, 1 month

3
9
0 / 0

[JBoss JIRA] Created: (JBFORUMS-261) Forum notification type modification not working

by Luc Boudreau (JIRA)

Forum notification type modification not working ------------------------------------------------ Key: JBFORUMS-261 URL: http://jira.jboss.com/jira/browse/JBFORUMS-261 Project: JBoss Forums Issue Type: Bug Components: Forum View Layer Affects Versions: 1.0.1 RC Environment: Firefox 2.0.0.9 Reporter: Luc Boudreau Assigned To: Ryszard Kozmik While in the MyForums page, if I click on the link to modify my subscription type to forums, once on the modification page, clicking on the "modify" link of a watched forum simply brings back the same page. -- 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

17 years, 1 month

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-4940) Deployment.types not propagated

by Thomas Diesler (JIRA)

Deployment.types not propagated ------------------------------- Key: JBAS-4940 URL: http://jira.jboss.com/jira/browse/JBAS-4940 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- 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

17 years, 1 month

2
11
0 / 0

[JBoss JIRA] Created: (JGRP-608) FLUSH not safe in simultaneous flush situation

by Michael Newcomb (JIRA)

FLUSH not safe in simultaneous flush situation ---------------------------------------------- Key: JGRP-608 URL: http://jira.jboss.com/jira/browse/JGRP-608 Project: JGroups Issue Type: Feature Request Affects Versions: 2.6 Reporter: Michael Newcomb Assigned To: Bela Ban I'm running into a few problems when multiple members request a FLUSH at the same time. I am still in the process of analyzing the situation, but here are a few problems: private void handleStartFlush(Message msg, FlushHeader fh) { byte oldPhase = flushPhase.transitionToFirstPhase(); if(oldPhase == FlushPhase.START_PHASE){ sendBlockUpToChannel(); onStartFlush(msg.getSrc(), fh); }else if(oldPhase == FlushPhase.FIRST_PHASE){ Address flushRequester = msg.getSrc(); Address coordinator = null; synchronized(sharedLock){ if(flushCoordinator != null) coordinator = flushCoordinator; else coordinator = flushRequester; } After a successful transtion to the first phase, onStartFlush is called. Inside the method, the flushCoordinator is set. However a simultaneous handleStartFlush from another member would fail the transitionToFirstPhase() call, but it is possible that the flushCoordinator might not be set yet and the second handleStartFlush would end up setting the 'coordinator' to the flushRequestor. This could grant the second START_FLUSH a FLUSH_OK without rejecting the flush that succeeded in the transitionToFirstPhase(). IMHO the transitionToFirstPhase() should assign the flushCoordinator at that time to avoid the above situation, in fact, all of the protected parts of the onStartFlush() call should be made inside the protected section of transitionToFirstPhase(). The above should take care of the didn't-succeed-in-transitionToFirstPhase-but-became-flushCoordinator-anyways-because-flushCoordinator-wasn't-set-yet problem. Now, there is another problem in the way simultaneous START_FLUSHes are resolved. If the new flushRequestor is < the current flushCoordinator the new requestor will win the flush fight. This is a great strategy because all the members will get the same result here. If A, B, C are members and A < B < C and they all simultaneously request a flush, then the desired effect is for everyone to decide that A will win the flush fight. So the following code handles that situation... private void handleStartFlush(Message msg, FlushHeader fh) { ... }else if(oldPhase == FlushPhase.FIRST_PHASE){ ... if(flushRequester.compareTo(coordinator) < 0){ rejectFlush(fh.viewID, coordinator); ... synchronized(sharedLock){ flushCoordinator = flushRequester; } } If the new flushRequetor is < the old flushCoordinator than reject/abort the old flush. However, the new flushCoordinator is never acknowledged by a onStartFlush (which sends FLUSH_OK). If we moved all the protected parts of onStartFlush() to transitionToFirstPhase() then the flush members would never be set properly, so that situation needs to be resolved as well. I think this might be the problem I'm seeing because I wait indefinitely for my flush to succeed. I will be testing a patch this afternoon and hope to report back. -- 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

17 years, 1 month

3
17
0 / 0

[JBoss JIRA] Created: (JGRP-618) FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack only)

by Vladimir Blagojevic (JIRA)

FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack only) ---------------------------------------------------------------------------------------------- Key: JGRP-618 URL: http://jira.jboss.com/jira/browse/JGRP-618 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic When flush coordinator A runs a flush for a view that excludes himself a flush coordinator transfer occurs. Member B that is first next neighbor of A according to view has to complete the flush by sending STOP_FLUSH to all. Simplification of FLUSH JGRP-598 removed complex stop flush phase. In new design as soon as member receives STOP_FLUSH it unblocks application by sending UNBLOCK. Now, during coordinator transfer described above we first have to send a view up to application and then invoke STOP_FLUSH. If we do it other way around STOP_FLUSH will loop back and cause delivery of UNBLOCK to application prior to new view - thus causing reordering of block/unblock/view events in applications. -- 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

17 years, 1 month

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007