November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-634) Ability to add stacks to JChannelFactory

by Brian Stansberry (JIRA)

Ability to add stacks to JChannelFactory ---------------------------------------- Key: JGRP-634 URL: http://jira.jboss.com/jira/browse/JGRP-634 Project: JGroups Issue Type: Feature Request Reporter: Brian Stansberry Assigned To: Bela Ban Priority: Minor It would be nice to be able to add additional stacks to an existing JChannelFactory. Example: an AS deployment that wants to use a specialized channel. The deployment could package an "added-stacks.xml" file and a -beans.xml file that declares something like this: <bean>  <install bean="JChannelFactory" method="addMultiplexerConfig"> <parameter>added-stacks.xml</parameter> </install> </bean> Other services in the deployment would then be able to use some custom stack declared in added-stacks.xml. The nice thing about this is it allows packaging of custom stacks with the deployment that uses them, rather than forcing an edit of a global stacks.xml file. A quick look at JChannelFactory tells me this should be pretty simple to do. The existing setMultiplexerConfig methods seem to work like "add" methods, i.e. they could be invoked multiple times with different passed in values. A minor exception is setMultiplexerConfig(String) which also caches the passed String in an instance field. So, it should be simple to add addMultiplexerConfig methods that basically invoke the same logic. They should probably be added to the jmx.JChannelFactory as well. -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JGRP-637) Reincarnation reloaded: prevent port number reuse through persistence

by Bela Ban (JIRA)

Reincarnation reloaded: prevent port number reuse through persistence --------------------------------------------------------------------- Key: JGRP-637 URL: http://jira.jboss.com/jira/browse/JGRP-637 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.7 If bind_port (UDP) or start_port (TCP) is used, restarted members might reuse the same port, therefore one could run into reincarnation issues. Solution: if enabled, we maintain a file in the temp dir (shared by all instances on the same host), into which we write ports chosen. When a new socket is created, we read the file, weed out expired ports and pick the next port. Then we write that back to the file and close the file again. -- 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, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1164) Killing a client with a registered MessageListener renders the queue (and ServerPeer) unusable

by Ovidiu Feodorov (JIRA)

Killing a client with a registered MessageListener renders the queue (and ServerPeer) unusable ---------------------------------------------------------------------------------------------- Key: JBMESSAGING-1164 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1164 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP1 Reporter: Ovidiu Feodorov Assigned To: Tim Fox Fix For: 1.4.0.SP2 Start a simple remote client that creates a connection, session (AUTO_ACKNOWLEDGE), consumer and registers a message listener. Kill the client vm (kill -9) The queue and the ServerPeer interface become inaccessible. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1742) ACLEnforcer - folder.getFolders() give results for Anonymus user only if child folders have write or manage permssion for anonymous (read is not enough)

by Mariusz Smykula (JIRA)

