September 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (EJBTHREE-27) Allowed methods

by Carlo de Wolf (JIRA)

[ https://jira.jboss.org/jira/browse/EJBTHREE-27?page=com.atlassian.jira.pl... ] Carlo de Wolf resolved EJBTHREE-27. ----------------------------------- Resolution: Done > Allowed methods > --------------- > > Key: EJBTHREE-27 > URL: https://jira.jboss.org/jira/browse/EJBTHREE-27 > Project: EJB 3.0 > Issue Type: Feature Request > Affects Versions: Preview 5 > Reporter: Bill Burke > Assignee: Carlo de Wolf > Fix For: 1.0.0-Beta1 > > > EJB specification has semanatics for what methods can be called when. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-2766) tomcat libraries not available to remoting when using http transport

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-2766?page=com.atlassian.jira.plug... ] Dimitris Andreadis closed JBAS-2766. ------------------------------------ Resolution: Won't Fix Assignee: (was: Tom Elrod) > tomcat libraries not available to remoting when using http transport > -------------------------------------------------------------------- > > Key: JBAS-2766 > URL: https://jira.jboss.org/jira/browse/JBAS-2766 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: JBossAS-4.0.4.CR2 > Reporter: Tom Elrod > Priority: Critical > Attachments: jboss-service.xml, remoting-service.xml, standardjboss.xml > > > As of JBoss Remoting 1.4.0 final (which is now included for JBossAS 4.0.4 and JBossAS 5), the http transport implementation uses Tomcat connectors. Therefore, the following jars need to be available to remoting when running within JBossAS: > tomcat-apr.jar > tomcat-coyote.jar > tomcat-http.jar > tomcat-util.jar > These are included in the jbossweb-tomcat55.sar directory, but are not on the classpath when the UnifiedInvoker is used (which uses remoting). So if use the http transport within remoting when using UnifiedInvoker, get errors since the needed classes are not found. > BTW, does not matter if 'UseJBossWebLoader' is true or false within jbossweb-tomcat55.jar/META-INF/jboss-service.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1984) HttpNamingContextFactory unable to reconnect

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ] Dimitris Andreadis updated JBAS-1984: ------------------------------------- Component/s: (was: Remoting) Fix Version/s: JBossAS-5.0.1.CR1 > HttpNamingContextFactory unable to reconnect > -------------------------------------------- > > Key: JBAS-1984 > URL: https://jira.jboss.org/jira/browse/JBAS-1984 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming > Affects Versions: JBossAS-3.2.7 Final > Environment: XP > Reporter: Bernd Eckenfels > Assignee: Emanuel Muckenhuber > Fix For: JBossAS-5.0.1.CR1 > > > Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this: > ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568) > at net.eckenfels.JNDITest.main(JNDITest.java:72) > Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250) > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348) > ... 3 more > Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224) > ... 4 more > Caused by: java.net.UnknownHostException: http: http > at java.net.InetAddress.getAllByName0(InetAddress.java:1128) > at java.net.InetAddress.getAllByName0(InetAddress.java:1098) > at java.net.InetAddress.getAllByName(InetAddress.java:1061) > at java.net.InetAddress.getByName(InetAddress.java:958) > at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61) > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220) > ... 4 more > Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct: > p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory"); > p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory"); > p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); > p.put("jnp.disableDiscovery", "true"); > Context rootCtx = (Context)new InitialContext(p); > while(true) > { > try > { > // rootCtx = new InitialContext(p); > Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi"); > l = jmxCtx.list(""); > while(l.hasMore()) > { > System.out.println(" - " + l.next()); > } > } catch (Throwable t) { > System.out.println("ex: " + t); t.printStackTrace(System.out); > } > try{Thread.sleep(10000);}catch(Throwable t) { } > } > This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling. > The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBAS-1984) HttpNamingContextFactory unable to reconnect

by Dimitris Andreadis (JIRA)

[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ] Dimitris Andreadis reassigned JBAS-1984: ---------------------------------------- Assignee: Emanuel Muckenhuber (was: Tom Elrod) Emanuel, this is an old issue. Do you want to check if it still current and get a stub at it? (after AS5) > HttpNamingContextFactory unable to reconnect > -------------------------------------------- > > Key: JBAS-1984 > URL: https://jira.jboss.org/jira/browse/JBAS-1984 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Naming, Remoting > Affects Versions: JBossAS-3.2.7 Final > Environment: XP > Reporter: Bernd Eckenfels > Assignee: Emanuel Muckenhuber > > Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this: > ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]] > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575) > at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568) > at net.eckenfels.JNDITest.main(JNDITest.java:72) > Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250) > at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348) > ... 3 more > Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http] > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224) > ... 4 more > Caused by: java.net.UnknownHostException: http: http > at java.net.InetAddress.getAllByName0(InetAddress.java:1128) > at java.net.InetAddress.getAllByName0(InetAddress.java:1098) > at java.net.InetAddress.getAllByName(InetAddress.java:1061) > at java.net.InetAddress.getByName(InetAddress.java:958) > at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61) > at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220) > ... 4 more > Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct: > p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory"); > p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory"); > p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); > p.put("jnp.disableDiscovery", "true"); > Context rootCtx = (Context)new InitialContext(p); > while(true) > { > try > { > // rootCtx = new InitialContext(p); > Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi"); > l = jmxCtx.list(""); > while(l.hasMore()) > { > System.out.println(" - " + l.next()); > } > } catch (Throwable t) { > System.out.println("ex: " + t); t.printStackTrace(System.out); > } > try{Thread.sleep(10000);}catch(Throwable t) { } > } > This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling. > The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1483) Set JACC Policy Context ID in EJBContextImpl for callbacks

