November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1820) Finders for user profile

by Andrew Oliver (JIRA)

Finders for user profile ------------------------ Key: JBPORTAL-1820 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1820 Project: JBoss Portal Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Portal Identity Reporter: Andrew Oliver It should be possible to search for users by properties of their profile. Example all users with location "Heidelberg, DE" or other user added properties. Add User findUserByProfileProperty(String name, Object value); to UserProfileModule and its implementations Alter HibernateUserImpl such that ProfileMap is an Entity able to be searched on. Presently this is JBP_USER_PROP but is a component. This can be altered without altering the database structure and without more than mapping and other minor changes to the Hibernate...Impl classes (none of which would affect existing portal apps). -- 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-1805) Let a user define multiple display-name for a portal object in the admin portlet

by Thomas Heute (JIRA)

Let a user define multiple display-name for a portal object in the admin portlet -------------------------------------------------------------------------------- Key: JBPORTAL-1805 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1805 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Core Admin Reporter: Thomas Heute Assigned To: Wesley Hales Fix For: 2.6.3 Final When an administrator creates a new portlet-instance, he should be able to define (and edit) different display-names for a single instance. -- 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: (JBPORTAL-1721) Improve error handling when the CMS content cannot be found by the content selector

by Thomas Heute (JIRA)

Improve error handling when the CMS content cannot be found by the content selector ----------------------------------------------------------------------------------- Key: JBPORTAL-1721 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1721 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Reporter: Thomas Heute Assigned To: Sohil Shah Fix For: 2.6.3 Final If the content of a file doesn't exist neither in the user preferred locale and the default locale set up at the service level, the CMS content selector will fail with a NPE in: /WEB-INF/jsp/cms/editor/main.jsp at line 128 125: <p class="portlet-font"> 126: Selected file: <%= uri %><br /> 127: <% 128: if (content.getTitle() != null) 129: { 130: out.println("File title: " + content.getTitle() + "<br />"); 131: } -- 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: (JBBUILD-428) Add support for ThreadLocal.remove()

by Magesh Kumar B (JIRA)

Add support for ThreadLocal.remove() ------------------------------------ Key: JBBUILD-428 URL: http://jira.jboss.com/jira/browse/JBBUILD-428 Project: JBoss Build System Issue Type: Feature Request Components: JBossRetro Environment: JDK1.4 Reporter: Magesh Kumar B Assigned To: Magesh Kumar B Priority: Blocker Fix For: JBossRetro-1.1.3.GA ThreadLocal.remove just sets the ThreadLocal to null and the subsequent calls to get() does not initialize the initialValue(). -- 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
3
0 / 0

[JBoss JIRA] Created: (JBAS-5015) Deploy entity beans in Oracle 11g on JBoss 4.2.1 and JBoss 4.2.1

by Georges Goebel (JIRA)

