September 2006 - jboss-dev-forums

[Design of JBoss Portal] - Re: Core split

by sverker

Any idea of when this will happen? I'd like to see it sooner rather than later as it would separate the infrastructure components from your example portal. I'd probably use core-server and core-cms as is and my own bundle of management and ui instead of core-ui View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975270#3975270 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975270

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Thoughts on 2.0 API

by genman

Probably the boat has already left the dock, but here are some thoughts... There's org.jboss.cache.factories and org.jboss.cache.pojo.factory, in addition to being inconsistent, I sort of don't like the "ies" look. I also don't like "factory" as a package in general, because I don't think it has enough weight (number of classes and scope of use) to warrant separation. Its use is integral to how a user builds a cache, so it should be immediately obvious where to get it. I also doubt that having the Factory be an interface is better than an abstract base class. A simple "abstract Cache createCache(...)" that users can replace and a "static Cache createDefaultCache" would be far more useful. import org.jboss.cache.Cache; import org.jboss.cache.CacheFactory; Cache c = CacheFactory.createDefaultCache(); c.put(Fqn.ROOT, "a", "b"); // versus import org.jboss.cache.Cache; import org.jboss.cache.factories.CacheFactory; import org.jboss.cache.factories.DefaultCacheFactory; CacheFactory cf = new DefaultCacheFactory(); Cache c = cf.createCache(); c.start(); c.put(Fqn.ROOT, "a", "b"); Having a start parameter, like "Factory { create(Config c, boolean start) }" is sort of hokey... In general, the 90% use case is to create a started cache, if you're going through Java. A "Configuration" could state if a cache should be in started state for the 10% of cases. Example: Configuration c = ... c.setStartOnCreate(false); // or something like that Cache c = CacheFactory.createCache(c); c.start(); CacheSPI () { } ... Having a List that can be changed seems better than two additional methods. A List is for adding and removing stuff, right? CacheSPI spi = ... spi.getInterceptorChain().add(new MyInterceptor()); // or spi.getInterceptorChain().add(4, new MyInterceptor()); // or spi.getInterceptorChain().addAll(4, List l); I'm also thinking a JSR-77 sort of Statistics class would be in order. Having a grouped bunch means you can add new statistics without changing the CacheSPI interface itself. Why does Region not have a "CacheListener"? There are 6 methods in CacheSPI for a listener, but none in Region. I guess what'd be nice is a: Fqn f; CacheListener cl; Region r = Cache.getRegion(f); r.getCacheListeners().clear(); r.getCacheListeners().add(cl); Cache.getRegion(Fqn.Root).clear(); // not sure how well defined this might be I would probably move RegionImpl->Region. Having interfaces sort of prevents you from extending your API (easily). Again, what's the benefit of an interface over a concrete class in this situation? Region sounds like something you'd want to extend in the future. One scenario is if you had different interceptor configs or cache loaders per region in the future. The new API needs to justifiable, otherwise your users will simply do this: TreeCache tc = ... Cache c = tc.getCacheSPI(); and the hell to your factories ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975254#3975254 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975254

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: JBoss Portal 2.0 and Oracle ADF Faces

by bbernard

If anyone have the solution for this (particulary the source of the modified Portal bridge) that would be great. Thanks Bruno View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975228#3975228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975228

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: Supporting XInclude

by alex.loubyansky＠jboss.com

I don't mind adding it. For xerces, yes, there is a feature for it http://xerces.apache.org/xerces2-j/features.html#xinclude View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975220#3975220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975220

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: What's the status of HEAD?

by scott.stark＠jboss.org

Your thirdparty contents are not up to date then. Remove it and do a clean build as sun.opends.classpath exists in my build. | [starksm@succubus testsuite]$ grep -C3 sun.opends.classpath ../thirdparty/libraries.ent | <property name="sun.opends.root" value="${project.thirdparty}/sun-opends"/> | <property name="sun.opends.lib" value="${sun.opends.root}/lib/"/> | <property name="sun.opends.resources" value="${sun.opends.root}/resources/"/> | <path id="sun.opends.classpath"> | <pathelement path="${sun.opends.lib}/OpenDS.jar"/> | </path> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975211#3975211 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975211

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

by ron_sigal

I've run into another issue. When memory is running short, the server side callback handler has the ability to persist callbacks to secondary storage. Currently, there is one true persisting callback store, which I guess predates jboss serialization, since it uses java serialization. Therefore, it can't handle some Messaging callbacks. Extending it to use jboss serialization shouldn't be a problem. However, Tom mentioned that, at Tim's request, he implemented a BlockingCallbackStore, which simply blocks the thread passing calllbacks to Remoting. So I'm wondering what the Messaging philosophy here. Do you want to have the option to configure a true persisting callback store? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975196#3975196 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975196

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Supporting XInclude

by adrian＠jboss.org

I'd like to be able to compose xml documents. With the old dtd stuff this was done with entities, e.g. see the build scripts. :-) When using xsd, the only option is XInclude. But this isn't supported until java5 http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParserFactor... Can we add some reflection processing to the static initializer in SaxJBossXBParser that tries to set this to true if the method exists. It should also be possible to make this work by setting features before Java5? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975195#3975195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975195

18 years, 5 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - Re: Which is the most important feature for JBMS to implemen

by dhartford

I voted for the Calendar server/CBA. There are a lot of various tools (both open source and not) for integrating/developing a solution to include Mail support, but not many open source for doing Calendar-server oriented development (scheduling time/resources and retrieving Free-Busy schedules). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975194#3975194 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975194

18 years, 5 months

1
0
0 / 0

[Design of JBoss Reporting] - Re: Reporting System

by dhartford

Not sure if this has already been identified - http://www.pentaho.org Olap/mondrian support (with MDX and XML/A), ETL-kettle support, jasperreport engine and BIRT report engine, scheduling (via Quartz). -D View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975193#3975193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975193

18 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Smooks Transformation Integrated

by tfennelly

"mark.little(a)jboss.com" wrote : However, what's the service API look like? Sorry about the delay.... I was busy fixing the build ;-) Transformation Service API SmooksTransformer implements the TransformationService interface. "mark.little(a)jboss.com" wrote : How will someone go about replacing this transformation service with another one? I suppose that depends on whether we're talking about the current or a future architecture... Currently, as far as the ESB is concerned, Transformation Service implementations need to be ActionProcessors same as any other ActionProcessor (terrible name ;-( ). So, from a code perspective, replacing any ActionProcessor with another ActionProcessor is seemless because they all implement that interface. From a configuration perspective, it'd be a case of replacing the processor on the "Action" configuration to reference that "different" transformation service - thereby getting it to transform (process) the message instead. Of course, the "different" transformation service would need to work against the same action properties. This should all become more decoupled in our future archs once we get all the "Action" configurations into the registry and get our normalised message structures + EPRs etc in there with the routing info (and other message metadata). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975192#3975192 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975192

18 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006