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

[Design of JBoss jBPM] - deploying jbpm-console.war in IBM websphere

by btl_ayd

Can anybody explain how can I deploy jbpm-console.war in wasce 2.0(IBM websphere)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160332#4160332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160332

16 years

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Re: Duplicate jmx remoting in jbossas5

by adrian＠jboss.org

"dimitris(a)jboss.org" wrote : | I think people want that because it's the standard way now to access remotely an mbeanserver using service url: | | service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector | | In this regard, I don't see how they can be merged in an mcbean implementation? | | Or maybe we can retire RMIAdaptor. You should be able to bind the JSR160 MBeanServerConnection in place of the RMIAdapter - assuming you're not bothered about implementing the old interfaces? But I think you'll find classloading issues? I don't think it will understand how to unmarshal objects into scoped deployments see InvokerAdapterService::invoke View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160325#4160325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160325

16 years

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Re: Duplicate jmx remoting in jbossas5

by scott.stark＠jboss.org

Ok, I see. There is a current failing test due to problems with not implmenting callback handlers. Perhaps the jdk version does not support that. The problem with the RMIAdaptor is that its been the connector interface for years now. I would expect we would have to at least provide a mapping of a proxy onto the jmx impl or at least the ability to continue to deploy the RMIAdaptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160324#4160324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160324

16 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Legacy client SecurityAssociation

by adrian＠jboss.org

"anil.saldhana(a)jboss.com" wrote : | | Most clients (if they used the SecurityAssociation api) will be using on the client | | to do a single login for the entire jvm. | | | | What is your personal opinion on this? I know this has been the legacy approach but what do you think about providing vm-wide security context? What's wrong with it? We're talking about a traditional client, not a server that hosts many apps that can't be trusted. Why can't there just be a mode which enables a global security context? On the SecurityAssociation itself, I'm not really that worried since people should always be using JAAS to establish the login, I'm talking about the new stuff not having the same capabilities. The real fix is to remove any mentioned of SecurityAssociation from the testsuite. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160322#4160322 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160322

16 years

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Re: Duplicate jmx remoting in jbossas5

by dimitris＠jboss.org

I understand that jmx-remoting.sar is just a wrapper on top of the jdk provided remoting implementation. AFAIR, tomL had started writing his own but then jdk5 came so he just wrapped that in a service mbean. I think people want that because it's the standard way now to access remotely an mbeanserver using service url: service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector In this regard, I don't see how they can be merged in an mcbean implementation? Or maybe we can retire RMIAdaptor. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160321#4160321 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160321

16 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Legacy client SecurityAssociation

by anil.saldhana＠jboss.com

The above fix is applicable to ejb apps. I need to see what the issue is for the xmbean test (doing now) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160320#4160320 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160320

16 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Legacy client SecurityAssociation

by anil.saldhana＠jboss.com

The issue exists here: http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/pr... for the http://anonsvn.jboss.org/repos/jbossas/trunk/server/src/main/org/jboss/pr... The Client Side SecurityInterceptor has no clue whether the user used the legacy SecurityAssociation or the newer SecurityClient. I can add additional logic to see if SA.getServer == false, then also consider sa.getprincipal, sa.getcredential as a potential provider of security context. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160319#4160319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160319

16 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Legacy client SecurityAssociation

by anil.saldhana＠jboss.com

| Most clients (if they used the SecurityAssociation api) will be using on the client | to do a single login for the entire jvm. | What is your personal opinion on this? I know this has been the legacy approach but what do you think about providing vm-wide security context? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160316#4160316 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160316

16 years

1
0
0 / 0

[Design of Security on JBoss] - Re: Legacy client SecurityAssociation

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/SECURITY-236 With this change that came in 2.0.2.CR4, I have ensured that the client side SA usage works as is. But yes, on the server side, SA usage should set the setServer flag. But the server side usage of SA should by default have the server flag set due to the JaasSecurityManagerService->startService() | protected void startService() throws Exception | { | // use thread-local principal and credential propagation | if (serverMode) | SecurityAssociation.setServer(); | I will take a look at the tests that you mention that are failing and see why this is an issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160314#4160314 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160314

16 years

1
0
0 / 0

[Design of JBoss ESB] - Re: Wise based soap client for esb

by jeffdelong

I checked out your workspace, and ran ant dist. Got the following error: [java] compile: [java] [javac] Compiling 6 source files to /shared/workspace/ws-wise/product/services/soap/build/classes [java] [javac] /shared/workspace/ws-wise/product/services/soap/src/main/java/org/jboss/soa/esb/actions/soap/wise/SOAPClient.java:25: cannot access it.javalinux.wise.core.client.InvocationResult [java] [javac] bad class file: /shared/workspace/ws-wise/product/services/soap/lib/ext/Wise-core.jar(it/javalinux/wise/core/client/InvocationResult.class) [java] [javac] class file has wrong version 50.0, should be 49.0 [java] [javac] Please remove or make sure it appears in the correct subdirectory of the classpath. [java] [javac] import it.javalinux.wise.core.client.InvocationResult; [java] [javac] ^ [java] [javac] 1 error [java] BUILD FAILED [java] /shared/workspace/ws-wise/product/build.xml:210: The following error occurred while executing this line: [java] /shared/workspace/ws-wise/product/services/build.xml:11: The following error occurred while executing this line: [java] /shared/workspace/ws-wise/product/services/soap/base-project-build.xml:56: Compile failed; see the compiler error output for details. [java] Total time: 51 seconds BUILD FAILED /shared/workspace/ws-wise/product/build.xml:474: The following error occurred while executing this line: /shared/workspace/ws-wise/product/build.xml:96: Java returned: 1 Any thoughts? Thanks, Jeff View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160313#4160313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160313

16 years

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 June 2008