by Anil Saldhana (JIRA)

Set JACC Policy Context ID in EJBContextImpl for callbacks ---------------------------------------------------------- Key: EJBTHREE-1483 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1483 Project: EJB 3.0 Issue Type: Feature Request Components: Security Reporter: Anil Saldhana Assignee: Anil Saldhana We have the Policy Context ID being set in RoleBasedAuthorizationInterceptor but the callbacks do not go through this. One place for call backs in the EJBContextImpl.isCallerInRole. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBWEB-118) Add HTTP Connector socketBuffer Attribute

by Mike Millson (JIRA)

Add HTTP Connector socketBuffer Attribute ----------------------------------------- Key: JBWEB-118 URL: https://jira.jboss.org/jira/browse/JBWEB-118 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Reporter: Mike Millson Assignee: Mike Millson Add socketBuffer attribute to HTTP connector to allow specifying custom buffer sizes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-821) Starting VERIFY_SUSPECT timer thread causes java.lang.IllegalThreadStateException

by Vladimir Blagojevic (JIRA)

Starting VERIFY_SUSPECT timer thread causes java.lang.IllegalThreadStateException --------------------------------------------------------------------------------- Key: JGRP-821 URL: https://jira.jboss.org/jira/browse/JGRP-821 Project: JGroups Issue Type: Bug Affects Versions: 2.6.3, 2.7 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 2.6.4, 2.7 I believe this is related to concurrent message processing of multiple suspect messages. Timer needs to be started while holding a lock - we properly publish thread references as well. java.lang.IllegalThreadStateException at java.lang.Thread.start(Unknown Source) at org.jgroups.protocols.VERIFY_SUSPECT.startTimer(VERIFY_SUSPECT.java:293) at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:240) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:122) at org.jgroups.protocols.FD.up(FD.java:269) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:309) at org.jgroups.protocols.MERGE2.up(MERGE2.java:144) at org.jgroups.protocols.Discovery.up(Discovery.java:244) at org.jgroups.protocols.TP.passMessageUp(TP.java:1266) at org.jgroups.protocols.TP.access$100(TP.java:49) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1809) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1788) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Commented: (JBPORTAL-2102) cms admin ui testing

by Viliam Rockai (JIRA)

[ https://jira.jboss.org/jira/browse/JBPORTAL-2102?page=com.atlassian.jira.... ] Viliam Rockai commented on JBPORTAL-2102: ----------------------------------------- saving a file (exporting of folder withing cms admin) is quite a problem with actual version of selenium. there exists a workaround for firefox, but it seems there is no way for other browsers to test it. anyway i will look deeper on that firefox workaround and try to implement it. > cms admin ui testing > -------------------- > > Key: JBPORTAL-2102 > URL: https://jira.jboss.org/jira/browse/JBPORTAL-2102 > Project: JBoss Portal > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Prabhat Jha > Assignee: Viliam Rockai > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5906) Client user transaction lookups aren't closing initial contexts

by Adrian Brock (JIRA)

Client user transaction lookups aren't closing initial contexts --------------------------------------------------------------- Key: JBAS-5906 URL: https://jira.jboss.org/jira/browse/JBAS-5906 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Transaction Manager (JBossTM) Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1 Reporter: Adrian Brock Assignee: Galder Zamarreno Fix For: JBossAS-5.0.0.CR2, JBossAS-4.2.4.GA There are a number of places in the UserTransaction initialisation and TxPropogationContextUtil that are doing jndi lookups() without closing the initial context. Typically new InitialContext().lookup(...); This is inefficient since on the client side this will mean an rmi connection is open until it gets garbage collected. This has already been fixed in JBoss5 for the TxPropogationContextUtil (correct code should look like this) try { InitialContext ctx = new InitialContext(); try { tpcFactory = (TransactionPropagationContextFactory) ctx.lookup(EXPORTER_JNDI_NAME); } finally { ctx.close(); } } catch (NamingException e) { throw new RuntimeException("Unable to lookup " + EXPORTER_JNDI_NAME, e); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBPORTAL-2103) wsrp admin ui testing

by Prabhat Jha (JIRA)

[ https://jira.jboss.org/jira/browse/JBPORTAL-2103?page=com.atlassian.jira.... ] Prabhat Jha commented on JBPORTAL-2103: --------------------------------------- The second step will be to create an instance of portlet that you get as a bea consumer and add that to a portal. > wsrp admin ui testing > --------------------- > > Key: JBPORTAL-2103 > URL: https://jira.jboss.org/jira/browse/JBPORTAL-2103 > Project: JBoss Portal > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Prabhat Jha > Assignee: Viliam Rockai > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2008