[JBoss JIRA] Created: (JBAS-5306) HttpNamingContextFactory doesn't support http basic authentication
by David Smiley (JIRA)
HttpNamingContextFactory doesn't support http basic authentication
------------------------------------------------------------------
Key: JBAS-5306
URL: http://jira.jboss.com/jira/browse/JBAS-5306
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Naming
Affects Versions: JBossAS-4.2.2.GA
Reporter: David Smiley
Assigned To: Scott M Stark
If I were to secure the http invoker in my JBoss (in accordance with documentation, by using the /invoker/restricted/JNDIFactory/ url", then I would consequently need to supply a username & password to whatever client code is going to do the JNDI lookups. However, the class org.jboss.naming.HttpNamingContextFactory doesn't do any authentication handling whatsoever. It should be examining the principal & credentials and adding the authentication header for basic auth. It does delegate to the JDK's URL handling under the hood, but that code don't support automatic authentication from the url. So for example if I were to do: http://username:password@myserver:8080/invoker/restricted/JNDIFactory then strangely enough, only the username is passed on in a header, no password.
I'm contemplating writing my own implementation of HttpNamingContextFactory which uses the efficient apache jakarta commons httpclient library instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-1192) ClassProxyHack breaks all EJB3 Web Service endpoints
by Thomas Diesler (JIRA)
ClassProxyHack breaks all EJB3 Web Service endpoints
----------------------------------------------------
Key: EJBTHREE-1192
URL: http://jira.jboss.com/jira/browse/EJBTHREE-1192
Project: EJB 3.0
Issue Type: Bug
Reporter: Thomas Diesler
Assigned To: Carlo de Wolf
Fix For: AS 5.0.0.CR1
The recent introduction of ClassProxyHack breaks all EJB3 endpoints
[tdiesler@tdvaio trunk]$ ant tests-smoke
tests-run-internal:
[junit] Running org.jboss.test.ws.jaxws.samples.asynchronous.AsynchronousDispatchTestCase
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.031 sec
[junit] Running org.jboss.test.ws.jaxws.samples.asynchronous.AsynchronousProxyTestCase
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.688 sec
[junit] Running org.jboss.test.ws.jaxws.samples.context.WebServiceContextJSETestCase
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.879 sec
[junit] Running org.jboss.test.ws.jaxws.samples.eardeployment.EarTestCase
[junit] JBoss Inc., JBoss Web Services - Native, jbossws-3.0-native-2.0.4.DEV (build=200802151213)
[junit] Retrieving document at 'http://localhost:8080/earejb3/EJB3Bean?wsdl'.
[junit] Retrieving document at 'http://localhost:8080/earjse/JSEBean?wsdl'.
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 6.163 sec
15:07:08,631 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
java.lang.ClassCastException: org.jboss.ejb3.session.ClassProxyHack
at org.jboss.wsf.container.jboss50.InvocationHandlerEJB3.invoke(InvocationHandlerEJB3.java:92)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:220)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:418)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:274)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:191)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:124)
at org.jboss.wsf.stack.jbws.EndpointServlet.service(EndpointServlet.java:84)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[JBoss JIRA] Created: (JBCOMMON-42) NotifyingBufferedInputStream notify bug after reading one byte
by Bart Vanhaute (JIRA)
NotifyingBufferedInputStream notify bug after reading one byte
--------------------------------------------------------------
Key: JBCOMMON-42
URL: http://jira.jboss.com/jira/browse/JBCOMMON-42
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: common-core
Reporter: Bart Vanhaute
Assigned To: Dimitris Andreadis
While I was inspecting something totally unrelated, I came across this bug:
The code for reading one byte in org.jboss.util.stream.NotifyingBufferedInputStream contains:
public int read()
throws IOException
{
int result = super.read();
if (result == -1)
return result;
checkNotification(result);
return result;
}
The checkNotification method checks if chunkSize bytes have already been read. Obviously, the above method should be calling checkNotification(1), because only one byte is read.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[JBoss JIRA] Created: (JASSIST-51) Editing a NewExpr results in a VerifyError (inconsistent stack height)
by Yanic Inghelbrecht (JIRA)
Editing a NewExpr results in a VerifyError (inconsistent stack height)
----------------------------------------------------------------------
Key: JASSIST-51
URL: http://jira.jboss.com/jira/browse/JASSIST-51
Project: Javassist
Issue Type: Bug
Environment: Javassist 3.7, JDK 1.6.0_03 on WinXP
Reporter: Yanic Inghelbrecht
Assigned To: Shigeru Chiba
The code below is the simplest case I could find that reproduces the error. The code contains two classes : Client and Main. Client is the class that gets instrumented, Main does the instrumenting. The error that result is :
Exception in thread "main" java.lang.VerifyError: (class: test_try_catch/Client, method: instrumentMe signature: ()V) Inconsistent stack height 0 != 1
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at test_try_catch.Main.main(Main.java:30)
Javassist somehow messes up on instrumenting the NewExpr in method Client#instrumentMe
The weird thing about this bug is, the verifyError only occurs when the method containing the NewExpr also contains a try/catch block!
For me this is a show stopper, not using try/catch blocks is not really an option :o)
I hope you agree this is a high priority issue, because our project cannot be released because of this.
Best regards,
Yanic
--------- source code for Client.java below
package test_try_catch;
import java.util.ArrayList;
public class Client {
public void instrumentMe() {
// we need a 'new' expression to instrument, the exact type is not important
new Object();
// if the try/catch block below is removed, the error does not occur
try {
System.out.println();
} catch (Throwable t) {
//
}
}
}
--------- source code for Main.java below
package test_try_catch;
import java.lang.reflect.Method;
import javassist.CannotCompileException;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtMethod;
import javassist.Loader;
import javassist.NotFoundException;
import javassist.Translator;
import javassist.expr.ExprEditor;
import javassist.expr.NewExpr;
public class Main {
public static void main(String[] args) throws Exception {
ClassPool pool = new ClassPool(true);
Loader cl = new Loader();
try {
cl.addTranslator(pool, new MyTranslator());
} catch (Exception e) {
e.printStackTrace();
return;
}
// load the Client class
Class clientClass=cl.loadClass("test_try_catch.Client");
// create an instance
Object client=clientClass.newInstance();
// execute Client#instrumentMe
Method callMethod=clientClass.getMethod("instrumentMe", new Class[]{});
callMethod.invoke(client, new Object[]{});
}
static public class MyTranslator extends ExprEditor implements Translator {
public void onLoad(ClassPool pool, String classname) throws NotFoundException, CannotCompileException {
CtClass cc = pool.get(classname);
modify(cc);
}
public void modify(CtClass c) throws CannotCompileException {
for (CtMethod m : c.getMethods()) {
m.instrument(this);
}
}
@Override
public void edit(NewExpr m) throws CannotCompileException {
// no changes, for simplicity's sake
String block = "{$_=$proceed($$);}";
m.replace(block);
}
public void start(ClassPool pool) throws NotFoundException, CannotCompileException {
// do nothing
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[JBoss JIRA] Created: (JBMESSAGING-1213) Client side connection exception is not thrown on the client side when the lease times out
by Jay Howell (JIRA)
Client side connection exception is not thrown on the client side when the lease times out
------------------------------------------------------------------------------------------
Key: JBMESSAGING-1213
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1213
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Remoting
Affects Versions: 1.4.0.SP3
Reporter: Jay Howell
Assigned To: Tim Fox
Clients that are connected that experience a lease timeout are not notified that they no longer have a connection on the server. The behavior is that clients think that they are alive, while they will no longer get any messages. Also something of note, the Server side pinger has been disabled for JBM.
Note: this is an issue that can either be fixed on the remoting side or the JBM side. Discussing this with Clebert, it may be prudent to fix it on both sides. I've opened this jira to facilitate the communication about where the logic should go. Please refer to the linked Remoting Jira JBREM-888 that was opened for this same topic.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months
[JBoss JIRA] Created: (JBMICROCONT-233) SchemaResolverDeployer.parse(VFSDeploymentUnit unit, VirtualFile file, T root) needs to validate file InputStream
by Scott M Stark (JIRA)
SchemaResolverDeployer.parse(VFSDeploymentUnit unit, VirtualFile file, T root) needs to validate file InputStream
-----------------------------------------------------------------------------------------------------------------
Key: JBMICROCONT-233
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-233
Project: JBoss MicroContainer
Issue Type: Bug
Affects Versions: JBossMC-2.0.0.Beta10
Reporter: Scott M Stark
Assigned To: Scott M Stark
Its possible that the file passed into parse fails to return a non-null InputStream. This produces this type of uninformative error:
... 25 more
Caused by: java.net.MalformedURLException
at java.net.URL.<init>(URL.java:601)
at java.net.URL.<init>(URL.java:464)
at java.net.URL.<init>(URL.java:413)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:189)
... 29 more
The file InputStream needs to be validated for null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 2 months