December 2009 - jboss-dev-forums - Jboss List Archives

[JBoss Identity Development] - Re: ADFS JBossWS and friends

by anil.saldhana＠jboss.com

>From what I can see, you really need to provide some handler at the first instance where the IP origination has to be assumed as the credential. After that, you may need custom login modules to handle the interaction of this morphed security context (username, IP cred) and deal with the AD for the group information. The scenario looks similar to a regular invocation of username/password except that we use IP origination as the cred. The login modules you write should just use the username to get hold of the groups from AD. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268977#4268977 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268977

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

The framework/trunk location is now active View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268972#4268972 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268972

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Incompatible framework dependencies

by thomas.diesler＠jboss.com

I'm ready for the Beta5 release, which will hopefully be tagged today. anonymous wrote : | As a consequence, I suggest to move framework to its natural location again (i.e. projects/runtime/framework/trunk) since its life as reactor project has ended. | Please use | svn switch https://svn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/... | after the Beta5 announcement. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268969#4268969 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268969

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Embedded API Design Problems

by richard.opalka＠jboss.com

"jason.greene(a)jboss.com" wrote : | I do agree with the API consistency argument, however I disagree with using get/set with method chaining. If you are doing a DSL style method chain, you don't need get/set, it's just extra verbosity. Get is logically the no-arg version, and Set is logically the version which takes arguments. In general I think Java developers took the JavaBean recomendations WAY too far. The whole reason JavaBeans required get & set notation was so that an automated tool could figure out what the "properties" are. In other words, JavaBeans are a big hack. | I agree get/set vs. DSL style is subjective. To clarify my stay I'm just complaining about API consistency. The following two classes are some kind of To be, or not to be Hamlet dilemma in a way: package org.jboss.bootstrap.api.as.config; | | public interface JBossASBasedServerConfig<T extends JBossASBasedServerConfig<T>> extends ServerConfig<T> | { | ... | String getBindAddress(); | T bindAddress(String bindAddress); // I'm using set/get style in API design? | ... | } | | package org.jboss.bootstrap.api.server; | | public interface Server<K extends Server<K, T>, T extends ServerConfig<T>> | { | ... | T getConfiguration(); | void setConfiguration(T config); // Or I'm using DSL style in API design? | ... | } "jason.greene(a)jboss.com" wrote : | Also, as a more general comment, Bloch's advice is just that, advice. API design is somewhat subjective, so we shouldn't treat them as hard and fast rules. | Agreed. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268937#4268937 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268937

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Embedded API Design Problems

by richard.opalka＠jboss.com

"jason.greene(a)jboss.com" wrote : I disagree with the server factory example in Rule 4. IllegalArgumentException is the appropriate exception to be thrown | Of course you're right Jason, the correct code should be: package org.jboss.bootstrap.api.factory; | | public class ServerFactory | { | ... | public static Server<?, ?> createServer(final String implClassName) | throws IllegalArgumentException, InstantiationException; // this is WRONG, see RULE 4 | | public static Server<?, ?> createServer(final String implClassName, final ClassLoader cl) | throws IllegalArgumentException, InstantiationException // this is WRONG, see RULE 4 | ... | } | | public class ServerFactory | { | ... | public static Server<?, ?> createServer(final String implClassName) // this is CORRECT | { | ... | catch (InstantiationException ie) | { | throws BootstrapException(ie); | } | ... | } | | public static Server<?, ?> createServer(final String implClassName, final ClassLoader cl) // this is CORRECT | { | ... | throw new IllegalArgumentException(); | ... | } | ... | } | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268935#4268935 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268935

16 years, 4 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Embedded API Design Problems

by richard.opalka＠jboss.com

"david.lloyd(a)jboss.com" wrote : | "richard.opalka(a)jboss.com" wrote : | | DO NOT DECLARE TO THROW RUNTIME EXCEPTIONS | | ... | | * RULE 2.5: Runtime exceptions indicate programmer errors. The best practice is to don't declare them in method signature. | | | | Couldn't disagree more. Putting all possible/expected unchecked exception types in the throws clause gives users a sense of what to expect; also it can hint to IDEs that you might want to add a catch clause for it. And it does no real harm. | | "richard.opalka(a)jboss.com" wrote : | | * shouldn't be declared to be thrown from API if it is assignable from java.lang.RuntimeException and represents programmer error | | | | Again, disagree. | Let me disagree ;) * Runtime exceptions represent programmer errors * Checked exceptions (declared in throws clause) represent special cases user (not programmer) should deal with/know about Here's one example from String.class: The following public String(char value[], int offset, int count) constructor throws StringIndexOutOfBoundsException runtime exception. If I'd change it's signature like you suggest, i.e.: public String(char value[], int offset, int count) throws StringIndexOutOfBoundsException the working with such API would look like: char[] data = ...; | String s = null; | try | { | s = new String(data, 0, 5); | } | catch (StringIndexOutOfBoundsException e) // I'm forced to catch the exception or rethrow it | { | log.error("Damn! Man fix it, then start application again", e); | System.exit(1); | } | IMO runtime exceptions cannot be part of the signatures, because they represent my programming errors. The only way I can fix them is to shutdown application, then fix it and again start the application. I'd end with hundreeds/thousands application exit points :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268934#4268934 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268934

16 years, 4 months

1
0
0 / 0

[EJB 3.0 Development] - Re: javax.naming.NameNotFoundException: QName_ejb_vehicle no

by jaikiran

"jaikiran" wrote : | | | | | +- EJBVehicle[link -> SOAPFaultException_ejb_vehicle] (class: javax.naming.LinkRef) | | | | | A bit weird part in that exception stacktrace is, it probably isn't reporting the jndi name which is leading to this exception. For example, i see this in the stacktrace: | | javax.naming.NameNotFoundException: SOAPFaultException_ejb_vehicle not bound | | After paying a bit more attention at the JNDI contents, shows that the EJBVehicle jndi name is "linking" to SOAPFaultException_ejb_vehicle (and hence that's the name being reported in the NameNotFoundException). So apparently, it's the "linking" of the ENC jndi name to the global jndi name which isn't happening correct. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268927#4268927 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268927

