October 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Analytical and operational dashboards

by kukeltje

JBPM-2, you solved it, I reported it ;-) (as well as JBPM-1 btw) anonymous wrote : That's a too unspecific. We can produce graphs of information that's put into relation. | I.e. comparing the number of process instances this month with the number of process instances last month. And this for comparing weeks, days, is that to unspecific? It's just like downdrilling. Basic view is e.g. comparing months (like in the dow-jones...ahhh bad example nowadays ;-) ). Clicking on a month then you see the weeks of this month, or select start and end week (like a sliding window) and downdrilling shows a day with e.g. the hour as the unit) anonymous wrote : In what context to problems appear? Sometimes in the context of a month, sometimes a week, sometimes a day. And they are not always 'problems' sometimes it is detecting a trend so more people can be hired the comming day's. Current values (may different ones like number of instances, duration etc) visible in relation to the average of a certain period (which in turn is debatable) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183994#4183994 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183994

15 years, 12 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: One-way requests are still the black sheep

by trustin

I'd prefer to remove it now and add it later when the requirement arises again. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183989#4183989 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183989

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by ALRubinger

"wolfc" wrote : If it was the sync on cacheMap I would say a deadlock would happen, not some timeout of 30 seconds. There's no contention issue. Other Threads will block. Bet you a Bacardi 'n Coke. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183978#4183978 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183978

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by bstansberry＠jboss.com

"wolfc" wrote : That takes care of the cache configuration, but I also want to know what's behind this passivation issue. | | Is passivating or activating the culprit? | On what OS is this? | | If it was the sync on cacheMap I would say a deadlock would happen, not some timeout of 30 seconds. Needs to be proven of course, but SimpleStatefulCache.SessionTimeoutTask holds a lock on the cacheMap while it iterates through the contents and passivates. If there are a lot of beans (knowing Andy, this is a load test and there are) that could take a while. Any SimpleStatefulCache.get() request will block in the meantime. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183977#4183977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183977

15 years, 12 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Remoting 3: Secure Remote Classloading (JBREM-929)

by david.lloyd＠jboss.com

Various parties have already pointed out the security concerns with the existing remote classloading system and the need to better integrate with the AS classloader system. There are (at least) three points where security is significant to remote classloading. (1) The loading endpoint needs to be able to control whether or not a given class may be remotely loaded from a given peer, and by whom. This could possibly be implemented as some sort of permission, with parameters to specify what range of classes the permission applies to and what remote services may be loaded from. In addition it might be beneficial to have a global "off switch" as an easy way to secure an endpoint. (2) The loading endpoint needs to be able to assign permissions to the loaded class. This should be doable using the client's security policy mechanism, preferably using some type of codeBase URL that is able to specify the source of the loaded class. (3) The endpoint from which the classes are sent needs to be able to restrict the scope of what classes are made available to the client, so as not to "leak" any potentially sensitive classes. This could possibly function at a module granularity (JAR file) or at a package/class granularity. A quick note - in Remoting 3, classes may conceptually be sent either from client to server (as part of a request) or from server to client (as part of a reply). Here's a couple proposals for how to implement it. (1) A Remote VFS scheme This solution entails creating a VFS plugin that uses Remoting to load resources ("vfsremote:<remoting-service-URI>" perhaps). A Remoting service would be created which exports some subset of one system's VFS. A client would then connect to this service, creating a VFS view of the remote system. Then a classloader which includes a VFSClassLoader referencing this view is created and injected into the Remoting client configuration (specifically, as the classloader used by the ClassResolver of the MarhsallerFactory). This can then be secured by using a VFS codeBase URL (assuming we get that working, which I'm confident is possible, one way or another). Pros: very elegant. Uses all our various cool JBoss doodads together. No enhancements to the Remoting codebase are necessary. No new classloader implementations are needed. Avoids the various issues that have come up with the current implementation. Uses standard security configuration. Possibly has other uses outside of remote classloading. Cons: standalone clients might be very complex, having to include a bunch of our classloading and VFS stuff in order to gain access to the remote classes/jars/etc. We would need to devise a way to simplify client configuration as well - maybe even producing a special API for writing simple clients which preconfigures all this stuff at once. (2) A RemoteClassLoader implementation With this solution, we create a ClassLoader implementation which uses a custom remote classloading service. The server side would wrap one or more ClassLoader instance(s) to which class lookups are delegated. Pros: simpler for clients - they'd just have to create a RemoteClassLoader implementation. Cons: there are a lot of features in classloaders that do not have a clear mapping across a remote channel. Getting resources, packages, and security manager considerations all weigh in to this. I would expect a lot more design bugs with this approach compared to implementation bugs. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183976#4183976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183976

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by bstansberry＠jboss.com

What I love about this Andy is it appears you are demonstrating taht what I expect should work does work -- a bean annotated @Clustered w/o a remote interface: https://jira.jboss.org/jira/browse/EJBTHREE-1540 Andrew, remember or chat about this a couple months back? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183975#4183975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183975

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by wolfc

That takes care of the cache configuration, but I also want to know what's behind this passivation issue. Is passivating or activating the culprit? On what OS is this? If it was the sync on cacheMap I would say a deadlock would happen, not some timeout of 30 seconds. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183973#4183973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183973

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by ALRubinger

"andy.miller(a)jboss.com" wrote : I had to work on FY'10 budget stuff until late last night, and I had to sit on a call from 6:30 this morning to go over it with a bunch of folks, so I'm just now getting around to creating a slimmed down test case. Wasn't meant to pressure you, just showing what I'll need to reflect this in the community suite. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183972#4183972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183972

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by andy.miller＠jboss.com

"bstansberry(a)jboss.com" wrote : I see it. You are using : | | import org.jboss.annotation.ejb.Clustered; | | which was removed a long time ago as part of the reorganization of EJB3 annotations; now it is: | | import org.jboss.ejb3.annotation.Clustered; Okay, so I have to rebuild this against the AS 5 CR 2 libraries then. I was hoping to just be able to take what I had built before, but that's okay. I can add the AS 5 CR 2 libraries to my project manually, and rebuild. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183971#4183971 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183971

15 years, 12 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Passivating EJB 3 Stateful Session Beans stops the World

by bstansberry＠jboss.com

I see it. You are using : import org.jboss.annotation.ejb.Clustered; which was removed a long time ago as part of the reorganization of EJB3 annotations; now it is: import org.jboss.ejb3.annotation.Clustered; View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183968#4183968 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183968

15 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008