[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
[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
[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
[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