16 years, 4 months

1
0
0 / 0

[EJB 3.0 Development] - Re: javax.naming.NameNotFoundException: QName_ejb_vehicle no

by jaikiran

I don't have the details of those tests, so i am not sure what exactly might be going on. But looking at the stacktrace, it appears to be an application client which appears to be doing a JNDI lookup and running into a NameNotFoundException. Looking the ENC of that application client: +- UserTransaction[link -> UserTransaction] (class: javax.naming.LinkRef) | +- metaData (class: org.jboss.metadata.client.jboss.JBossClientMetaData) | +- env (class: org.jnp.interfaces.NamingContext) | | +- ejb (class: org.jnp.interfaces.NamingContext) | | | +- EJBVehicle[link -> SOAPFaultException_ejb_vehicle] (class: javax.naming.LinkRef) | +- classPathEntries (class: java.util.ArrayList) | I think the right jndi name to use would be java:comp/env/ejb/EJBVehicle in the lookup. A bit weird part in that exception stacktrace is, it probably isn't reporting the jndi name which is leading to this exception. For example, i see this in the stacktrace: javax.naming.NameNotFoundException: SOAPFaultException_ejb_vehicle not bound and also this: javax.naming.NameNotFoundException: QName_ejb_vehicle not bound It would be weird if the code is really looking up "SOAPFaultException_ejb_vehicle" or "QName_ejb_vehicle". As a side note, you probably would want to see this http://www.jboss.org/community/wiki/HowtouseanapplicationclientinJBoss-5, just in case it's a configuration issue. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268926#4268926 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268926

16 years, 4 months

1
0
0 / 0

[JBoss Identity Development] - ADFS JBossWS and friends

by acoliver＠jboss.org

I'm going to ask this as if it were a user question. Anil told me to post it here :-) Mainly I'm proposing a scenario. The basic requirement IE/Flash ----SOAP----JBoss----SOAP----AnotherJBoss---SOAP---NOTJBOSS ActiveDirectory The present solution (https://jira.jboss.org/jira/browse/JBAS-2681): Microsoft Certificate Server Fixed LDAPExtLoginModule to let me authorize only and use the principal from the cert SSL Cert authentication That gets us step 1. Step 2 is how does JBoss call AnotherJBoss passing the credentials Present solution involves NOT calling the same port (because I have to NOT do client cert re-authentication) and passing WS-Security info, using another login module that says "if JBoss said he's authenticated then he must be authenticated". Basically ID and origination IP is the credential. So how do I get a real single sign on session from client call one server and share that session up to another and possible another NOT JBoss server? What software, standards, configuration is involved? How would one put such a thing together. Ideally the client would: * only use SSL Authentication anywhere once (Because cross authentication is a bear) * be able to authorize (get his groups and/or roles) in a convenient manner. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268925#4268925 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268925

16 years, 4 months

1
0
0 / 0

[jBPM Development] - Wondering about where the best place for forms really is

by rmoskal

I've been developing a fairly substantial app and as I work I've been going back and forth on task forms. I keep wanting to be able to assign them to transitions instead of task nodes as is supported by the jpdl. This way way use cases like a a review task, where a manager can "reject", "approve", or "ask for "rework from a another department" can be handled elegantly: I simply show a different form for each transition. I actually started down this path a fair way then become worried that I would freak out my client making such an non-idiomatic use of jbpm. So I started reworking my forms to be task node based. When I moved my forms to the task nodes, they suddenly need to become a lot smarter. I have to show different you elements based on which transition I want to take anyway. The UI is a bit different when one approves something than when one rejects (one might want to reassign the work for example). And different again if I want to send the task to another department for rework. I have many scenarios like the above, and they were handled elegantly when I associated tasks with transitions. I thought about making the reassignment or the rework step to be separate task nodes, but this complexifies the work flows and it seems that from the users and the systems perspective this should be thought of as one task and not many. Has anyone had thoughts down these lines? Am I being perverse? My app has a completely custom admin console (written in extjs) so I'm not losing anything by not having the jbpm console. Color me curious, Robert Moskal Brooklyn, USA View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268923#4268923 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268923

16 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 December 2009