September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (JBANN-7) Generate a HTML report of annotations

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBANN-7?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBANN-7. --------------------------------- Resolution: Done XML not included > Generate a HTML report of annotations > ------------------------------------- > > Key: JBANN-7 > URL: https://jira.jboss.org/jira/browse/JBANN-7 > Project: Papaki > Issue Type: Task > Components: Tool - Indexer > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.0.Beta1 > > > Generate a HTML report of the annotations found inside the file -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-1107) SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation

by Ron Sigal (JIRA)

SocketServerInvoker.IdleTimeoutTask interrupts ServerThreads during long invocation ----------------------------------------------------------------------------------- Key: JBREM-1107 URL: https://jira.jboss.org/jira/browse/JBREM-1107 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) org.jboss.remoting.transport.socket.SocketServerInvoker.IdleTimerTask is intended to shut down org.jboss.remoting.transport.socket.ServerThreads that haven't been in use for some configured amount of time. For each ServerThread, it compares the value of System.currentTimeMillis() to the time at which the ServerThread last started or finished processing an invocation, and, if the difference exceeds the value of the "idleTimeout" parameter, it shuts down the ServerThread. The problem is that if processing an invocation takes longer than the value of "idleTimeout", a ServerThread could be shut down DURING the processing of an invocation. -- 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

14 years, 8 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1146) Treat IOException("Connection reset by peer") as a retriable exception

by Ron Sigal (JIRA)

Treat IOException("Connection reset by peer") as a retriable exception ---------------------------------------------------------------------- Key: JBREM-1146 URL: https://jira.jboss.org/jira/browse/JBREM-1146 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 org.jboss.remoting.transport.socket.MicroSocketClientInvoker uses the parameter "numberOfCallRetries" to determine the number of invocation attempts to make upon receiving java.net.SocketExceptions. For example, SocketException("Connection reset") will cause MicroSocketClientInvoker to get another socket and try again. However, if a connection is reset on the other side, then an IOException("Connection reset by peer") is thrown, which doesn't lead to a retry. It should be possible to configure the socket transport to treat an IOException("Connection reset by peer") as retriable. -- 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

14 years, 8 months

2
4
0 / 0

[JBoss JIRA] Resolved: (JBANN-8) Support exclusion of annotations

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBANN-8?page=com.atlassian.jira.plugin... ] Jesper Pedersen resolved JBANN-8. --------------------------------- Resolution: Done > Support exclusion of annotations > -------------------------------- > > Key: JBANN-8 > URL: https://jira.jboss.org/jira/browse/JBANN-8 > Project: Papaki > Issue Type: Task > Components: Tool - Indexer > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.0.Beta1 > > > Allow the user to specify which annotations should be excluded from in annotation parsing phase. > F.ex. java.lang.Deprecated. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-7230) Deployment Problem

by Satyaranjan Panda (JIRA)

Deployment Problem ------------------ Key: JBAS-7230 URL: https://jira.jboss.org/jira/browse/JBAS-7230 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-5.1.0.GA Environment: Java 6, Jboss5.1.0.GA EJB 2.x Reporter: Satyaranjan Panda Assignee: Alexey Loubyansky Priority: Critical I am getting error when I am going to deploy my ear file. Below is the error. Failed to create Resource Puma.ear - cause: java.lang.RuntimeException:org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** DEPLOYMENTS IN ERROR: Name -> Error vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/ -> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/PumaEJBComp/ DEPLOYMENTS IN ERROR: Deployment "vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 87:3 The markup in the document preceding the root element must be well-formed. -> org.jboss.deployers.client.spi.IncompleteDeploymentException:Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** DEPLOYMENTS IN ERROR: Name -> Error vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/ -> org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/PumaEJBComp/ DEPLOYMENTS IN ERROR: Deployment "vfsfile:/D:/jboss-5.1.0.GA/server/default/deploy/Puma.ear/" is in error due to the following reason(s): org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 87:3 The markup in the document preceding the root element must be well-formed. -- 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

14 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1720) JMSUserManager has insert data into JBM_ROLE and JBM_USER every time when it starts.

by ryu ken (JIRA)

