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

[Design of JBoss Portal] - Re: Java 5 migration strategy

by bdaw

Actually I don't see the big problem here: - we don't need to upgrade whole codebase to the java 5 syntax (time consuming + branch sync issues) - when you bug fix you code with backport (svn merge) in mind so probably won't use new syntax anywa... - when you add new features you change/refactor a lot so such part can't be backported easily, and probably isn't supposed to be backported at all.... So lets naturally use java 5 in trunk for new stuff and during refactorings, and don't upgrade old code "just to". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061064#4061064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061064

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Initial UI Server Prototype Discussion

by sohil.shah＠jboss.com

Here is the first cut for the UI Server that needs to be built out for the next version of JBoss Portal. For background on what this UI Server is look at http://wiki.jboss.org/wiki/Wiki.jsp?page=PresentationFramework. So here are the architectural concepts implemented in this prototype: * A portal request is processed by an entity called the Controller. The controller processes this request in three different phases: processCommand, processCommandResponse, and process the response coming back from handling the CommandResponse * It is during this third phase, that UI related functions such as markup aggregation for the calling client takes place * So in this prototype, the UI Server handles the processing of the UI generation in this third phase * UIServer is a JMX service registered/configured at Portal startup * UIServer requests are invoked using an object called UIServerRequest * Data needed by the UIServer to fulfill a UIServerRequest of generating the final UI and sending back to the client is passed in by setting attributes on the UIServerRequest object * In this prototype and the usecases implemented, the data being passed in by the Controller is ServerInvocation, and a UIIndicator object which signifies which type of client UI should produce the UI to be sent back * The UIServerResponse object which is a HandlerResponse object carries the UIIndicator object. * The UIServer has the abstract idea of a ClientUI. A ClientUI can be your classic html request/response based client, or an ajax based rich application, a thick client swing application etc etc. The UIServer manages the lifecycles required for the client uis. And these ClientUI implementations can be easily registered with the UIServer via its JMX configuration. * The link between the controller and the client UI is made using the UIIndicator object which is part of the Client UI registration configuration in the JMX bean Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061056#4061056 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061056

18 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - JBREM-433 - Point-to-multipoint, JGroups

by david.lloyd＠jboss.com

The question is - how can we provide a point-to-multipoint request-reply mechanism. I guess the easy answer is JBREM-48 - just have a JGroups transport. I think that there could be a couple more types of session: * point-to-point - single connection; request-respone (definitely reliable) and oneway (probably reliable) allowed * point-to-multipoint - oneway only, possibly unreliable (simple protocols like UDP+Multicast or UDP+Broadcast) * point-to-group - something like JGroups, where you allow request-response with some kind of response aggregation (like a Map of node-IDs to Reply messages [guess this means that Remoting needs to have a concept of an endpoint identifier - and no, I do no think that it should be the connection URI because there won't be a 1:1 correspondance there]) We should provide an SPI thing for all these types, but I don't think it's worth the effort to reinvent what JGroups already has, so the last should be confined to a JGroups transport unless someone contributes something awesome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061049#4061049 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061049

18 years, 9 months

1
0
0 / 0

[Design of POJO Server] - Re: Running with the full featured profile service

by rrajesh

I added a test-config to the testsuite with the full featured profile service as mentioned above, but i am not able to start the test configuration. I get NoClassDefFoundError as shown below. The target in the testsuite is "tests-profileservice". This is not part of the main testsuite yet. 16:14:19,362 ERROR [AbstractKernelController] Error installing to PreInstall: name=AspectDeployer state=Not Installed | java.lang.NoClassDefFoundError: org/jboss/deployers/plugins/deployer/AbstractSimpleDeployer | at java.lang.ClassLoader.defineClass1(Native Method) | at java.lang.ClassLoader.defineClass(ClassLoader.java:620) | at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) | at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) | at java.net.URLClassLoader.access$100(URLClassLoader.java:56) | at java.net.URLClassLoader$1.run(URLClassLoader.java:195) | at java.security.AccessController.doPrivileged(Native Method) | at java.net.URLClassLoader.findClass(URLClassLoader.java:188) | at java.lang.ClassLoader.loadClass(ClassLoader.java:306) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.resolveComplexTypeInfo(IntrospectionTypeInfoFactoryImpl.java:349) | at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:340) | at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactory.getTypeInfo(IntrospectionTypeInfoFactory.java:49) | at org.jboss.classadapter.plugins.BasicClassAdapterFactory.getClassAdapter(BasicClassAdapterFactory.java:61) | at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:70) | at org.jboss.kernel.plugins.config.AbstractKernelConfig.getBeanInfo(AbstractKernelConfig.java:55) | at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:65) | at org.jboss.kernel.plugins.config.AbstractKernelConfigurator.getBeanInfo(AbstractKernelConfigurator.java:84) | at org.jboss.kernel.plugins.dependency.PreInstallAction.installActionInternal(PreInstallAction.java:63) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:147) | at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:53) | at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) | at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) | at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:309) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:279) | at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130) | at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88) | at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:158) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:295) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:222) | at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89) | at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403) | at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342) | at org.jboss.Main.boot(Main.java:210) | at org.jboss.Main$1.run(Main.java:523) | at java.lang.Thread.run(Thread.java:595) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4061030#4061030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4061030

18 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Tracking WF path of execution

by bill.burke＠jboss.com

I always thought that relying on Hibernate to both load and manage a process definition instances was a flawed approach as you cannot do things like this. This is why jBPM is also stuck with the instance-per-request for actions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060992#4060992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060992

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Consider using shorter filenames....

by bill.burke＠jboss.com

This has got to be the most hilarious discussion in awhile.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060989#4060989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060989

18 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Fully asynchronous invocation

by david.lloyd＠jboss.com

In my wiki article, I talked about using a Future to represent the future result of an invocation in the event of a non-blocking request-reply invocation. One limitation of Future is that it doesn't provide any means to call a callback when the operation completes - you must poll the Future. So instead of returning a Future, the asynchronous request method should return a subinterface of Future (which I have called FutureReply) that also has a setCompletionNotifier(handler) method, which calls the given handler when the request completes. This way, a single interface lets you invoke in three different ways: blocking, non-blocking with polling, and non-blocking with asynchronous callback. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060988#4060988 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060988

18 years, 9 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Sharing connections and classloading

by david.lloyd＠jboss.com

It should be possible for all traffic between two Remoting endpoints to share a single connection for all communication (assuming a transport that uses TCP or similar). However an exception to this is that in order to load classes on demand (either from server-to-client like we have today, or client-to-server which has been requested), a separate channel is needed. The reason for this is that classes are not identified as missing until a deserializer actually attempts to load them - at this point, even if we have a complete framework for sharing the connection, the serialization stream is monopolizing the connection so it cannot be used to load classes. So this means that in order to support class loading, a second connection is needed to facilitate this function. In Remoting 3, there should be some sort of SPI method to open a classloading channel for each transport that supports it. In addition, it should be possible for connection-oriented transports to share a single connection for all classloading (in either direction) between two endpoints. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060984#4060984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060984

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J

by hmesha

Yep. It should work fine. All you need to change, in addition to backporting the SessionSerializationFactory, in JBossCacheService are the calls that are invoking marshalling. -Hany View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060974#4060974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060974

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Using JBossSerialization with HttpSession Replication (J

by bstansberry＠jboss.com

>From a quick look it seems that should work fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060963#4060963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060963

18 years, 9 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 July 2007