Deploy entity beans in Oracle 11g on JBoss 4.2.1 and JBoss 4.2.1 ---------------------------------------------------------------- Key: JBAS-5015 URL: http://jira.jboss.com/jira/browse/JBAS-5015 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Hibernate service Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA Environment: JAva 1.5 JBoss 4.2.1 and JBoss4.2.2 Reporter: Georges Goebel Assigned To: Steve Ebersole It is not possible to deploy entity beans to an Oracle 11g Datasource because the HibernateException : unknown Oracle major version [11] occurs If I check in the hibernate 3.2.4sp1 distribution the class org.hibernate.dialect.DialectFactory there I find the following definition which is correct (in my eyes) private static final Map MAPPERS = new HashMap(); static { // TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) ); MAPPERS.put( "DB2/NT", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) ); MAPPERS.put( "MySQL", new VersionInsensitiveMapper( "org.hibernate.dialect.MySQLDialect" ) ); MAPPERS.put( "PostgreSQL", new VersionInsensitiveMapper( "org.hibernate.dialect.PostgreSQLDialect" ) ); MAPPERS.put( "Microsoft SQL Server Database", new VersionInsensitiveMapper( "org.hibernate.dialect.SQLServerDialect" ) ); MAPPERS.put( "Microsoft SQL Server", new VersionInsensitiveMapper( "org.hibernate.dialect.SQLServerDialect" ) ); MAPPERS.put( "Sybase SQL Server", new VersionInsensitiveMapper( "org.hibernate.dialect.SybaseDialect" ) ); MAPPERS.put( "Informix Dynamic Server", new VersionInsensitiveMapper( "org.hibernate.dialect.InformixDialect" ) ); MAPPERS.put( "Apache Derby", new VersionInsensitiveMapper( "org.hibernate.dialect.DerbyDialect" ) ); MAPPERS.put( "Oracle", new DatabaseDialectMapper() { public String getDialectClass(int majorVersion) { return majorVersion > 8 ? "org.hibernate.dialect.Oracle9Dialect" : "org.hibernate.dialect.OracleDialect"; } } ); } The JBoss 4.2.2 distribution shows during startup the usage of hibernate 3.2.4sp1 (also according the Manifest file in the jar) but when I decompile the class org.hibernate.dialect.DialectFactory in the JBoss distribution it shows the old implementation: static { MAPPERS = new HashMap(); MAPPERS.put("HSQL Database Engine", new VersionInsensitiveMapper("org.hibernate.dialect.HSQLDialect")); MAPPERS.put("DB2/NT", new VersionInsensitiveMapper("org.hibernate.dialect.DB2Dialect")); MAPPERS.put("DB2/LINUX", new VersionInsensitiveMapper("org.hibernate.dialect.DB2Dialect")); MAPPERS.put("MySQL", new VersionInsensitiveMapper("org.hibernate.dialect.MySQLDialect")); MAPPERS.put("PostgreSQL", new VersionInsensitiveMapper("org.hibernate.dialect.PostgreSQLDialect")); MAPPERS.put("Microsoft SQL Server Database", new VersionInsensitiveMapper("org.hibernate.dialect.SQLServerDialect")); MAPPERS.put("Microsoft SQL Server", new VersionInsensitiveMapper("org.hibernate.dialect.SQLServerDialect")); MAPPERS.put("Sybase SQL Server", new VersionInsensitiveMapper("org.hibernate.dialect.SybaseDialect")); MAPPERS.put("Adaptive Server Enterprise", new VersionInsensitiveMapper("org.hibernate.dialect.SybaseDialect")); MAPPERS.put("Informix Dynamic Server", new VersionInsensitiveMapper("org.hibernate.dialect.InformixDialect")); MAPPERS.put("Apache Derby", new VersionInsensitiveMapper("org.hibernate.dialect.DerbyDialect")); MAPPERS.put("Oracle", new DatabaseDialectMapper() { public String getDialectClass(int majorVersion) { switch(majorVersion) { case 8: // '\b' return (DialectFactory.class$org$hibernate$dialect$Oracle8iDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle8iDialect : (DialectFactory.class$org$hibernate$dialect$Oracle8iDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle8iDialect"))).getName(); case 9: // '\t' return (DialectFactory.class$org$hibernate$dialect$Oracle9iDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle9iDialect : (DialectFactory.class$org$hibernate$dialect$Oracle9iDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle9iDialect"))).getName(); case 10: // '\n' return (DialectFactory.class$org$hibernate$dialect$Oracle10gDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle10gDialect : (DialectFactory.class$org$hibernate$dialect$Oracle10gDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle10gDialect"))).getName(); } throw new HibernateException("unknown Oracle major version [" + majorVersion + "]"); } }); } Perhaps there is something wrong by integration the different components in JBoss during packaging. Replacing the hibernate3.jar in the JBoss distribution by the hibernate3.jar from the hibernate 3.2.4sp1 distribution solved the problem. -- 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
7
0 / 0

[JBoss JIRA] Commented: (JBWEB-16) scratchdir fails for multi-user installs

by Remy Maucherat (JIRA)

[ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12389596 ] Remy Maucherat commented on JBWEB-16: ------------------------------------- The only real option to make it automagical is to use a random folder name inside temp, but this does not work well as there's a possible expectation by some users that the work folder is persistent (it can be used for session persistence, keeping compiled JSPs, etc). Using "catalina.base" uses Tomcat's multi-user capabilities, which makes it work. Unless someone comes up with a brilliant idea, I'll resolve this as "won't fix". > scratchdir fails for multi-user installs > ---------------------------------------- > > Key: JBWEB-16 > URL: http://jira.jboss.com/jira/browse/JBWEB-16 > Project: JBoss Web > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Tomcat Module > Affects Versions: JBossWeb embedded - AS 4.0.1 > Reporter: Norman Richards > Assigned To: Remy Maucherat > > The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8). Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable. > This produces a a FATAL log message: > 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified: > /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable. > This also causes exceptions when the server shuts down. > The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis. Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. > See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear. -- 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
0
0 / 0

[JBoss JIRA] Created: (JBAS-4568) AOP 2.0.0.beta

by Kabir Khan (JIRA)

AOP 2.0.0.beta -------------- Key: JBAS-4568 URL: http://jira.jboss.com/jira/browse/JBAS-4568 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: AOP Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: JBossAS-5.0.0.Beta3 -- 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
7
0 / 0

[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

17 years, 1 month

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

17 years, 1 month

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

17 years, 1 month

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007