March 2008 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

4
9
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-542) Define a precedence order between AND and OR pointcut connectors

by Flavia Rainone (JIRA)

Define a precedence order between AND and OR pointcut connectors ---------------------------------------------------------------- Key: JBAOP-542 URL: http://jira.jboss.com/jira/browse/JBAOP-542 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Flavia Rainone Currently, there is no precedence order between the AND and the OR connectors in the pointcut language. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-541) Use simple synchronization rather than rw locks when initialising lazy collections

by Kabir Khan (JIRA)

Use simple synchronization rather than rw locks when initialising lazy collections ---------------------------------------------------------------------------------- Key: JBAOP-541 URL: http://jira.jboss.com/jira/browse/JBAOP-541 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.CR8 -- 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

1
1
0 / 0

[JBoss JIRA] Created: (JBDEPLOY-12) Fix EARStructureUnitTestCase::testNotAnEAR test

by Ales Justin (JIRA)

Fix EARStructureUnitTestCase::testNotAnEAR test ----------------------------------------------- Key: JBDEPLOY-12 URL: http://jira.jboss.com/jira/browse/JBDEPLOY-12 Project: JBoss Deployers Issue Type: Sub-task Reporter: Ales Justin Assigned To: Ales Justin Fix For: JBDEPLOY-2.0.0.Beta11 Fixt the test. Currently it expects to fail, although jar structure deployer recognizes deployment. -> This gets recognised by the jar deployer assertNotValid("/structure/ear", "notanear"); -- 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

1
1
0 / 0

[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

2
3
0 / 0

[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

3
4
0 / 0

[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

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-5304) Upgrade AOP Project to Latest Snapshot

by Andrew Lee Rubinger (JIRA)

Upgrade AOP Project to Latest Snapshot -------------------------------------- Key: JBAS-5304 URL: http://jira.jboss.com/jira/browse/JBAS-5304 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Andrew Lee Rubinger Assigned To: Kabir Khan Priority: Critical Fix For: JBossAS-5.0.0.CR1 Kabir: A while ago you'd added some classes to the AOP client JAR for me (see linked issue). Now we just need to get this version into AS so that the classes make it into jbossall-client.jar. Thx. :) S, ALR -- 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

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2008