ACLEnforcer - folder.getFolders() give results for Anonymus user only if child folders have write or manage permssion for anonymous (read is not enough) -------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1742 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1742 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.2 Final Environment: JBoss 4.2.1 Reporter: Mariusz Smykula Assigned To: Sohil Shah I want to execute simple code from my portlet: Command listCMD = cmsService.getCommandFactory().createFolderGetListCommand("/"); mainFolder = (Folder) cmsService.execute(listCMD); LOG.info(mainFolder .getFolders().size()); This is ALWAYS empty folders list, if executed as Anonymous user. For real result I need to set role write or manage for Anonymus user to all subfolders. This is correct? This happens because in ACLEnforce there is checked for write or mange permssion, but read is enough! for(Iterator itr=specificPermissions.iterator();itr.hasNext();) { Permission specificPermission = (Permission)itr.next(); if( (specificPermission.getService().equals("cms")) && (specificPermission.getAction().equals("write") || specificPermission.getAction().equals("manage")) ) { for(Iterator itr2=userPermissions.iterator();itr2.hasNext();) { Permission userPermission = (Permission)itr2.next(); if( (userPermission.getService().equals("cms")) && (userPermission.getAction().equals("write") || userPermission.getAction().equals("manage")) ) { String pathCriteria = userPermission.findCriteriaValue("path"); if(pathCriteria.equals(path)) { //this means this user has read access to this path toolAccess = true; } } } } } This is correct? -- 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, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1727) CLONE -CMS saves pages in native encoding (ISO-8859-1 or Cp1251) but retrieve it in UTF-8. then national leters are damaged

by Mariusz Smykula (JIRA)

CLONE -CMS saves pages in native encoding (ISO-8859-1 or Cp1251) but retrieve it in UTF-8. then national leters are damaged --------------------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1727 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1727 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Environment: jboss4.0.3sp1 Reporter: Mariusz Smykula Assigned To: Sohil Shah Fix For: 2.6 CR3 When I input ru-characters in the text area it has been puted into table in native encoding (cp1251) - !!! not UTF-8. But pages are sends in UTF-8, and it damaged. I think that I have to encode the request in UTF-8 ??? --------------------------------------------- create file.html in Ru (in cms admin) with this text abc??? then look at the last record of JBP_CMS_VERSION_BINVAL (six bytes in BINVAL_DATA field): 61 62 63 e0 e1 e2 it is cp1251 encoding !!!! why this text non unicoded ??? then when i retrive it i have - 'abc???' I think that problem isn't in ContentTypeInterceptor because it succefully sets UTF8, because localized resources seems right (in russian). may be it is need to store text in CLobs insdead blobs ??? (a use Derby) or customize Jackrabbit ??? ----------------------------------------------------------- but when I upload file on UTF-8 with russian characters - all correct. I think that cms saves the content in one byte encoding (cp1250 or same). -- 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, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4986) subproject fails to build from source (jgroups related)

by Torsten Werner (JIRA)

subproject fails to build from source (jgroups related) ------------------------------------------------------- Key: JBAS-4986 URL: http://jira.jboss.com/jira/browse/JBAS-4986 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.2.2.GA Reporter: Torsten Werner Assigned To: Brian Stansberry When I try to build the subproject from source, I get the following error message. The class org.jgroups.debug.Debugger is not available in jgroups 2.5 or 2.6. 1. ERROR in /home/twerner/debian/build-area/jbossas4-4.2.2.GA/cluster/src/main/./org/jboss/ha/framework/server/ClusterPartition.java (at line 49) import org.jgroups.debug.Debugger; ^^^^^^^^^^^^^^^^^^^^^^^^^^ The import org.jgroups.debug.Debugger cannot be resolved ---------- 2. ERROR in /home/twerner/debian/build-area/jbossas4-4.2.2.GA/cluster/src/main/./org/jboss/ha/framework/server/ClusterPartition.java (at line 100) protected Debugger debugger=null; ^^^^^^^^ Debugger cannot be resolved to a type ---------- 3. ERROR in /home/twerner/debian/build-area/jbossas4-4.2.2.GA/cluster/src/main/./org/jboss/ha/framework/server/ClusterPartition.java (at line 344) if(use_debugger && debugger == null) ^^^^^^^^ debugger cannot be resolved ---------- 4. ERROR in /home/twerner/debian/build-area/jbossas4-4.2.2.GA/cluster/src/main/./org/jboss/ha/framework/server/ClusterPartition.java (at line 346) debugger=new Debugger(channel); ^^^^^^^^ debugger cannot be resolved ---------- 5. ERROR in /home/twerner/debian/build-area/jbossas4-4.2.2.GA/cluster/src/main/./org/jboss/ha/framework/server/ClusterPartition.java (at line 346) debugger=new Debugger(channel); ^^^^^^^^ Debugger cannot be resolved to a type Cheers, Torsten -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4766) HTTP session replication failover failures with async buddy replication

by Dominik Pospisil (JIRA)

HTTP session replication failover failures with async buddy replication ----------------------------------------------------------------------- Key: JBAS-4766 URL: http://jira.jboss.com/jira/browse/JBAS-4766 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Affects Versions: JBossAS-4.2.0.GA Environment: 4 nodes, buddy async replication, 100 clients Reporter: Dominik Pospisil Assigned To: Brian Stansberry Attachments: driver.log, server-perf01.log.gz, server-perf02.log.gz, server-perf03.log.gz, test.log Sending test-logs of failed tests. Failed clients: 72, 96. For details please see attached log files. -- 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, 7 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-5011) SecurityInterceptor: Use unauthenticatedIdentity if explicit RunAsPrincipal not configured

by Anil Saldhana (JIRA)

SecurityInterceptor: Use unauthenticatedIdentity if explicit RunAsPrincipal not configured ------------------------------------------------------------------------------------------ Key: JBAS-5011 URL: http://jira.jboss.com/jira/browse/JBAS-5011 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: EJB2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 In the setContainer method of the SecurityInterceptor, there is a need to create a RunAsIdentity instance. If there is no explicit run-as principal configured for a run-as role, then use the container unauthenticatedIdentity, starting with the Applicationmetadata.getUnauthenticatedprincipal. -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1332) Add support to event declaration in the DRL and add support to event identification into the engine

by Edson Tirelli (JIRA)

Add support to event declaration in the DRL and add support to event identification into the engine --------------------------------------------------------------------------------------------------- Key: JBRULES-1332 URL: http://jira.jboss.com/jira/browse/JBRULES-1332 Project: JBoss Drools Issue Type: Sub-task Security Level: Public (Everyone can see) Components: All Reporter: Edson Tirelli Assigned To: Edson Tirelli Fix For: 4.1.0 Add support to event declaration in the DRL and add support to event identification into the engine -- 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, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1646) portal-cms depends on existence of user 'admin'

by Tobias Roth (JIRA)

portal-cms depends on existence of user 'admin' ----------------------------------------------- Key: JBPORTAL-1646 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1646 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.1 Final Reporter: Tobias Roth Assigned To: Sohil Shah cms/src/main/org/jboss/portal/cms/impl/jcr/JCRCMS.java has the user 'admin' hardcoded: /** Loads content from sar and adds it to the repo. */ public void createContent() throws Exception { log.info("Creating default CMS content."); // Get the content URL root = Thread.currentThread().getContextClassLoader().getResource(defaultContentLocation); //make the user executing these to create the default content, an 'Admin' user //without this, the fine grained security won't allow the creation UserModule userModule = getUserModule(); if(userModule != null) { org.hibernate.Session session = org.jboss.portal.cms.hibernate.state.Tools.getOpenSession(); org.hibernate.Transaction tx = session.beginTransaction(); User user = userModule.findUserByUserName("admin"); // HERE if(user!=null) { JCRCMS.getUserInfo().set(user); } tx.rollback(); org.jboss.portal.cms.hibernate.state.Tools.closeSession(session); } If it doesn't exist (for example because LDAP is being used), portal-cms cannopt be deployed, and several database tables are not created. If 'admin' is changed to an existing user, everything works fine. There is another reference to 'admin' in cms/src/main/org/jboss/portal/cms/impl/jcr/command/ACLEnforcer.java, but leaving this as it is doesn't seem to have any negative effect. -- 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, 7 months

3
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007