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

[Design of Security on JBoss] - Identity API for NonAS projects

by anil.saldhana＠jboss.com

I have taken a look at the Seam Identity API and need to have a look at the portal identity API yet. I have fair idea of how the API will look like. One area that I need to focus on is the representation of roles and groups. To get the context of this thread, please look at: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=121030 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101943#4101943 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101943

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: remoting streams

by jahlborn

So, a couple of things jump out at me initially. the first is that it is a very interesting choice to put the iterator-like API beneath the stream API. the rmiio library has a remote iterator API which is built on top of the streaming API. the choice made in the remoting impls leads to some performance consequences. every remote retrieval operation for inputstream requires two remote calls (hasNext and next). additionally, for the collection based impls (IteratorObjectSource), every object retrieval requires two remote calls! since rmiio implements the iterator api on top of the streaming api (arguably more complicated), multiple objects can be retrieved in one call. and, there is no remote "hasNext" equivalent, just "read" which merely returns null when EOD is reached. lastly, since rmiiio uses streams, over-the-wire compression can be utilized to dramatically reduce the data transmission. the other big thing that stuck out to me is the lack of any idempotent guarantees. it's possible this is provided by the underlying framework, but, if not, it's a significant weakness. when systems get burdened, it's not unlikely for a given call to fail. looking at these implementations alone, that means lost data. the rmiio implementations allow the current read/write operation to be infinitely retried. another problem that's more related to remoting as a whole (at least in previous remoting versions), is the lack of an interface similar to java.rmi.server.Unreferenced. this becomes more important for things like streams which can be holding system resources which are relatively scarce (open file handles, database connections, etc). it's not uncommon for a client to die unexpectedly before the "close" method is invoked on the server. this will leave the stream resource open indefinitely. the rmiio implementations utilize the Unreferenced API so that when used with RMI proper, server resources will eventually be reclaimed if clients die before calling the remote "close". one last minor point is that i see no support for duplicate close calls (again, this could be managed elsewhere by the underlying framework). often, with appropriate usage of finally blocks, you may attempt to close a remote source multiple times. since the first successful call often shuts down the remote server, this can result in lots of annoying exceptions on the client side (because the source no longer exists when the second call goes through). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101920#4101920 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101920

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by jmesnil

"trustin" wrote : | | MINA 2.x provides exactly what you want as a filter. Please take a look at here: | | http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/min... | | Cool, one thing less to reinvent on our side :) I had a look at it and it is exactly the feature we need. Thanks for the tip! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101894#4101894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101894

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by jmesnil

"timfox" wrote : More thoughts, how this might look: | | abstract class Packet | { | long correlationID; | } | | interface Dispatcher | { | Handler registerHandler(int handlerID); | | void sendOneWay(Packet packet, int handlerID); | | void sendBlocking(Packet packet, int handlerID); | } | | interface Handler | { | void handle(Message message); | } | I have a simple prototype which is quite similar: | interface Packet | { | long correlationID; | String handlerID; | } | | class CreateSessionRequest extends Packet { | } | class CreateSessionResponse extends Packet { | } | | interface Client | { | Handler registerHandler(int handlerID, Handler handler); | void unregisterHandler(int handlerID); | | void sendOneWay(Packet packet); | | Packet sendBlocking(Packet packet); | } | | interface Handler | { | void handle(Packet packet); | } | * to send a message and forget it: sendOneWay(message) | * to send a packet and be notified later on: register the handler, set the handlerID on the packet and send it one way. Handler will be called back sometimes later. | * to send a message and block until the response arrives: Packet response = sendBlocking(request) | anonymous wrote : | Here are some examples of usage: | ... | I'm writing unit tests based on this simple API to check what we need to cover to integrate MINA into JBoss Messaging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101887#4101887 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101887

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by scott.stark＠jboss.org

"wolfc" wrote : Note that the example works on a MC bean instance. I don't have a MC bean instance, I got an (EJB) class. I'm working on a testcase in the metadata project that illustrates what I'm talking about in terms of a wrapped/proxied jboss view that builds metadata from annotations from the ejb, interceptor, servlet, etc. classes. I"ll post it later today when I get it done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101883#4101883 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101883

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | That doesn't solve the problem. | | The issue is making the xml look like annotations such that EJB3's AOP configuration | (which works off annotations to enable adivces) can see the configuraiton from the xml. I don't see this type of processing in the Ejb3DescriptorHandler, is it there or somewhere else? I'm looking at the standard javaee annotations which affect the org.jboss.metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101879#4101879 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101879

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by jmesnil

