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

[Design of POJO Server] - Re: Naming lookup needs a getClassloader permission

by anil.saldhana＠jboss.com

Where do JIRA issues for "integration" go? I cannot find a project for it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190260#4190260 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190260

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Naming lookup needs a getClassloader permission

by scott.stark＠jboss.org

Same issue with getParent(). Only that should be in the privileged block, loadClass() should not. I guess the domain is null because its the java.lang.ClassLoader.getParent code that is making the permission check call. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190258#4190258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190258

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Naming lookup needs a getClassloader permission

by anil.saldhana＠jboss.com

Suddenly I have turned into a Santa Claus who brings JIRA issues. It is still November. >From the stack trace: | 2008-11-18 13:52:53,897 ERROR [STDERR] (WorkerThread#3[127.0.0.1:40887]) access: domain that failed ProtectionDomain (null <no signer certificates>) | org.jboss.proxy.compiler.Runtime@56683a8d | <no principals> | java.security.Permissions@8465aab ( | (javax.management.MBeanServerPermission findMBeanServer) | (javax.management.MBeanPermission org.jboss.mx.modelmbean.XMBean#*[JMImplementation:type=MBeanRegistry] *) | (javax.management.MBeanPermission org.jboss.security.plugins.JaasSecurityManagerService#*[jboss.security:service=JaasSecurityManager] invoke) | .... | | java.lang.IllegalStateException: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) | at org.jboss.security.plugins.JBossSecurityContext.getUtil(JBossSecurityContext.java:201) | at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.invokeGetRelatedId(JDBCCMRFieldBridge.java:1156) | at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.createRelationLinks(JDBCCMRFieldBridge.java:988) | | .... | Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader) | at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) | at java.security.AccessController.checkPermission(AccessController.java:427) | at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) | at java.lang.ClassLoader.getParent(ClassLoader.java:1224) | at org.jboss.classloading.spi.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:84) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.util.loading.DelegatingClassLoader.loadClass(DelegatingClassLoader.java:97) | at java.lang.ClassLoader.loadClass(ClassLoader.java:251) | at org.jboss.security.SecurityContextFactory.getContextClass(SecurityContextFactory.java:142) | at org.jboss.security.SecurityContextFactory.createUtil(SecurityContextFactory.java:118) | at org.jboss.security.plugins.JBossSecurityContext.getUtil(JBossSecurityContext.java:197) | ... 82 more | | Currently I feel that the offending class is the (surrogate) DelegatingClassLoader that sits in the "integration" project at: http://anonsvn.jboss.org/repos/jbossas/projects/integration/trunk/jboss-c... Here calls to getParent() and super.loadClass need to be shielded with priv blocks? This is because for the users of CL, getting the classloader is a privileged operation, but loading the class is not. Also I am wondering why the protection domain is null. Is it because we are in the bootstrap zone when the perm check is done? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190254#4190254 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190254

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: API first cut available for jBPM3

by benhu

"thomas.diesler(a)jboss.com" wrote : Thanks for your comments, but what should it actually be? | | #1 | ProcessDefinition + Process | | #2 | ProcessDefinition + ProcessInstance | | #3 | something else completely | | Please also consider the usage of these artefacts | | | | ProcessDefinitionService pdService = engine.getService(ProcessDefinitionService.class); | | | | ProcessDefinition procDef = pdService.createProcessDefinition(XML); | | Process proc = procDef.newProcess(); | | | | Token tok = proc.startProcess(); | | | | vs. | | | | ProcessDefinitionService pdService = engine.getService(ProcessDefinitionService.class); | | | | ProcessDefinition procDef = pdService.createProcessDefinition(XML); | | ProcessInstance procInst = procDef.newProcessInstance(); | | | | Token tok = procInst.startProcessInstance(); | | | | Generally, please come up with an alternative suggestion if a given proposal is no good for some reason i.e. I don't like Foo because ... Instead I propose Bar | I think #1 works fine. From my point of view, even for business people when they mention "Process", they can mean both. Because for business people, they do not differentiate between definition and "instance". They think that they draw a diagram and the process is up like magic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190250#4190250 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190250

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: API first cut available for jBPM3

by benhu

is this already included in jBPM 3.3.0 GA? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190249#4190249 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190249

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Only way to remove a managedcomponent is to remove its d

by scott.stark＠jboss.org

Removing the component is the api that should accomplish that. That is does not is simply a bug/not implemented feature. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190237#4190237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190237

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService Guidance

by scott.stark＠jboss.org

Its passing locally for me with the changes I have for a few different profile service issues. I'll check the changes in once a couple other regressions are fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190236#4190236 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190236

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Only way to remove a managedcomponent is to remove its deplo

by charles.crouch＠jboss.com

I know we've discussed this before but I wanted bring it up again now we have a concrete api to work with. Right now the only way to remove a component appears to be as follows: ManagementView mgtView = ProfileServiceFactory.getCurrentProfileView(); | ManagedComponent managedComponent = getManagedComponent(); | ManagedDeployment deployment = managedComponent.getDeployment(); | mgtView.removeDeployment(deployment.getName(), ManagedDeployment.DeploymentPhase.APPLICATION); | mgtView.process(); | But if you have other things defined in the deployment, e.g. the hsqldb-ds.xml deployment contains jboss:service=Hypersonic,database=localDB service as well as the datasource, you end up blowing the whole lot away. There is an api on the deployment which *looks* like it would help, but does not: deployment.removeComponent(managedComponent.getName()); So in the spirit of API completeness for GA I'd like to discuss what api changes we should look to support removing a single component, rather than entire deployment. First idea: -Treat a delete like an update. Don't alter the underlying deployment descriptor, just add a management override that says don't process component foo. Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190228#4190228 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190228

17 years, 4 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Remoting 3: RFC: Simple load balancers

by david.lloyd＠jboss.com

In IRC someone was asking about load balancing. One major benefit of the ClientSource+Client design is the ability to create a wrapper ClientSource which can do things like this. I thought it would be nice to provide some load-balancing implementations as part of the API - perhaps as a separate package, e.g. org.jboss.remoting.lb or something like that. What do you guys think? What load-balancing algorithms should we support beyond simple round-robin? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190220#4190220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190220

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService Guidance

by sguilhen＠redhat.com

Scott, the SecurityManagedObjectsTestCase includes a test for a security bean annotated with @ManagedObject in the security-jboss-beans.xml deployment, and this test started failing since build #1080. You mentioned problems with this specific test before (metadata level annotation not being propagated to the management object factory). Do you think we have the same issue again or is it possible that something else is preventing this bean from showing up through in ManagementView.getComponent? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190219#4190219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190219

17 years, 4 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 2008