April 2007 - jboss-dev-forums - Jboss List Archives

[Design of the JBoss EJB Container] - Re: jdbc2.StoreManager2 and key-generators

by jesper.pedersen

Looking at the next at the next exception in our trace it seems that jdbc2.AbstractQueryCommand doesn't implement LIMIT/OFFSET functionality such the jdbc.JDBCAbstractQueryCommand does. Correct ? If so, how should jdbc2.AbstractQueryCommand implement this functionality ? The interface between the two classes are different, so the OFFSET/LIMIT information isn't directly available. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037470#4037470 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037470

18 years, 11 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: jdbc2.StoreManager2 and key-generators

by jesper.pedersen

There is a bug in JDBCEntityBridge2::getQualifiedTableName(). The method should do the same as the JDBCEntityBridge::getQualifiedTableName() namely | SQLUtil.fixTableName(metadata.getDefaultTableName(), dataSource); | Should the bug be fixed in the constructor (as local variable) or in the method ? I'm for the fix in the constructor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037451#4037451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037451

18 years, 11 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Updating the server task to detect OutOfMemoryErrors

by ryan.campbell＠jboss.com

If visibility problems are pushing the cloning of all of these classes, then we should put it back in the org.apache namespace. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037344#4037344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037344

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Re: Configuration & CacheImpl overlap of concerns

by bstansberry＠jboss.com

I like the use of Configuration.createX() rather than setX/getX. A concern I have with using the configuration to provide these is it tends to expose the internal objects used by the cache as part of the public API. Using a factory approach gets around that issue, since there's no reason two calls to createX() should return the same instance. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037301#4037301 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037301

18 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Where is EJB3 source

by fakeer

i looked everywhere. sourceforge's cvs link to this probject is also down :| View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037279#4037279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037279

18 years, 11 months

1
0
0 / 0

[Design of JBossCache] - Configuration & CacheImpl overlap of concerns

by genman

There's a lot of logic embedded in CacheImpl.start() and create() as to what specific object instances are created. For example, the JGroups Channel, or the InterceptorChainFactory are directly constructed here and users have no control on this. A bunch of other objects are also created based on class names and whatnot; these are configurable to some extent but why does the CacheImpl need to know how to build these? What really should be done is allow the Configuration class to play the role as factory class, and take out all factory details from the Cache itself. I suggest for 2.0 that anything with "new Something()" or Class.newInstance() in Cache be moved to the Configuration object. I would consider moving out the following: | RegionManager | Notifier | StateTransferManager | ReplicationQueue | InterceptorChainFactory | BuddyManager | CacheJmxWrapper | OptimisticTransactionEntry, TransactionEntry | As an example: public synchronized RegionManager getRegionManager() | { | if (regionManager == null) | { | regionManager = new RegionManager(this); | } | return regionManager; | } | should be rewritten as: | public synchronized RegionManager getRegionManager() | { | if (regionManager == null) | { | regionManager = configuration.createRegionManager(); | } | return regionManager; | } | This all somewhat is related to: http://jira.jboss.com/jira/browse/JBCACHE-1023 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037261#4037261 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037261

18 years, 11 months

1
0
0 / 0

[Design of JBoss Wiki] - Re: MediaWiki syntax and file handling

by Oberiko

One thing I forgot. I'm assuming that security will be done at the page level, would it be possible to set security constraints at the category level as well? Thus any page with the [[category:Customer1]] could only be set to only be viewed by users in the "Customer 1" group etc. This should also (optionally) flow down to sub-categories. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037215#4037215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037215

18 years, 11 months

1
0
0 / 0

[Design of JBoss Wiki] - MediaWiki syntax and file handling

by Oberiko

Hello, a few suggestions for the design of JBossWiki. MediaWiki syntax Would it be possible, as an option, to allow the Wiki administrator to change the forums to use pseudo-MediaWiki style syntax instead of JSPWiki syntax? Categories Handled the same as MediaWiki Files Central repository I know that JSPWiki allows files uploaded on a page basis, but I'd prefer to upload centrally and link to files with a [[File:FileName.ext|MyFile]] tag as I could potentially want the same file available on multiple pages. The MyFile would, of course, be optional. These files wouldn't need to be rendered within the wiki, so they could simply be stored and transferred as BLOBs. File sharing with CMS I would also like to be able to access files stored in the default JackRabbit CMS from within my wiki without having to upload it twice. For these I'd like a [[JRCMS:FilePath\FileName.ext|version|MyFile]] tag, with the last two portions being optional (if no specific version is specified, then it would use the last one). Going the other way, I'd like to see a "JBossWiki" folder added to CMSAdmin if JBossWiki is installed which would allow file management from there instead. Categorization I'd like for files to have the same kind of categorization options as any other page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037205#4037205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037205

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: Russian dolls and implicit deployment ordering

by adrian＠jboss.org

Also since we are currently developing support for aliases, this is another mechanism that could be used. e.g. When JCA creates its BeanMetaData or ServiceMetaData it could add an alias that is the jndi name, OR the JNDIBinding decorator could register it as a dynamic alias: http://jira.jboss.com/jira/browse/JBMICROCONT-170 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037096#4037096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037096

18 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: Russian dolls and implicit deployment ordering

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I much prefer the idea of using AOP (decorators) to handle jndi binding. | | | @JNDIBinding(...) | | public class MyClass | | | | or | | | | <bean ...> | | <annotation>@JNDIBinding(name="whatever")</annotation> | | </bean> | | | | Because: | 1) You can change what the jndi binding action means in different environments, | e.g. JBoss or Tomcat, without changing the configuration | 2) It enables all sorts of other useful features, like not even binding into | jndi at all (for client usage) until the barrier service says "open the gates" | we're ready to go. This should also fit in with your requirement to know the jndi mapping to kernel dependency. The JNDI Binding aspect (since it is a "decorator") can do: Pseudo code: | public void install(ControllerContext context) | { | JNDIBinding jndi = context.getMetaData().getAnnotation(JNDIBinding.class); | if (jndi != null) | map.put(jndi.name(), context.getName()); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4037088#4037088 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4037088

18 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2007