"timfox" wrote : To kick off the discussion, here are my initial comments on Jeff's wiki: | | In the diagram where you map MINA objects to JMS objects, we should remember that the JMS layer is a thin layer on the front. | | MINA needs to map to a JMS agnostic layer (which may look a bit like JMS). | | I'm thinking like the following: | | | | JMS Agnostic MINA | | --- -------- ---- | | | | IoConnector IoAcceptor | | \ / | | \ IoSession/ | | Connection----Connection------------------ | | | | | | | | | | Session Session | | / \ \ | | Producer Consumer Consumer | | | I think Connection Session and Consumer are good abstractions for generic messaging | But Producer and Browser only live on the JMS side. | Producing messages and browsing can be methods on the agnostic Session class. | You're right. I did not want to push too much emphasis on the client refactoring task (http://jira.jboss.org/jira/browse/JBMESSAGING-681 ) but it makes the picture clearer overall anonymous wrote : | IOSession will only need to maintain a map of references to the agnostic objects not the JMS objects. | | It will need to maintain such a map so the objects can be called back. | in fact, I'm redesigning that. The IoSession will only now about "agnostic handlers" objects. Each JBM object will then implement this handler interface. anonymous wrote : | In effect the system is *symettrical*. We have a dispatcher on the client side which looks up objects in order to deliver responses, and | we have dispatcher on the server side which looks up objects to deliver requests. | | Really requests and responses are the same thing, it's just the direction of travel is different. I think this symetry is aesthetically pleasing which is often a good sign. | | Regarding the messages: Perhaps it is not such a good idea to classify the messages as synchronous or asychronous since some messages can be sent either asynchronously or synchronously - a good example is sending a message -for persistent messages they are sent synchronously, for non persistently, but the message being sent is the same. | | We should come up with a set of messages (which can be either requests or responses) and the api determines whether they are sent asynchonrous or not. good point. I will clarify the terminology. anonymous wrote : | Another thing to think about is management messages. | | You probably want to define a message type as a management message (or a set of management messsages). | | The idea here is the user could send a messages saying "createQueue" or "getNumberOfMeessafesInQueue" or any number of different operations that we currently do via JMX, and get results that way without JMX. | I'll have a look at it and update http://jira.jboss.com/jira/browse/JBMESSAGING-91 >From what I understand of MINA, it should be quite straightforward to add a handler on the server-side which handlers all the "ManagementMessage" sent on the same connection that regular messages. This should make it simple to separate regular message logic from management message logic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101874#4101874 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101874

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by adrian＠jboss.org

"wolfc" wrote : Note that the example works on a MC bean instance. I don't have a MC bean instance, I got an (EJB) class. So what? A class is a class whether it's an MC bean, an EJB or a Servlet that is your component deployment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101816#4101816 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101816

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by wolfc

Note that the example works on a MC bean instance. I don't have a MC bean instance, I got an (EJB) class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101811#4101811 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101811

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by trustin

"timfox" wrote : To kick off the discussion, here are my initial comments on Jeff's wiki: | | In the diagram where you map MINA objects to JMS objects, we should remember that the JMS layer is a thin layer on the front. | | MINA needs to map to a JMS agnostic layer (which may look a bit like JMS). | | I'm thinking like the following: | | | | JMS Agnostic MINA | | --- -------- ---- | | | | IoConnector IoAcceptor | | \ / | | \ IoSession/ | | Connection----Connection------------------ | | | | | | | | | | Session Session | | / \ \ | | Producer Consumer Consumer | | | I think Connection Session and Consumer are good abstractions for generic messaging | But Producer and Browser only live on the JMS side. | Producing messages and browsing can be methods on the agnostic Session class. Looks great to me. "timfox" wrote : Actually, currently the *only* messages we send asynchronously are: | | 1) consumer change rate | 2) messages send (for non persistent messages) | | All the rest are synchronous. | | We could consider making the following asynchronous: | | 1) Cancel delivery | 2) Start/stop connection | | In terms of how to correlate requests and responses to give synchronous calls, it should be fairly simple to do something like the following: | | 1) Send message with "request id" in message. | 2) Block thread and put in map with key of request id. | 3) When response comes back, look at request id. | 4) Lookup thread in map with that request id and wake it up. | | Some kind of wait/notify should do the trick. MINA 2.x provides exactly what you want as a filter. Please take a look at here: http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/min... "timfox" wrote : Finally one other thing to think about is how MINA is going to support SSL and HTTP. MINA already has support for SSL including StartTLS. It's known to be very reliable. SSL is provided as a filter so just inserting a new SSL filter will enable SSL immediately. No sweat. MINA recently imported AsyncWeb source code into its sandbox, and it should be included into the official distribution after some polishing. MINA has an infra for implementing protocol codec and AsyncWeb provides HTTP codec on top of it. Therefore, you can build your own lightest-weight web server very easily. Please take a look at this example: http://svn.apache.org/viewvc/mina/sandbox/asyncweb/example/src/main/java/... Please feel free to contact me or the MINA team whenever you need some support related with MINA including questions like 'does feature XXX supported in MINA?' Actually we got most, and want to add as much as possible harmonizing all the features with each other. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101788#4101788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101788

18 years, 5 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 November 2007