[Design of JBoss ESB] - Re: Registry Design
by arvinder
Some food for though, which may be relevant or not.
1) The state of an endpoint service in the registry. This would be needed for clients and also reporting.
2) Each service should be categorised, either via a hardcoding of type under the registry, or a spi provided categorization. This may lead to signatures like searchByCategory etc.
3) Policies per service, and optionally on a per category basis.
4) I'm not sure at what point we need to think of templating services for each category, so that clients may at least know what template to possible work to, the underlying service impl can be changed transparently.
5) Aside from just services, will the registry hold dependant objects such as an XSD if there is say a validation service? Would this be classed as a ServiceResources and be grouped under the ServiceEntry such as ServiceEntry.getResources() ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968060#3968060
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968060
19 years, 7 months
[Design of JBoss jBPM] - Re: web services question
by tom.baeyens＠jboss.com
"kukeltje" wrote : So you prefer 1, while I prefere 2.
|
i don't really have a preference about how the schema looks like. in both cases it is readable. more important is which techniques we'll be using to do the java-to-XML conversion and the SOAP framework we'll use for exposing our webservice.
So you would start with JSR 109: Web Services for Java EE, Version 1.2
This relies on JAX-WS (next version of JAX-RPC) and JAXB 2.0.
I don't know these technologies. But my concern is: how easy or hard will it be to create new commands and expose them through that web service ?
I want to get a better understanding of the ins and outs going from development to deployment:
* we need a J2EE 1.4 container
* we have to put @WebService in the CommandService SLSB ?
* we have to generate the JAXB bindings from the command beans themselves ? is it hard to customize ? do you think that will be needed often or will the default name mappings be sufficient ?
* anything else we need to do ?
You don't have to convince me yet... cause i just don't get it yet. One way to get more insights is if you just go ahead and implement the basic structure. So that we can have a look out how it works.
Alex's opinion is always appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968052#3968052
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968052
19 years, 7 months
[Design of Security on JBoss] - Re: SecurityContext
by wolfc
Hi guys, two things with the new SecurityContext:
1. I got a NPE here:
| java.lang.NullPointerException
| at org.jboss.security.SecurityContext.setRoles(SecurityContext.java:91)
|
2. I'm trying to get this all up and running in EJB3 Embedded, but I haven't got a full set of MBeans running. So I get:
| java.lang.IllegalStateException: Cannot obtain Application Policy::jboss.security:service=XMLLoginConfig
| at org.jboss.security.Util.getApplicationPolicy(Util.java:669)
| at org.jboss.security.SecurityContext.setRoles(SecurityContext.java:87)
| at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:595)
| at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:245)
| at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:384)
| at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:143)
| at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:108)
|
Will the need for this MBean be enforced?
Full stack trace for the NPE:
| java.lang.NullPointerException
| at org.jboss.security.SecurityContext.setRoles(SecurityContext.java:91)
| at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:595)
| at org.jboss.security.plugins.JBossAuthorizationManager.doesUserHaveRole(JBossAuthorizationManager.java:245)
| at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:384)
| at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:143)
| at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:108)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
| at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:102)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:263)
| at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
| at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:848)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:447)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:520)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:257)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
| at org.jboss.remoting.Client.invoke(Client.java:612)
| at org.jboss.remoting.Client.invoke(Client.java:604)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.test.bank.TellerInterceptor.invoke(TellerInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
| at $Proxy3.greetChecked(Unknown Source)
| at org.jboss.ejb3.test.bank.unit.BankDeploymentDescriptorTestCase.testInjectionAnnotations(BankDeploymentDescriptorTestCase.java:117)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.test.bank.TellerInterceptor.invoke(TellerInterceptor.java:53)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
| at $Proxy3.greetChecked(Unknown Source)
| at org.jboss.ejb3.test.bank.unit.BankDeploymentDescriptorTestCase.testInjectionAnnotations(BankDeploymentDescriptorTestCase.java:117)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968050#3968050
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968050
19 years, 7 months
[Design of JBoss jBPM] - Re: web services question
by kukeltje
So you prefer 1, while I prefere 2.
Using 1 makes it impossible to generate any good client since anything is allowed. In the second version, you can have defined complex types per command. I prefere that one. Errorhandling is more simple since it comforms to an xsd or not. We do not have to program the checking of the '[any mixed content]' in relation to the name. So therefor I mention an XSD (and WSDL) . I tried this with the eclipse webservice explorer and could control the process from there with explicit commands and corresponding fields.
JSR-109 seems perfectly capable for this. No DOM parsing needed if you use example 2 and not one.
Maybe we should flip a coin or let Alex decide. He is the webservice guru ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968042#3968042
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968042
19 years, 7 months
[Design of JBoss jBPM] - Re: transactions, commands and packaging
by tom.baeyens＠jboss.com
"david.lloyd(a)jboss.com" wrote : The way I see it, no transaction should span more than a single request or form submission on the webapp.
|
correct. i see typically 2 possible transactions in one request:
1) the command transaction. if a user performs a UI operation that results in an update to jbpm this is done first in a separate transaction. of course, not all requests have a command transaction since many links are just navigation.
2) view rendering transaction. this is the transaction that is used to read all the data from the database to render the next view.
by splitting these transactions, the time that the command/update transaction is kept open is minimal. it is that command/update transaction that may acquire locks (optimistic or pessimistic).
in no case, transactions should span multiple requests.
one way of implementing the above transaction strategy is by making use of the JSF phase listener. the update command will be in the invoke application phase. so before that phase begins, a JbpmContext can be created and injected in a request-scoped bean. (e.g. the JbpmBean). Then after the invoke applications phase, that JbpmContext could be closed and a new one could be created for the rendering phase. After the rendering phase, also that JbpmContext could be closed.
Then it is a matter of binding the JbpmContext lifetime to the transaction in the standard or enterprise environment respectively.
thoughts ?
"david.lloyd(a)jboss.com" wrote :
| Also, I don't really like the idea of keeping a heavyweight state on the web application side either. Ideally the web application would be purely stateless.
|
I agree. id's if jBPM objects should be in the rendered client page. So that the next request is always stateless.
Does that correspond with what you say ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968020#3968020
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968020
19 years, 7 months
Virus intercepted
by MAILER-DAEMON＠lists.jboss.org
A message sent from <PayPal(a)solopar.com.br> to
<jboss-dev-forums(a)lists.jboss.org>
<jboss-user(a)lists.jboss.org>
contained HTML.Phishing.Pay-110 and has not been delivered.
19 years, 7 months
[Design of JBoss ESB] - Re: Registry Design
by tfennelly
anonymous wrote : Now one question about the getServices method. Will any user get the list of all Services or will there be some type of roles present here?
Not sure Mughdo. I guess this is really a requirements issue so lets wait to hear what Mark/Burr have to say on that.
anonymous wrote : Another thing, JAXR provides a lot of methods for the RegistryObject interface. I am wondering if we need to provide implementations for all of them?
My personal preference would be to only use what we need i.e. travel as light as possible!
I think we can probably park this until Mark gets a chance to review it. Not that we've done a whole lot, but we do seem to be taking in a particular direction now. Lets wait and see what Mark's thoughts are at this stage. What do you think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968019#3968019
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3968019
19 years, 7 months