JMSUserManager has insert data into JBM_ROLE and JBM_USER every time when it starts. ------------------------------------------------------------------------------------ Key: JBMESSAGING-1720 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1720 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Persistence Affects Versions: 1.4.0.SP3.CP08 Reporter: ryu ken Priority: Minor "CreateTablesOnStartup" attribute value of JMSUserManager has been set to "false". >From the second start of JBossMessaging, Even data of jbm user and role is already exist in JBM_ROLE and JBM_USER tables, JMSUserManager still try to insert data into the tables and cause the data already exist a SQLException. -- 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

14 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBANN-29) Rebrand project as Papaki

by Jesper Pedersen (JIRA)

Rebrand project as Papaki ------------------------- Key: JBANN-29 URL: https://jira.jboss.org/jira/browse/JBANN-29 Project: Papaki Issue Type: Task Components: Build, Core, Documentation, Tool - Indexer, Tool - Validator Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Blocker Fix For: 1.0.0.Beta1 -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBID-137) JBoss STS - improve the configuration to allow for general properties to be specified for each token provider

by Stefan Guilhen (JIRA)

JBoss STS - improve the configuration to allow for general properties to be specified for each token provider ------------------------------------------------------------------------------------------------------------- Key: JBID-137 URL: https://jira.jboss.org/jira/browse/JBID-137 Project: JBoss Identity Issue Type: Task Components: Identity-Federation Affects Versions: IDFED-1.0.0.alpha3 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: IDFED-1.0.0.alpha4 JBoss STS does not currently provide a way to specify general properties for a token provider. A token provider may be configurable (for example, a provider may take an URL of a third-party service or repository) and the configuration schema must be changed to allow the specification of properties. The token providers should also be associated with the token element (namespace and local name) besides the token type. The reason for doing this is that validation/renewing/cancellation requests do not specify the token type explicitly so it must be inferred by the token element. The only way for the STS to figure out which provider should be used to validate the token is by having an association between token elements and providers. Something like: <TokenProvider ProviderClass="...." TokenType="..." TokenNamespace="urn:...." TokenName="Assertion"> <Property name="..." value="..."/> <Property name="..." vluae="..."/> </TokenProvider> A final note about configuration is about the need for the TruststoreAlias attribute of the ServiceProvider. The alias of each service provider can be configured through the ValidatingAlias element of KeyProvider, so we may just make the TruststoreAlias attribute optional. -- 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

14 years, 8 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBREM-324) Facility for real-time decision on best InvokerLocator by which to contact a given handler.

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-324?page=com.atlassian.jira.plug... ] Ron Sigal updated JBREM-324: ---------------------------- Assignee: Ron Sigal (was: Ron Sigal) > Facility for real-time decision on best InvokerLocator by which to contact a given handler. > ------------------------------------------------------------------------------------------- > > Key: JBREM-324 > URL: https://jira.jboss.org/jira/browse/JBREM-324 > Project: JBoss Remoting > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assignee: Ron Sigal > Priority: Minor > > The basic idea is to be able to communicate with a single handler by way of different InvokerLocators. For example, if you're working over the internet, compression might be advantageous, but if you're local it might not be. So you could have two Connectors sharing a handler, one using the compression marshaller and one not. > How about a client that > 1. gets the InvokerLocators for all of the Connectors for a certain handler, via a detector, > 2. sends some sample invocations to each and times them, and > 3. displays the results. > It could be used for real time decision making or to collect information for a set of rules. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBANN-13) Add configuration to the AnnotationScanner

by Jesper Pedersen (JIRA)

[ https://jira.jboss.org/jira/browse/JBANN-13?page=com.atlassian.jira.plugi... ] Jesper Pedersen updated JBANN-13: --------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha3) > Add configuration to the AnnotationScanner > ------------------------------------------ > > Key: JBANN-13 > URL: https://jira.jboss.org/jira/browse/JBANN-13 > Project: JBoss Annotations > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.0.Beta1 > > > Allow the AnnotationScanner to be configured - switches could be > * Class level > * Constructor level > * Method level > * Field level > * Parameter level > * Throw exception on error -- 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

14 years, 8 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 2009