[Design of EJB 3.0] - The default local interface (vs. EJBTHREE-785)
by wolfc
With the implementation of EJBTHREE-785 we consider all interfaces implemented by the bean and it's super classes to be a candidate for remote or local business interface. This leads to problems in establishing the default local business interface.
"EJB 3 4.6.6" wrote : * If bean class implements a single interface, that interface is assumed to be the business interface of the bean. This business interface will be a local interface unless the interface is designated as a remote business interface by use of the Remote annotation on the bean class or interface or by means of the deployment descriptor.
| * A bean class is permitted to have more than one interface. If a bean class has more than one interface?excluding the interfaces listed below?any business interface of the bean class must be explicitly designated as a business interface of the bean by means of the Local or Remote annotation on the bean class or interface or in the deployment descriptor.
The second line allows for the inheritance of interfaces from a super (sort of). But the first specifies that if the bean itself implements one interface it must be the business interface (either remote or local). So any inherited interfaces become invalid at that point.
If there are no objections, we'll implement it by the letter.
http://jira.jboss.com/jira/browse/EJBTHREE-785
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093070#4093070
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093070
18 years, 6 months
[Design of POJO Server] - Russian Doll Ordering
by anil.saldhana＠jboss.com
I am not sure what the official take on this issue is at the moment. I remember Scott telling me that we will need to add explicit dependencies (or such) to make the russian doll ordering to work.
For example, I have a situation in the test suite as follows:
| org.jboss.test.security.test.DeepCopySubjectUnitTestCase
|
This test uses an ear called as deepcopy.ear that internally contains a war file and has a xxx-service.xml inside that is specified in the jboss-app.xml
The issue I see at the moment is the following:
| Caused by: java.lang.IllegalStateException: jboss.security.tests:service=DynamicLoginConfigDeepCopyTest is already installed.
| at org.jboss.dependency.plugins.AbstractController.install(AbstractContr
| oller.java:525)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractContr
| oller.java:398)
| at org.jboss.system.ServiceController.doInstall(ServiceController.java:6
| 41)
|
I am unsure if the SecurityDeployer is influencing this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4093068#4093068
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4093068
18 years, 6 months
[Design of JBoss jBPM] - [sim] using simulation engine for load testing?
by camunda
I just want to make an own discussion thread for it.
Let's summarize, what happened till now:
Ronald:
anonymous wrote : Also, it is simulation, but besides that, a great step towards loadtesting....(sim for the business managers, loadtesting for the it managers ;-) )
Bernd:
anonymous wrote : Hmm, I am not really sure about this usage. Load testing normally involves some more sophisticated load generating strategy, for example with more than one computer. This is not addressed by the simulation engine at the moment, even if it could be, if simulation runs are too slow. But this would be stuff for the very far future ;-)
|
| And you don't get real information about calculation time, because simulation time has nothing to do with real time. And all figures and logs refer only to the model time.
Ronald:
anonymous wrote : Agreed, but having realistic scenario's is great.... something that often lacks so called 'load tests' And yes, more needs to be done, but I'd hate to have to do duplicate work... :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092918#4092918
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092918
18 years, 6 months
[Design of JBoss Portal] - Switch portlet-windows in regions
by badock
Hi, i have a quick question...
I have disable the dashboard thing because i don't want the users (including the admin) to use it...
However, it turns out I want the admin to be able to switch portlets-windows in regions, like for instance, there is portlet1 in regionA, and portlet2 in regionB, and i want to have portlet1 in regionB and portlet2 in regionA.
It seems not possible to do that without the drag-and-drop-dashboard feature, i mean, using the webadmin thing.
If someone has an idea about that, that would be great, thanks !
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092910#4092910
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092910
18 years, 6 months
[Design of JBoss Web Services] - BASIC auth and WS-Security
by thomas.diesler＠jboss.com
It seems that we use the standard jaxrpc/jaxws properties as WSSE username token
| if (opConfig.getUsername() != null)
| {
| Object user = ctx.get(Stub.USERNAME_PROPERTY);
| Object pass = ctx.get(Stub.PASSWORD_PROPERTY);
|
| if (user == null && pass == null)
| {
| user = ctx.get(BindingProvider.USERNAME_PROPERTY);
| pass = ctx.get(BindingProvider.PASSWORD_PROPERTY);
| }
|
| if (user != null && pass != null)
| {
| operations.add(new OperationDescription<EncodingOperation>(SendUsernameOperation.class, null, user.toString(), pass.toString(), null));
| ctx.put(StubExt.PROPERTY_AUTH_TYPE, StubExt.PROPERTY_AUTH_TYPE_WSSE);
| }
| }
|
The side effect is that the wsse username token will always be sent via BASIC auth.
Is this by design? I thought the wsse username token is independent of transport security.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4092905#4092905
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4092905
18 years, 6 months