[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1522) HttpNamingContextFactory fails due to system property read when under a security manager

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1522?page=history ]
 
Scott M Stark closed JBAS-1522:
---

Resolution: Done

The org.jboss.security.httpInvoker.sslSocketFactoryBuilder system property is 
read in a PrivilegedAction, and failure simply results in the default https 
SSLSocketFactory being used.

 HttpNamingContextFactory fails due to system property read when under a 
 security manager
 

  Key: JBAS-1522
  URL: http://jira.jboss.com/jira/browse/JBAS-1522
  Project: JBoss Application Server
 Type: Bug
   Components: Naming
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha,  JBossAS-3.2.8 Final



 Running under a security manager with the 
 org.jboss.naming.HttpNamingContextFactory can result in the following failure 
 due to the property access not being in a privileged block. The failure 
 should also be ignored since its an optional override setting.
 java.lang.ExceptionInInitializerError
 at 
 org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:106)
 at 
 org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:65)
 at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
 at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
 at javax.naming.InitialContext.init(InitialContext.java:219)
 at javax.naming.InitialContext.(InitialContext.java:195)
 at com.nineci.applet.HelloBeanApplet.start(HelloBeanApplet.java:31)
 at sun.applet.AppletPanel.run(AppletPanel.java:377)
 at java.lang.Thread.run(Thread.java:534)
 Caused by: java.security.AccessControlException: access denied 
 (java.util.PropertyPermission 
 org.jboss.security.httpInvoker.sslSocketFactoryBuilder read)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1276)
 at java.lang.System.getProperty(System.java:573)
 at org.jboss.invocation.http.interfaces.Util.(Util.java:76)
 ... 9 more

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1558) HAJNDI should use a thread pool

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1558?page=history ]

Scott M Stark reassigned JBAS-1558:
---

Assign To: Scott M Stark

 HAJNDI should use a thread pool
 ---

  Key: JBAS-1558
  URL: http://jira.jboss.com/jira/browse/JBAS-1558
  Project: JBoss Application Server
 Type: Feature Request
   Components: Clustering
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Adrian Brock
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1



 The DetachedHANamingService should use a ThreadPool like plain JNDI
 when it is serving the bootstrap stub to clients.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1558) HAJNDI should use a thread pool

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1558?page=history ]
 
Scott M Stark closed JBAS-1558:
---

 Resolution: Done
Fix Version: JBossAS-5.0 Alpha

The DetachedHANamingService now uses a thread pool set via the LookupPool 
attribute the same as the NamingService. By default this is mapped to the 
jboss.system:service=ThreadPool in the cluster-service.xml. If this attribute 
is not set an independent BasicThreadPool(HANamingBootstrap Pool) instance is 
created.

 HAJNDI should use a thread pool
 ---

  Key: JBAS-1558
  URL: http://jira.jboss.com/jira/browse/JBAS-1558
  Project: JBoss Application Server
 Type: Feature Request
   Components: Clustering
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Adrian Brock
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha



 The DetachedHANamingService should use a ThreadPool like plain JNDI
 when it is serving the bootstrap stub to clients.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1544) Wrong MBean attribute name in jboss:service=Mail (POP3SererHost )

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1544?page=history ]
 
Scott M Stark closed JBAS-1544:
---

Resolution: Done

MailServiceMBean.java is generated from MailService.java in 4.0 and has been 
corrected in head.

 Wrong MBean attribute name in jboss:service=Mail (POP3SererHost )
 -

  Key: JBAS-1544
  URL: http://jira.jboss.com/jira/browse/JBAS-1544
  Project: JBoss Application Server
 Type: Bug
   Components: JMX
 Versions:  JBossAS-4.0.1 SP1
 Reporter: Goran Ehrsson
 Priority: Minor
  Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1



 While browsing the Management Console on my newly installed jboss-4.0.1sp1 I 
 found a misspelled MBean attribute in the Mail service. POP3SererHost should 
 be POP3ServerHost I assume.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1258) Remove jbossha-httpsession.sar

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1258?page=history ]

Scott M Stark reassigned JBAS-1258:
---

Assign To: Scott M Stark  (was: Ben Wang)

 Remove jbossha-httpsession.sar
 --

  Key: JBAS-1258
  URL: http://jira.jboss.com/jira/browse/JBAS-1258
  Project: JBoss Application Server
 Type: Task
   Components: Clustering
 Versions: JBossAS-4.0.1 Final
 Reporter: Ben Wang
 Assignee: Scott M Stark
 Priority: Optional
  Fix For:  JBossAS-4.0.2RC1


 Original Estimate: 1 hour
 Remaining: 1 hour

 jbossha-httpsession.sar under server/all/deploy is redundant since we have 
 used JBossCache now. canbe safely removed.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1258) Remove jbossha-httpsession.sar

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1258?page=history ]
 
Scott M Stark closed JBAS-1258:
---

 Resolution: Done
Fix Version: JBossAS-5.0 Alpha

 Remove jbossha-httpsession.sar
 --

  Key: JBAS-1258
  URL: http://jira.jboss.com/jira/browse/JBAS-1258
  Project: JBoss Application Server
 Type: Task
   Components: Clustering
 Versions: JBossAS-4.0.1 Final
 Reporter: Ben Wang
 Assignee: Scott M Stark
 Priority: Optional
  Fix For: JBossAS-5.0 Alpha,  JBossAS-4.0.2RC1


 Original Estimate: 1 hour
 Remaining: 1 hour

 jbossha-httpsession.sar under server/all/deploy is redundant since we have 
 used JBossCache now. canbe safely removed.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1526) Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the permissions of the replaced delegate

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1526?page=history ]
 
Scott M Stark closed JBAS-1526:
---

 Resolution: Done
Fix Version: (was: JBossPOJOServer-1.0 Alpha)

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 

  Key: JBAS-1526
  URL: http://jira.jboss.com/jira/browse/JBAS-1526
  Project: JBoss Application Server
 Type: Bug
   Components: Security
 Versions:  JBossAS-4.0.1 SP1
  Environment: -
 Reporter: Roland R?z
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha


 Original Estimate: 1 hour
 Remaining: 1 hour

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 According to the JACC specification all Permissions of a CodeSource or 
 ProtectionDomain should be returned. Currently these methods return only the 
 JACC Permissions, without the Permissions of the delegate class.
 The JACC Specification states (http://java.sun.com/j2ee/javaacc/):
 2.5 What a Provider Must Do
 paragraph 3
 A replacement Policy object must assume responsibility for performing all 
 policy decisions within the JRE in which it is installed that are requested 
 by way of the Policy interface that it implements.
 Example Implementation of DelegatingPolicy.getPermissions(x):
   public PermissionCollection getPermissions(ProtectionDomain domain) {
   PermissionCollection pc = super.getPermissions(domain);
   PermissionCollection delegated = 
 delegate.getPermissions(domain);
   for (Enumeration e = delegated.elements(); 
 e.hasMoreElements();) {
   Permission p = (Permission) e.nextElement();
   pc.add(p);
   }
   return pc;
   }
 Regards,
 Andrea

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1571) Logging of cluster rpc method exceptions at warn level is incorrect

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1571?page=history ]

Scott M Stark updated JBAS-1571:


JBoss Forum Reference: 
http://www.jboss.org/index.html?module=bbop=viewtopict=61348

 Logging of cluster rpc method exceptions at warn level is incorrect
 ---

  Key: JBAS-1571
  URL: http://jira.jboss.com/jira/browse/JBAS-1571
  Project: JBoss Application Server
 Type: Bug
   Components: Clustering
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Beta,  JBossAS-3.2.8 Final


 Original Estimate: 1 hour
 Remaining: 1 hour

 The HAPartitionImpl handler for cluster rpc method invocations logs 
 Exceptions and Errors thrown from the reflected method invocation at warn 
 level. This results in spurious warnings when the underlying invocation 
 throws an exception as part of its normal operation. An example of where this 
 occurs is when an ha-sigleton binds a jndi entry into its node, and a client 
 does a lookup of the binding through ha-jndi. In a 3 node cluster A, B, C 
 with the ha-singleton on A, a ha-jndi request going to B will produce the 
 following NameNotFoundException on C:
 06:52:07,359 WARN  [DefaultPartition] javax.naming.NameNotFoundException: 
 TheSingleton not bound
 These exceptions should be logged at trace level.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1571) Logging of cluster rpc method exceptions at warn level is incorrect

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1571?page=history ]
 
Scott M Stark closed JBAS-1571:
---

Resolution: Done

The handler now simply returns any exception thrown during the rpc method call 
dispatch as this is the only way to propagate this back to the caller. Note 
that this can result in exceptions showing up as return values if the rpc 
method throws an exception. See the referenced forum postings for more details.

 Logging of cluster rpc method exceptions at warn level is incorrect
 ---

  Key: JBAS-1571
  URL: http://jira.jboss.com/jira/browse/JBAS-1571
  Project: JBoss Application Server
 Type: Bug
   Components: Clustering
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Beta,  JBossAS-3.2.8 Final


 Original Estimate: 1 hour
 Remaining: 1 hour

 The HAPartitionImpl handler for cluster rpc method invocations logs 
 Exceptions and Errors thrown from the reflected method invocation at warn 
 level. This results in spurious warnings when the underlying invocation 
 throws an exception as part of its normal operation. An example of where this 
 occurs is when an ha-sigleton binds a jndi entry into its node, and a client 
 does a lookup of the binding through ha-jndi. In a 3 node cluster A, B, C 
 with the ha-singleton on A, a ha-jndi request going to B will produce the 
 following NameNotFoundException on C:
 06:52:07,359 WARN  [DefaultPartition] javax.naming.NameNotFoundException: 
 TheSingleton not bound
 These exceptions should be logged at trace level.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1494) Need to expose the filter list for the default Filter implementation on URLDeploymentScanner

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1494?page=history ]
 
Scott M Stark closed JBAS-1494:
---

  Assign To: Scott M Stark
 Resolution: Done
Fix Version:  JBossAS-4.0.2RC1
 JBossAS-5.0 Alpha

A new FilterInstance attribute allows the prefixes, suffixes and matching 
strings for the ignored files:

  !-- The FilterInstance specifies a URLLister.URLFilter for scanned
   directories. This DeploymentFilter is initialized with the given
   prefixes, suffixes and matches that define which URLs should be
   ignored.
  --
  attribute name=FilterInstance
 attributeClass=org.jboss.deployment.scanner.DeploymentFilter
 serialDataType=javaBean
 !-- Files starting with theses strings are ignored --
 property name=prefixes#,%,\,,.,_$/property
 !-- Files ending with theses strings are ignored --
 property 
name=suffixes#,$,%,.BAK,.old,.orig,.rej,.bak,.sh,\,v,~/property
 !-- Files matching with theses strings are ignored --
 property 
name=matches.make.state,.nse_depinfo,CVS,CVS.admin,RCS,RCSLOG,SCCS,TAGS,core,tags/property
  /attribute


 Need to expose the filter list for the default Filter implementation on 
 URLDeploymentScanner
 

  Key: JBAS-1494
  URL: http://jira.jboss.com/jira/browse/JBAS-1494
  Project: JBoss Application Server
 Type: Feature Request
   Components: MicroContainer bus
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha



 Adding new patterns of files that the URLDeploymentScanner should ignore 
 currently requires a custom class implementation. The default Filter 
 attribute:
 !-- The Filter specifies a java.io.FileFilter for scanned
 directories.  Any file not accepted by this filter will not be
 deployed.  The org.jboss.deployment.scanner.DeploymentFilter
 rejects the following patterns:
 #*, %*, ,*, .*, _$*, *#, *$, *%, *.BAK,
 *.old, *.orig, *.rej, *.bak, *,v, *~, .make.state,
 .nse_depinfo, CVS, CVS.admin, RCS, RCSLOG, SCCS,
 TAGS, core, tags
 --
 attribute 
 name=Filterorg.jboss.deployment.scanner.DeploymentFilter/attribute
 cannot have prefixes and suffixes added without creating a custom filter 
 implementation. There should be basic support for configuring the 
 DeploymentFilter using either the javaBean support:
mbean code=org.jboss.test.jmx.complexattrs.ComplexAttrTests
   name=test:name=ComplexAttrTests,case=#1
   attribute name=Bean2
  attributeClass=org.jboss.test.jmx.complexattrs.JavaBean2
  serialDataType=javaBean
  property name=i12345678/property
  property name=f1.23456/property
  property name=d3.14159265358979323846/property
  property name=l1234567890/property
   /attribute
/mbean
 or, the under development jbossxb mechanism:
 !-- Tell JBossXB about the namespace to factory mappings in this doc --
 ?jbossxb ns=urn:schema:ns1:jbossxb
factory=org.jboss.test.jmx.complexattrs.JavaBeanObjectModelFactory?
 ...
!-- Test the jbossxb attribute data type syntax --
mbean code=org.jboss.test.jmx.complexattrs.ComplexAttrTests
   name=test:name=ComplexAttrTests,case=#2
   attribute name=Bean1
  attributeClass=org.jboss.test.jmx.complexattrs.JavaBean1
  serialDataType=jbossxb
  xmlns:ns1=urn:schema:ns1:jbossxb
  ns1:javabean1
 property name=bindAddress127.0.0.1/property
 property name=someDateSun Jan  2 23:26:49 PST 2005/property
 property name=props
   prop1=value1
   prop2=value2
   prop3=${prop3.systemProperty}
 /property
 property name=namesname1,name2,name3/property
 property name=someURLhttp://www.jboss.org/property
  /ns1:javabean1
   /attribute
/mbean

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1508) JBoss AS needs JSF

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1508?page=history ]

Scott M Stark updated JBAS-1508:


Fix Version: (was: JBossAS-5.0 Beta)
 (was:  JBossAS-4.0.2RC1)
 (was: JBossPOJOServer-1.0 Alpha)
 (was: JBossPOJOServer-1.0 Final)

 JBoss AS needs JSF
 --

  Key: JBAS-1508
  URL: http://jira.jboss.com/jira/browse/JBAS-1508
  Project: JBoss Application Server
 Type: Feature Request
   Components: Web (Tomcat) service
 Versions:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossPOJOServer-1.0 
 Alpha, JBossAS-5.0 Alpha, JBossPOJOServer-1.0 Final, JBossAS-5.0 Beta, 
 JBossAS-5.0 Final,  JBossAS-3.2.8 Final
 Reporter: Stan Silvert
 Assignee: Stan Silvert
  Fix For: JBossAS-4.0.2 Final, JBossAS-5.0 Alpha, JBossAS-5.0 Final,  
 JBossAS-3.2.8 Final


 Original Estimate: 1 week
 Remaining: 1 week

 JSF support needs to be added to the JBoss AS distribution.  Initially, 
 MyFaces will be the implementation chosen.  This will probably also include 
 the JSF Car Demo as an example.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1559) Check all serverSocket accept threads

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1559?page=history ]

Scott M Stark reassigned JBAS-1559:
---

Assign To: Scott M Stark

 Check all serverSocket accept threads
 -

  Key: JBAS-1559
  URL: http://jira.jboss.com/jira/browse/JBAS-1559
  Project: JBoss Application Server
 Type: Task
 Reporter: Adrian Brock
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1



 Check all serverSocket accept threads to ensure there are not paths
 through the code that could cause the thread to die and the service
 stop listening.
 e.g. is java.lang.Throwable being caught, to trap java.lang.Errors?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1559) Check all serverSocket accept threads

2005-03-13 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1559?page=history ]

Scott M Stark updated JBAS-1559:


Fix Version: JBossAS-4.0.2 Final
 (was:  JBossAS-4.0.2RC1)

 Check all serverSocket accept threads
 -

  Key: JBAS-1559
  URL: http://jira.jboss.com/jira/browse/JBAS-1559
  Project: JBoss Application Server
 Type: Task
 Reporter: Adrian Brock
 Assignee: Scott M Stark
  Fix For: JBossAS-4.0.2 Final



 Check all serverSocket accept threads to ensure there are not paths
 through the code that could cause the thread to die and the service
 stop listening.
 e.g. is java.lang.Throwable being caught, to trap java.lang.Errors?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1574) SerializableResultSetMetaData.getColumnCount is off by one

2005-03-12 Thread Scott M Stark (JIRA)
SerializableResultSetMetaData.getColumnCount is off by one
--

 Key: JBAS-1574
 URL: http://jira.jboss.com/jira/browse/JBAS-1574
 Project: JBoss Application Server
Type: Bug
  Components: JCA service  
Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final
Reporter: Scott M Stark
 Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-5.0 Alpha


The SerializableResultSetMetaData wrapper ctor is creating a copy of the 
ResultSetMetaData column info into an array of getColumnCount+1 to allow for 
the base 1 index, but the getColumnCount method is returning the array length. 
This produces an off by one error.


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1574) SerializableResultSetMetaData.getColumnCount is off by one

2005-03-12 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1574?page=history ]

Scott M Stark reassigned JBAS-1574:
---

Assign To: Scott M Stark

 SerializableResultSetMetaData.getColumnCount is off by one
 --

  Key: JBAS-1574
  URL: http://jira.jboss.com/jira/browse/JBAS-1574
  Project: JBoss Application Server
 Type: Bug
   Components: JCA service
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-5.0 Alpha



 The SerializableResultSetMetaData wrapper ctor is creating a copy of the 
 ResultSetMetaData column info into an array of getColumnCount+1 to allow for 
 the base 1 index, but the getColumnCount method is returning the array 
 length. This produces an off by one error.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1574) SerializableResultSetMetaData.getColumnCount is off by one

2005-03-12 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1574?page=history ]
 
Scott M Stark closed JBAS-1574:
---

Resolution: Done

 SerializableResultSetMetaData.getColumnCount is off by one
 --

  Key: JBAS-1574
  URL: http://jira.jboss.com/jira/browse/JBAS-1574
  Project: JBoss Application Server
 Type: Bug
   Components: JCA service
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-5.0 Alpha



 The SerializableResultSetMetaData wrapper ctor is creating a copy of the 
 ResultSetMetaData column info into an array of getColumnCount+1 to allow for 
 the base 1 index, but the getColumnCount method is returning the array 
 length. This produces an off by one error.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1571) Logging of cluster rpc method exceptions at warn level is incorrect

2005-03-11 Thread Scott M Stark (JIRA)
Logging of cluster rpc method exceptions at warn level is incorrect
---

 Key: JBAS-1571
 URL: http://jira.jboss.com/jira/browse/JBAS-1571
 Project: JBoss Application Server
Type: Bug
  Components: Clustering  
Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final,  JBossAS-4.0.1 SP1
Reporter: Scott M Stark
 Assigned to: Scott M Stark 
 Fix For: JBossAS-5.0 Beta,  JBossAS-4.0.2RC1,  JBossAS-3.2.8 Final


The HAPartitionImpl handler for cluster rpc method invocations logs Exceptions 
and Errors thrown from the reflected method invocation at warn level. This 
results in spurious warnings when the underlying invocation throws an exception 
as part of its normal operation. An example of where this occurs is when an 
ha-sigleton binds a jndi entry into its node, and a client does a lookup of the 
binding through ha-jndi. In a 3 node cluster A, B, C with the ha-singleton on 
A, a ha-jndi request going to B will produce the following 
NameNotFoundException on C:

06:52:07,359 WARN  [DefaultPartition] javax.naming.NameNotFoundException: 
TheSingleton not bound

These exceptions should be logged at trace level.


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAOP-93) JBoss AOP jars in 4.0

2005-03-11 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAOP-93?page=history ]

Scott M Stark reassigned JBAOP-93:
--

Assign To: Scott M Stark  (was: Bill Burke)

 JBoss AOP jars in 4.0
 -

  Key: JBAOP-93
  URL: http://jira.jboss.com/jira/browse/JBAOP-93
  Project: JBoss AOP
 Type: Task
 Reporter: Adrian Brock
 Assignee: Scott M Stark
 Priority: Minor



 The jboss-aop and aspect library jars in Branch_4_0 should be in thirdparty
 and the source projects removed altogether from the JBossAS build.
 Although, we do want to use this approach in future, we don't have the 
 infrastructure
 in place for this change yet...
 e.g. How to control versions of dependent projects and thirdparty jars.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAOP-93) JBoss AOP jars in 4.0

2005-03-11 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAOP-93?page=comments#action_12316082 
]
 
Scott M Stark commented on JBAOP-93:


I'm creating thirdparty/jboss-xxx entries to remove the obsolete source modules 
and move to the binaries for the 4.0 branch. 

 JBoss AOP jars in 4.0
 -

  Key: JBAOP-93
  URL: http://jira.jboss.com/jira/browse/JBAOP-93
  Project: JBoss AOP
 Type: Task
 Reporter: Adrian Brock
 Assignee: Scott M Stark
 Priority: Minor



 The jboss-aop and aspect library jars in Branch_4_0 should be in thirdparty
 and the source projects removed altogether from the JBossAS build.
 Although, we do want to use this approach in future, we don't have the 
 infrastructure
 in place for this change yet...
 e.g. How to control versions of dependent projects and thirdparty jars.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1515) Update the AOP binaries and remove the aop modules

2005-03-11 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1515?page=history ]

Scott M Stark updated JBAS-1515:


Version:  JBossAS-4.0.1 SP1
 JBossAS-4.0.1 Final
 (was:  JBossAS-4.0.2RC1)
Fix Version:  JBossAS-4.0.2RC1
 (was: JBossAS-4.0.2 Final)

 Update the AOP binaries and remove the aop modules
 --

  Key: JBAS-1515
  URL: http://jira.jboss.com/jira/browse/JBAS-1515
  Project: JBoss Application Server
 Type: Task
   Components: Build System
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final
 Reporter: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1



 The aop deployer seems to no longer be built from the aspects module source. 
 The current 4.0 branch binaries do not include the recent security changes 
 and needs to be updated. If binaries are being used as the integration 
 mechanism, there is no reason to be including obsolete source modules.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1515) Update the AOP binaries and remove the aop modules

2005-03-11 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1515?page=history ]
 
Scott M Stark closed JBAS-1515:
---

 Assign To: Scott M Stark
Resolution: Done

The MailServiceMBean is generated from the MailService.java class so you need 
to do a clean build to synch the interface.

 Update the AOP binaries and remove the aop modules
 --

  Key: JBAS-1515
  URL: http://jira.jboss.com/jira/browse/JBAS-1515
  Project: JBoss Application Server
 Type: Task
   Components: Build System
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1



 The aop deployer seems to no longer be built from the aspects module source. 
 The current 4.0 branch binaries do not include the recent security changes 
 and needs to be updated. If binaries are being used as the integration 
 mechanism, there is no reason to be including obsolete source modules.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1562) Expose getEntityLockMonitor in the MBean EntityLockMonitorMBean

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1562?page=history ]

Scott M Stark moved JBJMX-84 to JBAS-1562:
--

   Project: JBoss Application Server  (was: JBoss JMX)
   Key: JBAS-1562  (was: JBJMX-84)
 Component: EJBs
JMX
   Version:  JBossAS-4.0.1 SP1
JBossAS-4.0.1 Final
 JBossAS-3.2.7 Final
JBossAS-3.2.6 Final
(was: JBossAS-4.0.0)
Security Level: Public

 Expose getEntityLockMonitor in the MBean EntityLockMonitorMBean
 ---

  Key: JBAS-1562
  URL: http://jira.jboss.com/jira/browse/JBAS-1562
  Project: JBoss Application Server
 Type: Feature Request
   Components: EJBs, JMX
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final, 
 JBossAS-3.2.6 Final
 Reporter: Yaron Zakai Or



 In order to perform proper monitoring of EJB locks, the current functionality 
 is not enough for the following reasons:
 1. The LockMonitor is saved per EJB name, where multiple EJBs can have the 
 same name. The solution should be to store it based on the jndi name.
 2. The only way to get per-EJB information is to use the printLockMonitor 
 method. This will create a non reasonable overhead for a real-life monitoring 
 solution. The solution here is to expose the method getEntityLockMonitor in 
 the MBean interface.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1563) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
Clustered stateful session bean removal of expired passivated instances causes 
deadlock
---

 Key: JBAS-1563
 URL: http://jira.jboss.com/jira/browse/JBAS-1563
 Project: JBoss Application Server
Type: Support Patch
  Components: Clustering, EJBs  
Versions: JBossAS-3.2.6 Final
Reporter: Scott M Stark
 Assigned to: Scott M Stark 


A patch against 3.2.6 is needed for the JBAS-1560 'Clustered stateful session 
bean removal of expired passivated instances causes deadlock' issue fix which 
is incorporated into 3.2.8, 4.0.2.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1563) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1563?page=history ]

Scott M Stark updated JBAS-1563:


CVS Branch: JBoss_3_2_6_JBAS-1563

 Clustered stateful session bean removal of expired passivated instances 
 causes deadlock
 ---

  Key: JBAS-1563
  URL: http://jira.jboss.com/jira/browse/JBAS-1563
  Project: JBoss Application Server
 Type: Support Patch
   Components: Clustering, EJBs
 Versions: JBossAS-3.2.6 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark


 Original Estimate: 2 days
 Remaining: 2 days

 A patch against 3.2.6 is needed for the JBAS-1560 'Clustered stateful session 
 bean removal of expired passivated instances causes deadlock' issue fix which 
 is incorporated into 3.2.8, 4.0.2.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBPORTAL-211) Support for Standard Content Storage API?

2005-03-10 Thread Scott M Stark (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBPORTAL-211?page=comments#action_12316052 ]
 
Scott M Stark commented on JBPORTAL-211:


Here is a link about IBM's efforts in this area someone forwarded to me.

http://www.nwfusion.com/news/2005/013105datastore.html?page=1

 Support for Standard Content Storage API?
 -

  Key: JBPORTAL-211
  URL: http://jira.jboss.com/jira/browse/JBPORTAL-211
  Project: JBoss Portal
 Type: Feature Request
 Reporter: SourceForge User



 SourceForge Submitter: elfring .
 Would you like to support content storage independence?
 Content Repository
 http://jcp.org/en/jsr/detail?id=170

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-363) FileURLConnection needs URL decode for JDK 1.4

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-363?page=history ]

Scott M Stark updated JBAS-363:
---

Description: 
SourceForge Submitter: andieveritt .
In the constructor of
org.jboss.net.protocol.file.FileURLConnection a new
File is created from the supplied URL. In JDK 1.4 the
result of URL.getPath() is URL encoded which means on
windows with a path with a space you get
'C:\Program%20Files\foo\bar' - which doesn't work.
I have tested a modified version of FileURLConnection
which URL decodes the result. This resolves the issue.
I have attached the modified version. The only change
is on Line 45:
-   file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
+  file = new
File(java.net.URLDecoder.decode(url.getPath()).replace('/',
File.separatorChar).replace('|', ':'));

  was:
SourceForge Submitter: andieveritt .
In the constructor of
org.jboss.net.protocol.file.FileURLConnection a new
File is created from the supplied URL. In JDK 1.4 the
result of URL.getPath() is URL encoded which means on
windows with a path with a space you get
'C:\Program%20Files\foo\bar' - which doesn't work.
I have tested a modified version of FileURLConnection
which URL decodes the result. This resolves the issue.
I have attached the modified version. The only change
is on Line 45:
-   file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
+  file = new
File(java.net.URLDecoder.decode(url.getPath()).replace('/',
File.separatorChar).replace('|', ':'));

Environment: 
Fix Version:  JBossAS-4.0.2RC1

 FileURLConnection needs URL decode for JDK 1.4
 --

  Key: JBAS-363
  URL: http://jira.jboss.com/jira/browse/JBAS-363
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For:  JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1



 SourceForge Submitter: andieveritt .
 In the constructor of
 org.jboss.net.protocol.file.FileURLConnection a new
 File is created from the supplied URL. In JDK 1.4 the
 result of URL.getPath() is URL encoded which means on
 windows with a path with a space you get
 'C:\Program%20Files\foo\bar' - which doesn't work.
 I have tested a modified version of FileURLConnection
 which URL decodes the result. This resolves the issue.
 I have attached the modified version. The only change
 is on Line 45:
 -   file = new File(url.getPath().replace('/',
 File.separatorChar).replace('|', ':'));
 +  file = new
 File(java.net.URLDecoder.decode(url.getPath()).replace('/',
 File.separatorChar).replace('|', ':'));

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1563) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1563?page=history ]

Scott M Stark updated JBAS-1563:


Attachment: LRUStatefulContextCachePolicy.java

 Clustered stateful session bean removal of expired passivated instances 
 causes deadlock
 ---

  Key: JBAS-1563
  URL: http://jira.jboss.com/jira/browse/JBAS-1563
  Project: JBoss Application Server
 Type: Support Patch
   Components: Clustering, EJBs
 Versions: JBossAS-3.2.6 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Attachments: LRUStatefulContextCachePolicy.java, 
 StatefulSessionInstanceCache.java

 Original Estimate: 2 days
 Remaining: 2 days

 A patch against 3.2.6 is needed for the JBAS-1560 'Clustered stateful session 
 bean removal of expired passivated instances causes deadlock' issue fix which 
 is incorporated into 3.2.8, 4.0.2.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1563) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1563?page=history ]

Scott M Stark updated JBAS-1563:


Attachment: StatefulSessionInstanceCache.java

 Clustered stateful session bean removal of expired passivated instances 
 causes deadlock
 ---

  Key: JBAS-1563
  URL: http://jira.jboss.com/jira/browse/JBAS-1563
  Project: JBoss Application Server
 Type: Support Patch
   Components: Clustering, EJBs
 Versions: JBossAS-3.2.6 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Attachments: LRUStatefulContextCachePolicy.java, 
 StatefulSessionInstanceCache.java

 Original Estimate: 2 days
 Remaining: 2 days

 A patch against 3.2.6 is needed for the JBAS-1560 'Clustered stateful session 
 bean removal of expired passivated instances causes deadlock' issue fix which 
 is incorporated into 3.2.8, 4.0.2.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1563) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1563?page=history ]

Scott M Stark updated JBAS-1563:


Attachment: jboss.jar

 Clustered stateful session bean removal of expired passivated instances 
 causes deadlock
 ---

  Key: JBAS-1563
  URL: http://jira.jboss.com/jira/browse/JBAS-1563
  Project: JBoss Application Server
 Type: Support Patch
   Components: Clustering, EJBs
 Versions: JBossAS-3.2.6 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Attachments: LRUStatefulContextCachePolicy.java, 
 StatefulSessionInstanceCache.java, jboss.jar

 Original Estimate: 2 days
 Remaining: 2 days

 A patch against 3.2.6 is needed for the JBAS-1560 'Clustered stateful session 
 bean removal of expired passivated instances causes deadlock' issue fix which 
 is incorporated into 3.2.8, 4.0.2.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1560) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-10 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1560?page=history ]
 
Scott M Stark closed JBAS-1560:
---

Resolution: Done

 Clustered stateful session bean removal of expired passivated instances 
 causes deadlock
 ---

  Key: JBAS-1560
  URL: http://jira.jboss.com/jira/browse/JBAS-1560
  Project: JBoss Application Server
 Type: Bug
   Components: EJBs
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
 Priority: Critical
  Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-5.0 Alpha,  
 JBossAS-3.2.8 Final


 Original Estimate: 2 days
 Remaining: 2 days

 The background processing of expired stateful sessions that have been 
 passivated  can result in deadlock when clustering is used due to the fact 
 that removal of the stateful session occurs with the cache lock held. This 
 conflicts with removal requests sent to invalidate a cache entry. The 
 deadlock is illustrated by the following 3.2.6 traces:
 Thread-25 daemon prio=1 tid=0x89648448 nid=0x3805 in Object.wait() 
 [8aaed000..8aaed87c]
 at java.lang.Object.wait(Native Method)
 at org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:505)
 at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:183)
 - locked 0x9b8ea9e8 (a java.lang.Object)
 at 
 org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:384)
 at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:134)
 at 
 org.jboss.ha.framework.server.HAPartitionImpl.callMethodOnCluster(HAPartitionImpl.java:620)
 at 
 org.jboss.ha.hasessionstate.server.HASessionStateImpl.removeSession(HASessionStateImpl.java:533)
 at 
 org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.removePassivated(StatefulHASessionPersistenceManager.java:219)
 at 
 org.jboss.ejb.plugins.StatefulSessionInstanceCache.removePassivated(StatefulSessionInstanceCache.java:193)
 at 
 org.jboss.ejb.plugins.LRUStatefulContextCachePolicy$RemoverTask.run(LRUStatefulContextCachePolicy.java:146)
 - locked 0x9296b8c0 (a java.lang.Object)
 at java.util.TimerThread.mainLoop(Timer.java:432)
 at java.util.TimerThread.run(Timer.java:382)
 MessageDispatcher up processing thread daemon prio=1 tid=0x086c06b0 
 nid=0x3805 waiting for monitor entry [8b788000..8b78887c]
 at 
 org.jboss.ejb.plugins.AbstractInstanceCache.remove(AbstractInstanceCache.java:206)
 - waiting to lock 0x9296b8c0 (a java.lang.Object)
 at 
 org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.sessionExternallyModified(StatefulHASessionPersistenceManager.java:231)
 at 
 org.jboss.ha.hasessionstate.server.HASessionStateImpl.ownedObjectExternallyModified(HASessionStateImpl.java:587)
 at 
 org.jboss.ha.hasessionstate.server.HASessionStateImpl._setOwnership(HASessionStateImpl.java:504)
 at sun.reflect.GeneratedMethodAccessor400.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
 at 
 org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:828)
 at 
 org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
 at 
 org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
 at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
 at 
 org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
 at 
 org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
 at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
 at java.lang.Thread.run(Thread.java:534)
 The background removal of the expired passivated sessions should not be done 
 with the cache lock held.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1560) Clustered stateful session bean removal of expired passivated instances causes deadlock

2005-03-09 Thread Scott M Stark (JIRA)
Clustered stateful session bean removal of expired passivated instances causes 
deadlock
---

 Key: JBAS-1560
 URL: http://jira.jboss.com/jira/browse/JBAS-1560
 Project: JBoss Application Server
Type: Bug
  Components: EJBs  
Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final,  JBossAS-4.0.1 SP1
Reporter: Scott M Stark
 Assigned to: Scott M Stark 
Priority: Critical
 Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1,  
JBossAS-3.2.8 Final


The background processing of expired stateful sessions that have been 
passivated  can result in deadlock when clustering is used due to the fact that 
removal of the stateful session occurs with the cache lock held. This conflicts 
with removal requests sent to invalidate a cache entry. The deadlock is 
illustrated by the following 3.2.6 traces:

Thread-25 daemon prio=1 tid=0x89648448 nid=0x3805 in Object.wait() 
[8aaed000..8aaed87c]
at java.lang.Object.wait(Native Method)
at org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:505)
at org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:183)
- locked 0x9b8ea9e8 (a java.lang.Object)
at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:384)
at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:134)
at 
org.jboss.ha.framework.server.HAPartitionImpl.callMethodOnCluster(HAPartitionImpl.java:620)
at 
org.jboss.ha.hasessionstate.server.HASessionStateImpl.removeSession(HASessionStateImpl.java:533)
at 
org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.removePassivated(StatefulHASessionPersistenceManager.java:219)
at 
org.jboss.ejb.plugins.StatefulSessionInstanceCache.removePassivated(StatefulSessionInstanceCache.java:193)
at 
org.jboss.ejb.plugins.LRUStatefulContextCachePolicy$RemoverTask.run(LRUStatefulContextCachePolicy.java:146)
- locked 0x9296b8c0 (a java.lang.Object)
at java.util.TimerThread.mainLoop(Timer.java:432)
at java.util.TimerThread.run(Timer.java:382)


MessageDispatcher up processing thread daemon prio=1 tid=0x086c06b0 
nid=0x3805 waiting for monitor entry [8b788000..8b78887c]
at 
org.jboss.ejb.plugins.AbstractInstanceCache.remove(AbstractInstanceCache.java:206)
- waiting to lock 0x9296b8c0 (a java.lang.Object)
at 
org.jboss.ejb.plugins.StatefulHASessionPersistenceManager.sessionExternallyModified(StatefulHASessionPersistenceManager.java:231)
at 
org.jboss.ha.hasessionstate.server.HASessionStateImpl.ownedObjectExternallyModified(HASessionStateImpl.java:587)
at 
org.jboss.ha.hasessionstate.server.HASessionStateImpl._setOwnership(HASessionStateImpl.java:504)
at sun.reflect.GeneratedMethodAccessor400.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
at 
org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:828)
at 
org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
at 
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
at 
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at 
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:534)

The background removal of the expired passivated sessions should not be done 
with the cache lock held.


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-29) Added URL Service MBean

2005-03-07 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-29?page=comments#action_12315908 ]
 
Scott M Stark commented on JBAS-29:
---

Generalize as per the JndiBindingService comments. The input attributes should 
be the set of jndi bindings with their jndi name, java bean type, and the value 
to bind in string form:

binding name=some-jndi-name type=javabean.typevalue to bind/binding

The string value should be converted to the actual type based on the type given 
and an associated java.beans.PropertyEditor.


 Added URL Service MBean
 ---

  Key: JBAS-29
  URL: http://jira.jboss.com/jira/browse/JBAS-29
  Project: JBoss Application Server
 Type: Patch
   Components: Naming
 Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1
  Environment: patches against src of JBossAS-4.0.1RC1, JBossAS-4.0.1RC2
 Reporter: Phil Cornelius
 Assignee: Scott M Stark
  Attachments: URLResource_jboss-4.0.1RC2.patch, was_urlresource.png

 Original Estimate: 2 hours
 Remaining: 2 hours

 duplicated from sourceforge/
 Further to RFE991650
 http://sourceforge.net/tracker/index.php?func=detailaid=991650group_id=22866atid=376688
 Attached is a patch that adds the URLResource Service
 needed to actually bind the URLResources into the jboss
 jndi directory.
 Until now the only way of adding a resource of type
 java.net.URL was to explicity write it in to the jboss
 deployment descriptors.
 Scott wrote the jboss server code to bind the URL
 resource references to a jboss jndi name.. (as in the
 RFE above) but there wasn't an easy way to bind the
 actual URLs to those jndi names.
 Would appreciate it if this made it to RC2
 The patch is against the jboss-4.0.1RC1-src
 Why do this?
 If you are OEMing your product on jboss then would be
 nice to keep system paths and external resources loosly
 coupled from the EAR file.. best way is to use a J2EE
 URL resource.. if these resources are bound in a
 service file (like all other resources) then they are
 easy to change with an installer say, or even at runtime...
 Tasks associated with this patch are welcome.
 Yours
 Phil
 PS. I noticed the JSR-77 URLResource class in the
 management module and wasn't sure how this ties in?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1553) Update the JAAS login module base class password mapping options

2005-03-07 Thread Scott M Stark (JIRA)
Update the JAAS login module base class password mapping options


 Key: JBAS-1553
 URL: http://jira.jboss.com/jira/browse/JBAS-1553
 Project: JBoss Application Server
Type: Feature Request
  Components: Security  
Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
Reporter: Scott M Stark


Currently we support a simple notion of only having the first login module 
perform authentication with all other login modules bypassing authentication 
when the password-stacking=useFirstPass 

We need to update the base login modules that support most of the options from 
the jaas developer guide:

* try_first_pass - If true, the first LoginModule in the stack saves the 
password entered, and subsequent LoginModules also try to use it. If 
authentication fails, the LoginModules prompt for a new password and retry the 
authentication.

* use_first_pass - If true, the first LoginModule in the stack saves the 
password entered, and subsequent LoginModules also try to use it. LoginModules 
do not prompt for a new password if authentication fails (authentication simply 
fails).

* try_mapped_pass - If true, the first LoginModule in the stack saves the 
password entered, and subsequent LoginModules attempt to map it into their 
service-specific password. If authentication fails, the LoginModules prompt for 
a new password and retry the authentication.

* use_mapped_pass - If true, the first LoginModule in the stack saves the 
password entered, and subsequent LoginModules attempt to map it into their 
service-specific password. LoginModules do not prompt for a new password if 
authentication fails (authentication simply fails).

* moduleBanner - If true, then when invoking the CallbackHandler, the 
LoginModule provides a TextOutputCallback as the first Callback, which 
describes the LoginModule performing the authentication.
 


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1545) FileURLConnection breaks if path has spaces

2005-03-04 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1545?page=history ]
 
Scott M Stark closed JBAS-1545:
---

 Resolution: Done
Fix Version:  JBossAS-4.0.2RC1
 JBossAS-4.0.2 Final

The 4.0.1SP1 release did not include the 
org.jboss.net.protocol.file.decodeFilePaths change.

 FileURLConnection breaks if path has spaces
 ---

  Key: JBAS-1545
  URL: http://jira.jboss.com/jira/browse/JBAS-1545
  Project: JBoss Application Server
 Type: Bug
 Versions:  JBossAS-4.0.1 SP1
  Environment: AMD 2600, Windows XP
 Java Version 1.4.2_07 
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-b05) 
 Java HotSpot(TM) Client VM (build 1.4.2_07-b05, mixed mode) 
 Reporter: Dave Lindquist
  Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final



 The org.jboss.net.protocol.file.FileURLConnection object is unable to handle 
 paths with spaces, and seems to die.
 For example, when trying to parse an XML document through Xerces, calling the 
 method:
 DocumentBuilder.parse(File filename)
 where filename is equal to D:\path\with spaces\to\file.xml will produce 
 this:
 java.io.FileNotFoundException: D:\path\with%20spaces\to\file.xml 
  at 
 org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:71)
  
  at 
 org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:80)
  
  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.DOMParser.parse(Unknown Source) 
  at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) 
  at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) 
 ...etc...
 Note that the filename now suddenly has %20 in it.
 The problem persists inspite of setting JAVA_OPTS to 
 -Dorg.jboss.net.protocol.file.decodeFilePaths=true as recommended in 
 JBAS-363 (yes, the output of run.bat was noted, and it did confirm that 
 JAVA_OPTS was set).
 This is a MAJOR blocker, as it is impossible to parse XML files if their path 
 has a space in it, and there appears to be no workaround.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-29) Added URL Service MBean

2005-03-03 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-29?page=comments#action_12315877 ]
 
Scott M Stark commented on JBAS-29:
---

Generalize it and it will be included. I'm not going to include something that 
is not going to be supported over a longer term. If you don't generalize it it 
will wait until I can do it.

 Added URL Service MBean
 ---

  Key: JBAS-29
  URL: http://jira.jboss.com/jira/browse/JBAS-29
  Project: JBoss Application Server
 Type: Patch
   Components: Naming
 Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1
  Environment: patches against src of JBossAS-4.0.1RC1, JBossAS-4.0.1RC2
 Reporter: Phil Cornelius
 Assignee: Scott M Stark
  Attachments: URLResource_jboss-4.0.1RC2.patch, was_urlresource.png

 Original Estimate: 2 hours
 Remaining: 2 hours

 duplicated from sourceforge/
 Further to RFE991650
 http://sourceforge.net/tracker/index.php?func=detailaid=991650group_id=22866atid=376688
 Attached is a patch that adds the URLResource Service
 needed to actually bind the URLResources into the jboss
 jndi directory.
 Until now the only way of adding a resource of type
 java.net.URL was to explicity write it in to the jboss
 deployment descriptors.
 Scott wrote the jboss server code to bind the URL
 resource references to a jboss jndi name.. (as in the
 RFE above) but there wasn't an easy way to bind the
 actual URLs to those jndi names.
 Would appreciate it if this made it to RC2
 The patch is against the jboss-4.0.1RC1-src
 Why do this?
 If you are OEMing your product on jboss then would be
 nice to keep system paths and external resources loosly
 coupled from the EAR file.. best way is to use a J2EE
 URL resource.. if these resources are bound in a
 service file (like all other resources) then they are
 easy to change with an installer say, or even at runtime...
 Tasks associated with this patch are welcome.
 Yours
 Phil
 PS. I noticed the JSR-77 URLResource class in the
 management module and wasn't sure how this ties in?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1544) Wrong MBean attribute name in jboss:service=Mail (POP3SererHost )

2005-03-03 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1544?page=history ]
 
Scott M Stark closed JBAS-1544:
---

 Resolution: Done
Fix Version:  JBossAS-4.0.2RC1
 JBossAS-4.0.2 Final
 JBossAS-5.0 Alpha

 Wrong MBean attribute name in jboss:service=Mail (POP3SererHost )
 -

  Key: JBAS-1544
  URL: http://jira.jboss.com/jira/browse/JBAS-1544
  Project: JBoss Application Server
 Type: Bug
   Components: JMX
 Versions:  JBossAS-4.0.1 SP1
 Reporter: Goran Ehrsson
 Priority: Minor
  Fix For:  JBossAS-4.0.2RC1, JBossAS-4.0.2 Final, JBossAS-5.0 Alpha



 While browsing the Management Console on my newly installed jboss-4.0.1sp1 I 
 found a misspelled MBean attribute in the Mail service. POP3SererHost should 
 be POP3ServerHost I assume.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBXB-4) JBossXBSchemaValidator IllegalAccessError under jrockit 1.5.0

2005-03-02 Thread Scott M Stark (JIRA)
JBossXBSchemaValidator IllegalAccessError under jrockit 1.5.0
-

 Key: JBXB-4
 URL: http://jira.jboss.com/jira/browse/JBXB-4
 Project: JBoss XML Binding (JBossXB)
Type: Bug
 Environment: jrockit 1.5.0 from:
http://commerce.bea.com/products/weblogicjrockit/5.0/jr_50.jsp
[EMAIL PROTECTED] bin]$ /usr/java/jrockit-jdk1.5.0/bin/java -version
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32, R25.0.0-75, GC:
 System optimized over throughput (initial strategy singleparpar))

Reporter: Scott M Stark
 Assigned to: Alexey Loubyansky 


Starting the current Branch_4_0 code with jrocket 1.5.0, I'm seeing the 
following error which looks like an integration problem with the xml parser 
bundled with the jdk. This is using the run.sh script so the lib/endorsed 
should be used. Validate whether this is an invalid assumption on our part or a 
problem with the jrockit jdk.

2005-03-02 04:15:30,659 DEBUG 
[org.jboss.security.auth.login.XMLLoginConfigImpl] Failed to load config as XML
java.lang.IllegalAccessError: handleStartElement
at 
org.apache.xerces.impl.xs.JBossXBSchemaValidator.init(JBossXBSchemaValidator.java:20)
at 
org.jboss.xml.binding.parser.xni.XniJBossXBParser$ParserConfiguration.configurePipeline(XniJBossXBParser.java:521)
at org.apache.xerces.parsers.DTDConfiguration.reset()V(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Z)Z(Unknown Source)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown
 Source)
at 
org.apache.xerces.parsers.XMLParser.parse(Lorg.apache.xerces.xni.parser.XMLInputSource;)V(Unknown
 Source)
at 
org.jboss.xml.binding.parser.xni.XniJBossXBParser.parse(XniJBossXBParser.java:207)
at org.jboss.xml.binding.Unmarshaller.unmarshal(Unmarshaller.java:94)
at 
org.jboss.security.auth.login.XMLLoginConfigImpl.loadXMLConfig(XMLLoginConfigImpl.java:307)
at 
org.jboss.security.auth.login.XMLLoginConfigImpl.loadConfig(XMLLoginConfigImpl.java:273)
at 
org.jboss.security.auth.login.XMLLoginConfigImpl.loadConfig(XMLLoginConfigImpl.java:253)
at 
org.jboss.security.auth.login.XMLLoginConfig.startService(XMLLoginConfig.java:152)
at 
org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
at 
org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
at 
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown
 Source)
at 
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown
 Source)
at 
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at 
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
at 
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:911)
at $Proxy0.start()V(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:416)
at 
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown
 Source)
at 
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown
 Source)
at 
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at 
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net

[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1540) java.lang.ClassNotFoundException: com.ionific.flash.sessions.admin.AdminAccountInfo during startup

2005-03-02 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1540?page=history ]
 
Scott M Stark closed JBAS-1540:
---

Resolution: Rejected

This is not a jboss/tomcat class so apparently the class has been removed and 
the persisted value cannot be restored. This simply means the session is lost.

 java.lang.ClassNotFoundException: 
 com.ionific.flash.sessions.admin.AdminAccountInfo during startup
 --

  Key: JBAS-1540
  URL: http://jira.jboss.com/jira/browse/JBAS-1540
  Project: JBoss Application Server
 Type: Bug
 Reporter: David Ching



 I encountered a following error when I start my JBOSS 3.0.11, I would like to 
 know where can I get the following class file. Thanks in advance. 
 2005-03-01 17:11:06,220 ERROR [org.apache.catalina.session.ManagerBase] 
 Exception loading sessions from persistent storage
 java.lang.ClassNotFoundException: 
 com.ionific.flash.sessions.admin.AdminAccountInfo
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1340)
 at 
 org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1189)
 at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:219)
 at 
 org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:72)
 at 
 java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
 at 
 java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
 at 
 java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
 at 
 org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1342)
 at 
 org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:885)
 at 
 org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:416)
 at 
 org.apache.catalina.session.StandardManager.load(StandardManager.java:343)
 at 
 org.apache.catalina.session.StandardManager.start(StandardManager.java:657)
 at 
 org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:499)
 at 
 org.apache.catalina.startup.ContextConfig.managerConfig(ContextConfig.java:315)
 at 
 org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:635)
 at 
 org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:216)
 at 
 org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 at 
 org.apache.catalina.core.StandardContext.start(StandardContext.java:4290)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
 at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
 at 
 org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at 
 org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-29) Added URL Service MBean

2005-03-02 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-29?page=history ]

Scott M Stark updated JBAS-29:
--

Attachment: URLResource_jboss-4.0.1RC2.patch

As far as I can see the given URLService does not address the fact that a 
webdav url cannot be created without installing a webdav protocol handler. As 
such, I don't see why this should not be generalized.

 Added URL Service MBean
 ---

  Key: JBAS-29
  URL: http://jira.jboss.com/jira/browse/JBAS-29
  Project: JBoss Application Server
 Type: Patch
   Components: Naming
 Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1
  Environment: patches against src of JBossAS-4.0.1RC1, JBossAS-4.0.1RC2
 Reporter: Phil Cornelius
 Assignee: Scott M Stark
  Attachments: URLResource_jboss-4.0.1RC2.patch, was_urlresource.png

 Original Estimate: 2 hours
 Remaining: 2 hours

 duplicated from sourceforge/
 Further to RFE991650
 http://sourceforge.net/tracker/index.php?func=detailaid=991650group_id=22866atid=376688
 Attached is a patch that adds the URLResource Service
 needed to actually bind the URLResources into the jboss
 jndi directory.
 Until now the only way of adding a resource of type
 java.net.URL was to explicity write it in to the jboss
 deployment descriptors.
 Scott wrote the jboss server code to bind the URL
 resource references to a jboss jndi name.. (as in the
 RFE above) but there wasn't an easy way to bind the
 actual URLs to those jndi names.
 Would appreciate it if this made it to RC2
 The patch is against the jboss-4.0.1RC1-src
 Why do this?
 If you are OEMing your product on jboss then would be
 nice to keep system paths and external resources loosly
 coupled from the EAR file.. best way is to use a J2EE
 URL resource.. if these resources are bound in a
 service file (like all other resources) then they are
 easy to change with an installer say, or even at runtime...
 Tasks associated with this patch are welcome.
 Yours
 Phil
 PS. I noticed the JSR-77 URLResource class in the
 management module and wasn't sure how this ties in?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-29) Added URL Service MBean

2005-03-01 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-29?page=comments#action_12315865 ]
 
Scott M Stark commented on JBAS-29:
---

Because mail, datasources and jms resources have a non-trivial configuration 
aspect of a service that a URL binding does not. There is no comparision other 
than the fact that these services bind things into jndi.  It should be a simple 
change to generalize this service into a JndiBindingService that takes a 
string, the class name of the type to bind, and uses the java beans property 
editor framework to convert the string to the actual type to bind.

 Added URL Service MBean
 ---

  Key: JBAS-29
  URL: http://jira.jboss.com/jira/browse/JBAS-29
  Project: JBoss Application Server
 Type: Patch
   Components: Naming
 Versions: JBossAS-4.0.1 Final, JBossAS-4.0.2 Final,  JBossAS-4.0.2RC1
  Environment: patches against src of JBossAS-4.0.1RC1, JBossAS-4.0.1RC2
 Reporter: Phil Cornelius
 Assignee: Scott M Stark


 Original Estimate: 2 hours
 Remaining: 2 hours

 duplicated from sourceforge/
 Further to RFE991650
 http://sourceforge.net/tracker/index.php?func=detailaid=991650group_id=22866atid=376688
 Attached is a patch that adds the URLResource Service
 needed to actually bind the URLResources into the jboss
 jndi directory.
 Until now the only way of adding a resource of type
 java.net.URL was to explicity write it in to the jboss
 deployment descriptors.
 Scott wrote the jboss server code to bind the URL
 resource references to a jboss jndi name.. (as in the
 RFE above) but there wasn't an easy way to bind the
 actual URLs to those jndi names.
 Would appreciate it if this made it to RC2
 The patch is against the jboss-4.0.1RC1-src
 Why do this?
 If you are OEMing your product on jboss then would be
 nice to keep system paths and external resources loosly
 coupled from the EAR file.. best way is to use a J2EE
 URL resource.. if these resources are bound in a
 service file (like all other resources) then they are
 easy to change with an installer say, or even at runtime...
 Tasks associated with this patch are welcome.
 Yours
 Phil
 PS. I noticed the JSR-77 URLResource class in the
 management module and wasn't sure how this ties in?

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-11) Error redeploying dependent war

2005-02-27 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-11?page=comments#action_12315852 ]
 
Scott M Stark commented on JBAS-11:
---

That really is not the correct fix. This method should really be removing the 
war dependency from the service in addition to nulling out all of these 
variables as the war has been undeployed and should no longer be usable. The 
redeployment of the properties service would then have no dependent war to 
start. What is really needed is a redeploy notion that would recycle the 
dependent deployments, but such a notion does not exist.

 Error redeploying dependent war
 ---

  Key: JBAS-11
  URL: http://jira.jboss.com/jira/browse/JBAS-11
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-4.0.0 Final
 Reporter: bern
 Assignee: Scott M Stark



 This is a taken from the forum post from octopus see 
 http://www.jboss.org/index.html?module=bbop=viewtopict=56015.
 I have a deployed webapp which depends on some mbean (having depends  clause 
 in jboss-web.xml).
 When mbean is being redeployed it causes redeploying this webapp which 
 finishes with NPE in WebModule.java
 This bug reproduced in both jboss 4.0.0 and 3.2.6
 Simple test case:
 Create sample service in /deploy, for example test-properties-service.xml
 Code:
 server
 mbean code=org.jboss.varia.property.SystemPropertiesService
 name=test:service=SystemProperties
 !-- Set propertuies using the properties file style. --
 attribute name=Properties
  /attribute
 /mbean
 /server
   
 Create sample war which depends on this service, for example
 Code:
 test.war
|
 WEB-INF
   |
web.xml
 jboss-web.xml
|
  META-INF
   
 where web.xml
 Code:
 web-app 
 /web-app
   
 jboss-web.xml
 Code:
 jboss-web
 dependstest:service=SystemProperties/depends
 /jboss-web
   
 now both test-properties-service.xml and test.war placed in /deploy and 
 deployed successfully.
 Now update test-properties-service.xml (edit-save, touch, etc)
 jboss will try to redeploy test.war with following result:
 Code:
 13:22:33,483 DEBUG [MainDeployer] Undeploying 
 file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-pr
 operties-service
 .xml
 13:22:33,483 DEBUG [SARDeployer] undeploying document 
 file:/C:/Cluster/jboss-3.2.6/server/all/deploy
 /test-properties
 -service.xml
 13:22:33,499 DEBUG [SARDeployer] stopping mbean test:service=SystemProperties
 13:22:33,499 DEBUG [ServiceController] stopping service: 
 test:service=SystemProperties
 13:22:33,514 DEBUG [ServiceController] stopping dependent services for: 
 test:service=SystemPropertie
 s depende
 nt services are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
  state: RUNNING
  I Depend On:  test:service=SystemProperties
  Depends On Me: ]
 13:22:33,530 DEBUG [ServiceController] stopping service: 
 jboss.web.deployment:war=test.war,id=-10807
 43623
 13:22:33,530 DEBUG [ServiceController] stopping dependent services for: 
 jboss.web.deployment:war=tes
 t.war,id=-1080743623
 dependent services are: []
 13:22:33,546 DEBUG [WebModule] Stopping 
 jboss.web.deployment:war=test.war,id=-1080743623
 13:22:33,546 INFO  [TomcatDeployer] undeploy, ctxPath=/test, 
 warUrl=file:/C:/Cluster/jboss-3.2.6/ser
 ver/all/tmp/deploy/tm
 p45130test.war/
 13:22:33,577 DEBUG [Context] Stopping
 13:22:33,577 DEBUG [Context] Stopping filters
 13:22:33,577 DEBUG [Context]  Stopping filter 'CommonHeadersFilter'
 13:22:33,592 DEBUG [Context] Processing standard container shutdown
 13:22:33,608 DEBUG [Context] Sending application stop events
 13:22:33,624 DEBUG [Context] resetContext 
 jboss.web:j2eeType=WebModule,name=//localhost/test,J2EEApp
 lication=none,J2EESer
 ver=none [EMAIL PROTECTED]
 13:22:33,624 DEBUG [Context] Stopping complete
 13:22:33,639 DEBUG [WebModule] Stopped 
 jboss.web.deployment:war=test.war,id=-1080743623
 13:22:33,639 DEBUG [LocalJBossServerDomain] handleNotification: 
 javax.management.Notification[source
 =jboss.system:service
 =ServiceController,type= 
 org.jboss.system.ServiceMBean.stop,sequenceNumber=225,timeStamp=10993981536
 39,message=null,userD
 ata=jboss.web.deployment:war=test.war,id=-1080743623]
 13:22:33,655 DEBUG [LocalJBossServerDomain] handleNotification: 
 javax.management.Notification[source
 =jboss.system:service
 =ServiceController,type= 
 org.jboss.system.ServiceMBean.stop,sequenceNumber=226,timeStamp=10993981536
 55,message=null,userD
 ata=test:service=SystemProperties]
 13:22:33,671 DEBUG [LocalJBossServerDomain] handleNotification: 
 javax.management.Notification[source
 =jboss.system:service
 =ServiceDeployer,type=org.jboss.deployment.SubDeployer.stop,sequenceNumber=114,timeStamp=10993981536
 71,message=null,userD
 [EMAIL PROTECTED] { 

[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1516) Tomcat5: StandardContext getConfigBase tries to create a directory

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1516?page=history ]

Scott M Stark updated JBAS-1516:


Priority: Critical  (was: Minor)

 Tomcat5: StandardContext getConfigBase tries to create a directory
 --

  Key: JBAS-1516
  URL: http://jira.jboss.com/jira/browse/JBAS-1516
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final,  JBossAS-4.0.1 SP1
  Environment: JBoss 4.0.1sp1, Solaris8
 Reporter: Roland R?z
 Assignee: Remy Maucherat
 Priority: Critical
  Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final,  JBossAS-3.2.8 Final


 Original Estimate: 10 minutes
 Remaining: 10 minutes

 Hello,
 Just to explain you the circumstances why this request has arised.
 I try to secure JBoss with a java security policy. The policy should prevent
 somebody from writing in the JBoss installation directory.
 For this reason I set a File permission that allows only reading on the 
 JBoss installation directory.
 It looks like this
 grant {
   permission java.io.FilePermission ${jboss.home.dir}/-, read;
 ...
 };
 Now when I start JBoss and deploy a War file I receive the following 
 AccessPermissionException
  Caused by: java.security.AccessControlException: access denied 
 (java.io.FilePermission 
 /opt/jboss/4.0.1/server/myserver/conf/jboss.web/localhost write)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
 at java.io.File.mkdir(File.java:1097)
 at java.io.File.mkdirs(File.java:1122)
 at 
 org.apache.catalina.core.StandardContext.getConfigBase(StandardContext.java:4858)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4071)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
 at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:121)
 at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:805)
 at org.a
 pache.catalina.core.StandardHost.addChild(StandardHost.java:595)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
 ... 152 more
 The method that creates the Exception looks like this
  private File org.apache.catalina.core.StandardContext#getConfigBase()
 {
 File configBase = new File(System.getProperty(catalina.base), 
 conf);
 if(!configBase.exists())
 return null;
 Container container = this;
 Container host = null;
 Container engine = null;
 for(; container != null; container = container.getParent())
 {
 if(container instanceof Host)
 host = container;
 if(container instanceof Engine)
 engine = container;
 }
 if(engine != null)
 configBase = new File(configBase, engine.getName());
 if(host != null)
 configBase = new File(configBase, host.getName());
 configBase.mkdirs();  // here it crashes
 return configBase;
 }
 JBoss sets the saveConfig Flag of the StandardContext to false.
 (see TomcatDeployer#performDeployInternal)
 configBase.mkdirs() should only be invoked if the saveConfig Flag is set to 
 true.
 Regards

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1522) HttpNamingContextFactory fails due to system property read when under a security manager

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1522?page=history ]

Scott M Stark reassigned JBAS-1522:
---

Assign To: Scott M Stark

 HttpNamingContextFactory fails due to system property read when under a 
 security manager
 

  Key: JBAS-1522
  URL: http://jira.jboss.com/jira/browse/JBAS-1522
  Project: JBoss Application Server
 Type: Bug
   Components: Naming
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Scott M Stark
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha,  JBossAS-3.2.8 Final



 Running under a security manager with the 
 org.jboss.naming.HttpNamingContextFactory can result in the following failure 
 due to the property access not being in a privileged block. The failure 
 should also be ignored since its an optional override setting.
 java.lang.ExceptionInInitializerError
 at 
 org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:106)
 at 
 org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:65)
 at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
 at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
 at javax.naming.InitialContext.init(InitialContext.java:219)
 at javax.naming.InitialContext.(InitialContext.java:195)
 at com.nineci.applet.HelloBeanApplet.start(HelloBeanApplet.java:31)
 at sun.applet.AppletPanel.run(AppletPanel.java:377)
 at java.lang.Thread.run(Thread.java:534)
 Caused by: java.security.AccessControlException: access denied 
 (java.util.PropertyPermission 
 org.jboss.security.httpInvoker.sslSocketFactoryBuilder read)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1276)
 at java.lang.System.getProperty(System.java:573)
 at org.jboss.invocation.http.interfaces.Util.(Util.java:76)
 ... 9 more

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Reopened: (JBAS-1520) patched references to missing field DEFAULT_PARTITION in org.jboss.metadata.ClusterConfigMetaData

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1520?page=history ]
 
Scott M Stark reopened JBAS-1520:
-

 Assign To: Adrian Brock

The comment here applies to JBAS-1521. This issue is actually a duplicate of 
JBAS-1501 and will be closed as such.

 patched references to missing field DEFAULT_PARTITION in 
 org.jboss.metadata.ClusterConfigMetaData
 -

  Key: JBAS-1520
  URL: http://jira.jboss.com/jira/browse/JBAS-1520
  Project: JBoss Application Server
 Type: Patch
   Components: Clustering
 Reporter: Marcin Mieszek
 Assignee: Adrian Brock
 Priority: Blocker



 This is the first time I submit anything here.. so please be patient to me :)
 Module jboss-head failed to compile as in 1.7.6.1 version of 
 org.jboss.metadata.ClusterConfigMetaData constant:
 public final static String DEFAULT_PARTITION = DefaultPartition;
 was replaced with default partition logic in 
 org.jboss.system.server.ServerConfigUtil cvs version 1.3 with method:
 public static String getDefaultPartitionName()
 However, there are still references to DEFAULT_PARTITION in files:
 1. org.jboss.ha.hasessionstate.server.HASessionStateImpl cvs version 1.15 at 
 line 54:
 protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
   
   ^^
 I suggest changing to:
 protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.system.server.ServerConfigUtil.getDefaultPartitionName();
 2. org.jboss.ha.framework.server.ClusterPartition cvs version 1.36 at line 54:
 protected String partitionName = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
  
 ^^  
 I suggest changing to:
 protected String partitionName = 
 org.jboss.system.server.ServerConfigUtil.getDefaultPartitionName();  
 Below are build errors:
 D:\jboss\jboss-head\cluster\src\main\org\jboss\ha\framework\server\ClusterPartition.java:54:
  cannot find symbol
 symbol  : variable DEFAULT_PARTITION
 location: class org.jboss.metadata.ClusterConfigMetaData
protected String partitionName = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
 ^
 D:\jboss\jboss-head\cluster\src\main\org\jboss\ha\hasessionstate\server\HASessionStateImpl.java:54:
  cannot find symbol
 symbol  : variable DEFAULT_PARTITION
 location: class org.jboss.metadata.ClusterConfigMetaData
protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
   
   ^
 I hope it may be useful and the format of my message is readable and this is 
 the right place to post this piece of information.
 Best regards,
 Marcin Mieszek

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1520) patched references to missing field DEFAULT_PARTITION in org.jboss.metadata.ClusterConfigMetaData

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1520?page=history ]
 
Scott M Stark closed JBAS-1520:
---

Resolution: Duplicate Issue

 patched references to missing field DEFAULT_PARTITION in 
 org.jboss.metadata.ClusterConfigMetaData
 -

  Key: JBAS-1520
  URL: http://jira.jboss.com/jira/browse/JBAS-1520
  Project: JBoss Application Server
 Type: Patch
   Components: Clustering
 Reporter: Marcin Mieszek
 Assignee: Adrian Brock
 Priority: Blocker



 This is the first time I submit anything here.. so please be patient to me :)
 Module jboss-head failed to compile as in 1.7.6.1 version of 
 org.jboss.metadata.ClusterConfigMetaData constant:
 public final static String DEFAULT_PARTITION = DefaultPartition;
 was replaced with default partition logic in 
 org.jboss.system.server.ServerConfigUtil cvs version 1.3 with method:
 public static String getDefaultPartitionName()
 However, there are still references to DEFAULT_PARTITION in files:
 1. org.jboss.ha.hasessionstate.server.HASessionStateImpl cvs version 1.15 at 
 line 54:
 protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
   
   ^^
 I suggest changing to:
 protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.system.server.ServerConfigUtil.getDefaultPartitionName();
 2. org.jboss.ha.framework.server.ClusterPartition cvs version 1.36 at line 54:
 protected String partitionName = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
  
 ^^  
 I suggest changing to:
 protected String partitionName = 
 org.jboss.system.server.ServerConfigUtil.getDefaultPartitionName();  
 Below are build errors:
 D:\jboss\jboss-head\cluster\src\main\org\jboss\ha\framework\server\ClusterPartition.java:54:
  cannot find symbol
 symbol  : variable DEFAULT_PARTITION
 location: class org.jboss.metadata.ClusterConfigMetaData
protected String partitionName = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
 ^
 D:\jboss\jboss-head\cluster\src\main\org\jboss\ha\hasessionstate\server\HASessionStateImpl.java:54:
  cannot find symbol
 symbol  : variable DEFAULT_PARTITION
 location: class org.jboss.metadata.ClusterConfigMetaData
protected final String DEFAULT_PARTITION_JNDI_NAME = 
 org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION;
   
   ^
 I hope it may be useful and the format of my message is readable and this is 
 the right place to post this piece of information.
 Best regards,
 Marcin Mieszek

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1479) SFSB handle should use JNDI

2005-02-25 Thread Scott M Stark (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBAS-1479?page=comments#action_12315790 ]
 
Scott M Stark commented on JBAS-1479:
-

You don't get full backward compatibility with the 
org.jboss.ejb.sfsb.handle.V327 system property because the invoker is not used. 
The testBMTSessionHandleNoDefaultJNDI and testSessionHandleNoDefaultJNDI tests 
of the org.jboss.test.cts.test.StatefulSessionUnitTestCase are failing even 
with org.jboss.ejb.sfsb.handle.V327 set because they are expecting that the 
InitialContext that was in effect when the handle was created. To achieve this 
with the updated StatefulHandleImpl requires one to use the 
org.jboss.naming.NamingContextFactory as the JNDI 
Context.INITIAL_CONTEXT_FACTORY value. This factory saves its environment in a 
thread local that is used by the StatefulHandleImpl.

 SFSB handle should use JNDI
 ---

  Key: JBAS-1479
  URL: http://jira.jboss.com/jira/browse/JBAS-1479
  Project: JBoss Application Server
 Type: Bug
   Components: EJBs
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Adrian Brock
 Assignee: Adrian Brock
  Fix For:  JBossAS-4.0.2RC1



 The SFSB handle should use jndi when doing getEJBObject.
 The use of an invoker does not work, e.g. the jrmp invoker cannot reconnect
 across server restarts.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1525) Generalize the LdapLoginModule user and roles search mechanism

2005-02-25 Thread Scott M Stark (JIRA)
Generalize the LdapLoginModule user and roles search mechanism
--

 Key: JBAS-1525
 URL: http://jira.jboss.com/jira/browse/JBAS-1525
 Project: JBoss Application Server
Type: Feature Request
  Components: Security  
Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final, 
JBossAS-5.0 Alpha, JBossPOJOServer-1.0 Final
Reporter: Scott M Stark


There are 3 areas where the LdapLoginModule can be generalized to improve its 
utility across ldap schemas:

1. Allow the context for the user to be a search criteria that can be a 
function of the username rather than a specific context DN.

2. Allow the context for the roles to be a search criteria that can be a 
function of the username rather than a specific context DN.

3. Allow for a mapping from the ldap group to a role name so that the ldap 
server does not need to know application specific roles.


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1479) SFSB handle should use JNDI

2005-02-25 Thread Scott M Stark (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBAS-1479?page=comments#action_12315810 ]
 
Scott M Stark commented on JBAS-1479:
-

Just the use of the org.jboss.naming.NamingContextFactory fixes the tests.


 SFSB handle should use JNDI
 ---

  Key: JBAS-1479
  URL: http://jira.jboss.com/jira/browse/JBAS-1479
  Project: JBoss Application Server
 Type: Bug
   Components: EJBs
 Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
 Reporter: Adrian Brock
 Assignee: Adrian Brock
  Fix For:  JBossAS-4.0.2RC1



 The SFSB handle should use jndi when doing getEJBObject.
 The use of an invoker does not work, e.g. the jrmp invoker cannot reconnect
 across server restarts.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1526) Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the permissions of the replaced delegate

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1526?page=history ]

Scott M Stark reassigned JBAS-1526:
---

Assign To: Scott M Stark

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 

  Key: JBAS-1526
  URL: http://jira.jboss.com/jira/browse/JBAS-1526
  Project: JBoss Application Server
 Type: Bug
   Components: Security
 Versions:  JBossAS-4.0.1 SP1
  Environment: -
 Reporter: Roland R?z
 Assignee: Scott M Stark


 Original Estimate: 1 hour
 Remaining: 1 hour

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 According to the JACC specification all Permissions of a CodeSource or 
 ProtectionDomain should be returned. Currently these methods return only the 
 JACC Permissions, without the Permissions of the delegate class.
 The JACC Specification states (http://java.sun.com/j2ee/javaacc/):
 2.5 What a Provider Must Do
 paragraph 3
 A replacement Policy object must assume responsibility for performing all 
 policy decisions within the JRE in which it is installed that are requested 
 by way of the Policy interface that it implements.
 Example Implementation of DelegatingPolicy.getPermissions(x):
   public PermissionCollection getPermissions(ProtectionDomain domain) {
   PermissionCollection pc = super.getPermissions(domain);
   PermissionCollection delegated = 
 delegate.getPermissions(domain);
   for (Enumeration e = delegated.elements(); 
 e.hasMoreElements();) {
   Permission p = (Permission) e.nextElement();
   pc.add(p);
   }
   return pc;
   }
 Regards,
 Andrea

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1526) Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the permissions of the replaced delegate

2005-02-25 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1526?page=history ]

Scott M Stark updated JBAS-1526:


Fix Version:  JBossAS-4.0.2RC1
 JBossPOJOServer-1.0 Alpha
 JBossAS-5.0 Alpha

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 

  Key: JBAS-1526
  URL: http://jira.jboss.com/jira/browse/JBAS-1526
  Project: JBoss Application Server
 Type: Bug
   Components: Security
 Versions:  JBossAS-4.0.1 SP1
  Environment: -
 Reporter: Roland R?z
 Assignee: Scott M Stark
  Fix For:  JBossAS-4.0.2RC1, JBossPOJOServer-1.0 Alpha, JBossAS-5.0 Alpha


 Original Estimate: 1 hour
 Remaining: 1 hour

 Jacc: Request for the DelegatingPolicy.getPermissions(x) to also return the 
 permissions of the replaced delegate
 According to the JACC specification all Permissions of a CodeSource or 
 ProtectionDomain should be returned. Currently these methods return only the 
 JACC Permissions, without the Permissions of the delegate class.
 The JACC Specification states (http://java.sun.com/j2ee/javaacc/):
 2.5 What a Provider Must Do
 paragraph 3
 A replacement Policy object must assume responsibility for performing all 
 policy decisions within the JRE in which it is installed that are requested 
 by way of the Policy interface that it implements.
 Example Implementation of DelegatingPolicy.getPermissions(x):
   public PermissionCollection getPermissions(ProtectionDomain domain) {
   PermissionCollection pc = super.getPermissions(domain);
   PermissionCollection delegated = 
 delegate.getPermissions(domain);
   for (Enumeration e = delegated.elements(); 
 e.hasMoreElements();) {
   Permission p = (Permission) e.nextElement();
   pc.add(p);
   }
   return pc;
   }
 Regards,
 Andrea

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1515) Update the AOP binaries and remove the aop modules

2005-02-24 Thread Scott M Stark (JIRA)
Update the AOP binaries and remove the aop modules
--

 Key: JBAS-1515
 URL: http://jira.jboss.com/jira/browse/JBAS-1515
 Project: JBoss Application Server
Type: Task
  Components: Build System  
Versions:  JBossAS-4.0.2RC1
Reporter: Scott M Stark
 Fix For: JBossAS-4.0.2 Final


The aop deployer seems to no longer be built from the aspects module source. 
The current 4.0 branch binaries do not include the recent security changes and 
needs to be updated. If binaries are being used as the integration mechanism, 
there is no reason to be including obsolete source modules.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1293) AOP HTTP session replication under Tomcat 5

2005-02-24 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1293?page=history ]

Scott M Stark updated JBAS-1293:


Fix Version: (was: JBossAS-4.0.2 Final)

 AOP HTTP session replication under Tomcat 5
 ---

  Key: JBAS-1293
  URL: http://jira.jboss.com/jira/browse/JBAS-1293
  Project: JBoss Application Server
 Type: Feature Request
   Components: Clustering
 Versions: JBossAS-4.0.1 Final
 Reporter: Bela Ban
 Assignee: Ben Wang
  Fix For: JBossAS-5.0 Alpha


 Original Estimate: 10 weeks
 Remaining: 10 weeks

 Use TreeCacheAop to do field level http session replication.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-53) Rewrite of ENC for Web, EJB 2.1, and EJB 3.0

2005-02-24 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-53?page=history ]

Scott M Stark updated JBAS-53:
--

Fix Version: (was: JBossAS-4.0.2 Final)

 Rewrite of ENC for Web, EJB 2.1, and EJB 3.0
 

  Key: JBAS-53
  URL: http://jira.jboss.com/jira/browse/JBAS-53
  Project: JBoss Application Server
 Type: Feature Request
   Components: Naming
 Versions: JBossAS-4.0.2 Final
 Reporter: Bill Burke
 Assignee: Bill Burke


 Original Estimate: 1 day
 Remaining: 1 day

 Make the ENC be threadlocal based rather than classloader based as 
 classloader based can give incorrect behavior.  This task will be dependent 
 on a JBoss 4.0 point release.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Moved: (JBAS-1516) Tomcat5: StandardContext getConfigBase tries to create a directory

2005-02-24 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1516?page=history ]

Scott M Stark moved JBWEB-13 to JBAS-1516:
--

   Project: JBoss Application Server  (was: JBoss Web)
   Key: JBAS-1516  (was: JBWEB-13)
 Component: Web (Tomcat) service
(was: Tomcat)
   Version:  JBossAS-4.0.1 SP1
JBossAS-4.0.1 Final
 JBossAS-3.2.7 Final
(was:  JBossWeb-4.0.1)
   Fix Version: JBossAS-4.0.2 Final
JBossAS-5.0 Alpha
 JBossAS-3.2.8 Final
Security Level: Public

 Tomcat5: StandardContext getConfigBase tries to create a directory
 --

  Key: JBAS-1516
  URL: http://jira.jboss.com/jira/browse/JBAS-1516
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final,  JBossAS-4.0.1 SP1
  Environment: JBoss 4.0.1sp1, Solaris8
 Reporter: Roland R?z
 Assignee: Remy Maucherat
 Priority: Minor
  Fix For: JBossAS-5.0 Alpha, JBossAS-4.0.2 Final,  JBossAS-3.2.8 Final


 Original Estimate: 10 minutes
 Remaining: 10 minutes

 Hello,
 Just to explain you the circumstances why this request has arised.
 I try to secure JBoss with a java security policy. The policy should prevent
 somebody from writing in the JBoss installation directory.
 For this reason I set a File permission that allows only reading on the 
 JBoss installation directory.
 It looks like this
 grant {
   permission java.io.FilePermission ${jboss.home.dir}/-, read;
 ...
 };
 Now when I start JBoss and deploy a War file I receive the following 
 AccessPermissionException
  Caused by: java.security.AccessControlException: access denied 
 (java.io.FilePermission 
 /opt/jboss/4.0.1/server/myserver/conf/jboss.web/localhost write)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
 at java.security.AccessController.checkPermission(AccessController.java:401)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
 at java.lang.SecurityManager.checkWrite(SecurityManager.java:954)
 at java.io.File.mkdir(File.java:1097)
 at java.io.File.mkdirs(File.java:1122)
 at 
 org.apache.catalina.core.StandardContext.getConfigBase(StandardContext.java:4858)
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4071)
 at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
 at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:121)
 at 
 org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:143)
 at java.security.AccessController.doPrivileged(Native Method)
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:805)
 at org.a
 pache.catalina.core.StandardHost.addChild(StandardHost.java:595)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:324)
 at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
 ... 152 more
 The method that creates the Exception looks like this
  private File org.apache.catalina.core.StandardContext#getConfigBase()
 {
 File configBase = new File(System.getProperty(catalina.base), 
 conf);
 if(!configBase.exists())
 return null;
 Container container = this;
 Container host = null;
 Container engine = null;
 for(; container != null; container = container.getParent())
 {
 if(container instanceof Host)
 host = container;
 if(container instanceof Engine)
 engine = container;
 }
 if(engine != null)
 configBase = new File(configBase, engine.getName());
 if(host != null)
 configBase = new File(configBase, host.getName());
 configBase.mkdirs();  // here it crashes
 return configBase;
 }
 JBoss sets the saveConfig Flag of the StandardContext to false.
 (see TomcatDeployer#performDeployInternal)
 configBase.mkdirs() should only be invoked if the saveConfig Flag is set to 
 true.
 Regards

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products 

[JBoss-dev] [JBoss JIRA] Closed: (JBAS-275) 2 identical named mdbs cannot deploy

2005-02-24 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-275?page=history ]
 
Scott M Stark closed JBAS-275:
--


 2 identical named mdbs cannot deploy
 

  Key: JBAS-275
  URL: http://jira.jboss.com/jira/browse/JBAS-275
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For:  JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1



 SourceForge Submitter: charris .
 Two MDBs, both with the same ejb-name but *in different
 ejb-jars*, both produce MBeans with ObjectName
 jboss.j2ee:jndiName=local/MyMDBEJBName,service=EJB
 meaning that the second MDB will not deploy properly
 since the MBeanServer returns
 InstanceAlreadyExistsException. The ObjectNames are
 formed with the prefix /local to produce a dummy jndi
 name, but need to be more unique than this to avoid the
 clash.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-714) Automatically include everything in jboss/lib to classpath

2005-02-24 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-714?page=history ]
 
Scott M Stark closed JBAS-714:
--


 Automatically include everything in jboss/lib to classpath
 --

  Key: JBAS-714
  URL: http://jira.jboss.com/jira/browse/JBAS-714
  Project: JBoss Application Server
 Type: Feature Request
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For:  JBossAS-3.2.7 Final,  JBossAS-4.0.2RC1



 SourceForge Submitter: rmcauble .
 This is a convenience to as not to have to explictly list 
 out each jar in jboss/lib.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Created: (JBAS-1522) HttpNamingContextFactory fails due to system property read when under a security manager

2005-02-24 Thread Scott M Stark (JIRA)
HttpNamingContextFactory fails due to system property read when under a 
security manager


 Key: JBAS-1522
 URL: http://jira.jboss.com/jira/browse/JBAS-1522
 Project: JBoss Application Server
Type: Bug
  Components: Naming  
Versions:  JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final
Reporter: Scott M Stark
 Fix For:  JBossAS-4.0.2RC1, JBossAS-5.0 Alpha,  JBossAS-3.2.8 Final


Running under a security manager with the 
org.jboss.naming.HttpNamingContextFactory can result in the following failure 
due to the property access not being in a privileged block. The failure should 
also be ignored since its an optional override setting.

java.lang.ExceptionInInitializerError
at 
org.jboss.naming.HttpNamingContextFactory.getNamingServer(HttpNamingContextFactory.java:106)
at 
org.jboss.naming.HttpNamingContextFactory.getInitialContext(HttpNamingContextFactory.java:65)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.(InitialContext.java:195)
at com.nineci.applet.HelloBeanApplet.start(HelloBeanApplet.java:31)
at sun.applet.AppletPanel.run(AppletPanel.java:377)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.security.AccessControlException: access denied 
(java.util.PropertyPermission 
org.jboss.security.httpInvoker.sslSocketFactoryBuilder read)
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1276)
at java.lang.System.getProperty(System.java:573)
at org.jboss.invocation.http.interfaces.Util.(Util.java:76)
... 9 more


-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1380) UIL2 server accept thread can be lost due to unexpected error

2005-02-23 Thread Scott M Stark (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBAS-1380?page=comments#action_12315651 ]
 
Scott M Stark commented on JBAS-1380:
-

Just create a new issue and describe the failure scenario including the 
exception that is causing the accept problem. 

 UIL2 server accept thread can be lost due to unexpected error
 -

  Key: JBAS-1380
  URL: http://jira.jboss.com/jira/browse/JBAS-1380
  Project: JBoss Application Server
 Type: Bug
   Components: JMS service
 Versions: JBossAS-4.0.1 Final,  JBossAS-3.2.7 Final, JBossAS-5.0 Alpha
 Reporter: Scott M Stark
 Assignee: Scott M Stark
 Priority: Critical
  Fix For:  JBossAS-4.0.1 SP1, JBossAS-5.0 Alpha,  JBossAS-3.2.8 Final,  
 JBossAS-4.0.2RC1



 The UIL2 org.jboss.mq.il.uil2.UILServerILService connection accept thread 
 (UILServerILService Accept Thread) can exit prematurely if there is any 
 exception other than the expected java.io.IOException. Runtime errors like 
 java.lang.OutOfMemory due to recoverable resource exhuastion like too many 
 threads can cause the thread to exit with the result being that no further 
 jms connection can be made. The jms client would see an error like the 
 following in this case:
 org.jboss.mq.SpyJMSException: Cannot authenticate user; - nested throwable: 
 (java.net.SocketException: Connection reset)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1504) type mapping for boolean in finder wrong

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1504?page=history ]

Scott M Stark updated JBAS-1504:


Priority: Major  (was: Blocker)

 type mapping for boolean in finder wrong
 

  Key: JBAS-1504
  URL: http://jira.jboss.com/jira/browse/JBAS-1504
  Project: JBoss Application Server
 Type: Bug
   Components: CMP service
 Versions:  JBossAS-4.0.1 SP1
  Environment: JDK1.5.0-update1; JBoss 4.0.1SP1; MaxDB 7.5.00.23-1; jdbc 
 driver: sapdbc-7_6_00_00_3264.jar; Linux Debian Sarge
 Reporter: Ingo Bruell



 i have defined a finder in which i will test a boolean attribute, but i got a 
 database error that the datatype must be compatibel.
 In EJBQL i have tested attribute = false and the generated SQL says 
 attribute = 0, that is wrong cause MaxDB wants attribute = false.
 I have changed the mapping in standardjbosscmp-jdbc.xml to BOOLEAN but that 
 changed nothing. 
 I have defined a new mapping for MaxDB in standardjbosscmp-jdbc.xml:
   type-mapping
  nameMaxDB/name
  row-locking-templateSELECT ?1 FROM ?2 WHERE ?3 ORDER BY ?4 FOR 
 UPDATE/row-locking-template
  pk-constraint-templateCONSTRAINT ?1 PRIMARY KEY 
 (?2)/pk-constraint-template
  fk-constraint-templateALTER TABLE ?1 ADD FOREIGN KEY ?2 (?3) 
 REFERENCES ?4 (?5)/fk-constraint-template
   auto-increment-template?1/auto-increment-template
  alias-header-prefixt/alias-header-prefix
  alias-header-suffix_/alias-header-suffix
  alias-max-length32/alias-max-length
  subquery-supportedtrue/subquery-supported
  true-mapping1/true-mapping
  false-mapping0/false-mapping
  function-mapping
 function-namecount/function-name
 function-sqlcount(?1)/function-sql
  /function-mapping
  mapping
 java-typejava.lang.Integer/java-type
 jdbc-typeINTEGER/jdbc-type
 sql-typeINTEGER/sql-type
  /mapping
  mapping
 java-typejava.lang.Character/java-type
 jdbc-typeCHAR/jdbc-type
 sql-typeCHAR/sql-type
  /mapping
  mapping
 java-typejava.lang.String/java-type
 jdbc-typeVARCHAR/jdbc-type
 sql-typeVARCHAR(256)/sql-type
  /mapping
  mapping
 java-typejava.lang.Object/java-type
 jdbc-typeJAVA_OBJECT/jdbc-type
 sql-typeLONG BYTE/sql-type
  /mapping
  mapping
 java-typejava.lang.Byte/java-type
 jdbc-typeTINYINT/jdbc-type
 sql-typeCHAR BYTE/sql-type
  /mapping
  mapping
 java-typejava.sql.Timestamp/java-type
 jdbc-typeTIMESTAMP/jdbc-type
 sql-typeTIMESTAMP/sql-type
  /mapping
  mapping
 java-typejava.util.Date/java-type
 jdbc-typeTIMESTAMP/jdbc-type
 sql-typeTIMESTAMP/sql-type
  /mapping
  mapping
 java-typejava.sql.Time/java-type
 jdbc-typeTIME/jdbc-type
 sql-typeTIME/sql-type
  /mapping
  mapping
 java-typejava.lang.Boolean/java-type
 jdbc-typeBOOLEAN/jdbc-type
 sql-typeBOOLEAN/sql-type
  /mapping
  mapping
 java-typejava.lang.Float/java-type
 jdbc-typeFLOAT/jdbc-type
 sql-typeFLOAT/sql-type
  /mapping
  mapping
 java-typejava.lang.Short/java-type
 jdbc-typeSMALLINT/jdbc-type
  /mapping
  mapping
 java-typejava.lang.Double/java-type
 jdbc-typeDOUBLE/jdbc-type
 sql-typeDOUBLE PRECISION/sql-type
  /mapping
  mapping
 java-typejava.lang.Long/java-type
 jdbc-typeDECIMAL/jdbc-type
 sql-typeDECIMAL(20)/sql-type
  /mapping
   /type-mapping
   type-mapping
  nameCloudscape/name
  row-locking-template/
  pk-constraint-templateCONSTRAINT ?1 PRIMARY KEY 
 (?2)/pk-constraint-template
  fk-constraint-templateALTER TABLE ?1 ADD CONSTRAINT ?2 FOREIGN KEY 
 (?3) REFERENCES ?4 (?5)/fk-constraint-template
  alias-header-prefixt/alias-header-prefix
  alias-header-suffix_/alias-header-suffix
  alias-max-length32/alias-max-length
  subquery-supportedtrue/subquery-supported
  true-mapping1/true-mapping
  false-mapping0/false-mapping
  function-mapping
 function-namecount/function-name
 function-sqlcount(?1)/function-sql
  /function-mapping
  mapping
 java-typejava.math.BigDecimal/java-type
 jdbc-typeLONGVARCHAR/jdbc-type
 sql-typeLONG VARCHAR/sql-type
  /mapping
  mapping
 java-typejava.lang.Boolean/java-type
  

[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1499) classcast exception after jaas login, while context lookup

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1499?page=history ]

Scott M Stark updated JBAS-1499:


JBoss Forum Reference: 
http://www.jboss.org/index.html?module=bbop=viewtopict=60472
SourceForge Reference:   (was: 
http://www.jboss.org/index.html?module=bbop=viewtopict=60472)

 classcast exception after jaas login, while context lookup
 --

  Key: JBAS-1499
  URL: http://jira.jboss.com/jira/browse/JBAS-1499
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-4.0.1 Final
  Environment: windows xp + eclipse
 Reporter: sai krishna



 Please refer discussion: 
 top of stack:
 13:09:50,058 INFO [STDOUT] java.lang.ClassCastException
 13:09:50,058 INFO [STDOUT] at 
 org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
 13:09:50,058 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
 13:09:50,074 INFO [STDOUT] at 
 javax.naming.InitialContext.lookup(InitialContext.java:347)
 13:09:50,074 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getRemoteHome(MailerEnterpriseFactory.java:151)
 13:09:50,090 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getMailAccountHome(MailerEnterpriseFactory.java:100)
 description:
 I am getting this error after a successful anonymous/nobody login., and when 
 i run a method findAll to fetch all CMP beans. it fails to get the remote 
 home interface, whilst method context.lookup(). 
 I dont get this bug if i set up jaas from eclipse workbench workspace, and do 
 a lookup., findAll, and it returns all remote ejb proxies.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1499) classcast exception after jaas login, while context lookup

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1499?page=history ]

Scott M Stark updated JBAS-1499:


  Description: 
Please refer discussion: 

top of stack:
13:09:50,058 INFO [STDOUT] java.lang.ClassCastException
13:09:50,058 INFO [STDOUT] at 
org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
13:09:50,058 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
13:09:50,074 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
13:09:50,074 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
13:09:50,074 INFO [STDOUT] at 
javax.naming.InitialContext.lookup(InitialContext.java:347)
13:09:50,074 INFO [STDOUT] at 
jmail.ejb.util.MailerEnterpriseFactory.getRemoteHome(MailerEnterpriseFactory.java:151)
13:09:50,090 INFO [STDOUT] at 
jmail.ejb.util.MailerEnterpriseFactory.getMailAccountHome(MailerEnterpriseFactory.java:100)

description:
I am getting this error after a successful anonymous/nobody login., and when i 
run a method findAll to fetch all CMP beans. it fails to get the remote home 
interface, whilst method context.lookup(). 

I dont get this bug if i set up jaas from eclipse workbench workspace, and do a 
lookup., findAll, and it returns all remote ejb proxies.

  was:
Please refer discussion: 
http://www.jboss.org/index.html?module=bbop=viewtopict=60472

top of stack:
13:09:50,058 INFO [STDOUT] java.lang.ClassCastException
13:09:50,058 INFO [STDOUT] at 
org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
13:09:50,058 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
13:09:50,074 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
13:09:50,074 INFO [STDOUT] at 
org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
13:09:50,074 INFO [STDOUT] at 
javax.naming.InitialContext.lookup(InitialContext.java:347)
13:09:50,074 INFO [STDOUT] at 
jmail.ejb.util.MailerEnterpriseFactory.getRemoteHome(MailerEnterpriseFactory.java:151)
13:09:50,090 INFO [STDOUT] at 
jmail.ejb.util.MailerEnterpriseFactory.getMailAccountHome(MailerEnterpriseFactory.java:100)

description:
I am getting this error after a successful anonymous/nobody login., and when i 
run a method findAll to fetch all CMP beans. it fails to get the remote home 
interface, whilst method context.lookup(). 

I dont get this bug if i set up jaas from eclipse workbench workspace, and do a 
lookup., findAll, and it returns all remote ejb proxies.

@see also:
Create a bug report in jira with an example of what is being done. There is an 
incorrect assumption in the PropertyMap that only String values will be added 
that needs to be fixed.

http://jira.jboss.com/jira/browse/JBAS

_

Scott Stark
Chief Technology Officer
JBoss Inc.


SourceForge Reference: 
http://www.jboss.org/index.html?module=bbop=viewtopict=60472

 classcast exception after jaas login, while context lookup
 --

  Key: JBAS-1499
  URL: http://jira.jboss.com/jira/browse/JBAS-1499
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-4.0.1 Final
  Environment: windows xp + eclipse
 Reporter: sai krishna



 Please refer discussion: 
 top of stack:
 13:09:50,058 INFO [STDOUT] java.lang.ClassCastException
 13:09:50,058 INFO [STDOUT] at 
 org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
 13:09:50,058 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
 13:09:50,074 INFO [STDOUT] at 
 javax.naming.InitialContext.lookup(InitialContext.java:347)
 13:09:50,074 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getRemoteHome(MailerEnterpriseFactory.java:151)
 13:09:50,090 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getMailAccountHome(MailerEnterpriseFactory.java:100)
 description:
 I am getting this error after a successful anonymous/nobody login., and when 
 i run a method findAll to fetch all CMP beans. it fails to get the remote 
 home interface, whilst method context.lookup(). 
 I dont get this bug if i set up jaas from eclipse workbench workspace, and do 
 a lookup., findAll, and it returns all remote ejb proxies.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on 

[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1484) ClassCastException while creating JNDI SubContext

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1484?page=history ]
 
Scott M Stark closed JBAS-1484:
---

  Assign To: Scott M Stark
 Resolution: Done
Fix Version:  JBossAS-4.0.2RC1
 JBossAS-5.0 Alpha
  JBossAS-3.2.8 Final

This was fixed as part of JBAS-1497.

 ClassCastException while creating JNDI SubContext
 -

  Key: JBAS-1484
  URL: http://jira.jboss.com/jira/browse/JBAS-1484
  Project: JBoss Application Server
 Type: Bug
   Components: Naming
 Versions: JBossAS-4.0.1 Final
 Reporter: Jens Schumann
 Assignee: Scott M Stark
  Fix For: JBossAS-5.0 Alpha,  JBossAS-4.0.2RC1,  JBossAS-3.2.8 Final



 Creating a subcontext from a servlet failes with a ClassCastExeception.
 java.lang.ClassCastException
 at org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
 at org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
 at 
 org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:867)
 at 
 org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:858)
 at 
 javax.naming.InitialContext.createSubcontext(InitialContext.java:413)
 The debugger shows a CompoundName instance for the value jnp.parsedName 
 instead of a String. I was unable to create a testcase because I don't know 
 how to place the CompoundName instance this far. 
 Will examine the issue more closely.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1499) classcast exception after jaas login, while context lookup

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1499?page=history ]
 
Scott M Stark closed JBAS-1499:
---

  Assign To: Scott M Stark
 Resolution: Done
Fix Version:  JBossAS-4.0.2RC1
 JBossAS-5.0 Alpha
  JBossAS-3.2.8 Final

This was fixed as part of JBAS-1497.

 classcast exception after jaas login, while context lookup
 --

  Key: JBAS-1499
  URL: http://jira.jboss.com/jira/browse/JBAS-1499
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-4.0.1 Final
  Environment: windows xp + eclipse
 Reporter: sai krishna
 Assignee: Scott M Stark
  Fix For: JBossAS-5.0 Alpha,  JBossAS-4.0.2RC1,  JBossAS-3.2.8 Final



 Please refer discussion: 
 top of stack:
 13:09:50,058 INFO [STDOUT] java.lang.ClassCastException
 13:09:50,058 INFO [STDOUT] at 
 org.jboss.util.property.PropertyMap.remove(PropertyMap.java:198)
 13:09:50,058 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.getEnv(NamingContext.java:1299)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:526)
 13:09:50,074 INFO [STDOUT] at 
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
 13:09:50,074 INFO [STDOUT] at 
 javax.naming.InitialContext.lookup(InitialContext.java:347)
 13:09:50,074 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getRemoteHome(MailerEnterpriseFactory.java:151)
 13:09:50,090 INFO [STDOUT] at 
 jmail.ejb.util.MailerEnterpriseFactory.getMailAccountHome(MailerEnterpriseFactory.java:100)
 description:
 I am getting this error after a successful anonymous/nobody login., and when 
 i run a method findAll to fetch all CMP beans. it fails to get the remote 
 home interface, whilst method context.lookup(). 
 I dont get this bug if i set up jaas from eclipse workbench workspace, and do 
 a lookup., findAll, and it returns all remote ejb proxies.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1507) Many-Many unidirectional relationship

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1507?page=history ]

Scott M Stark updated JBAS-1507:


Priority: Major  (was: Critical)

 Many-Many unidirectional relationship
 -

  Key: JBAS-1507
  URL: http://jira.jboss.com/jira/browse/JBAS-1507
  Project: JBoss Application Server
 Type: Feature Request
   Components: CMP service
 Versions: JBossAS-4.0.1 Final
  Environment: Using MySQL and POJOs
 Reporter: Fiona Healy



 Hi, 
 I am trying to set up a many-many relationship between 2 EJBS ReportEJB and 
 FieldsEJB and i am failing terribly. 
 I have configured both ejb jar file and jbosscmp-jdbc files to compile but i 
 am getting an error on creating the Report bean that holds a set of the 
 FieldsEJB 
 I am getting an error
 NullPointerException
 ...cmp.jdbc.bridge.JDBCCMRFieldBridge.getRelatedPrimaryKey(JDBCFieldBridge.java:1847)
 Has anyone any ideai can attach code if necessary please help me out here

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-110) Intelligent Locking

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-110?page=history ]
 
Scott M Stark closed JBAS-110:
--

Resolution: Out of Date

 Intelligent Locking
 ---

  Key: JBAS-110
  URL: http://jira.jboss.com/jira/browse/JBAS-110
  Project: JBoss Application Server
 Type: Feature Request
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: nobody .
 There is a serious drawback I have seen in the 
 WebLogic 6.0 locking model.  You have several choices:
 1) Exclusive Locking (the entity EJB can only be used 
 by one caller at a time whether the method be called 
 is transactional or not)
 2) Database Locking (the backing datastore is used to 
 provide the locking and multiple entity EJB instances 
 are used to represent the same entity while providing 
 single-client access to each at any given time)
 3) Read Only (the object doesn't change so no locking 
 is needed)
 Model (1) is sloow because you obtain an exclusive 
 lock even when calling non-transactional methods 
 (like getFirstName()) in a non-transactional context.
 Model (2) is bad because I do all of my database 
 access in ejbStore().  If I have a Person entity EJB 
 with an email and firstName property I can have 
 the following scenario:
 1) Client A accesses Person with ID=1 and updates the 
 first name by calling setFirstName(String)
 2) Client B accesses Person with ID=1 and updates the 
 e-mail by calling setEmail(String)
 3) The ejbStore() method is called on Client A's 
 entity, storing the new first name.
 4) The ejbStore() method is called on Client B's 
 entity, overwriting the new first name with the old 
 one and storing the new e-mail.
 Model (3) is useless in most situations.
 ** BUT ** I have an idea and was wondering if JBoss 
 might already implement this.  If an entity EJB is 
 properly implemented then all methods that modify the 
 EJB in some way should require a transaction in some 
 way (either required, mandatory, or new).  Suppose we 
 used an EJB entity pool that behaved as follows.
 1) Any single entity is represented by a number of NON-
 transactional EJB instances and a SINGLE transactional 
 instance.
 2) Access to the NON-transactional intances is freely 
 allowed if methods are called in a state where they 
 will not participate in a transaction.  These 
 instances never have their ejbStore() methods called 
 since they don't change.  This allows high throughput 
 access for simple operations like getName()
 3) If a transactional method is called by a client 
 then the single transactional instance is exclusively 
 locked for that client.  Meanwhile the NON-
 transactional instances can be used by other clients 
 that are not attempting to involving the entity in a 
 transaction.
 4) If the transaction is rolled back, the 
 transactional instance is repopulated with data in the 
 database (i.e.: ejbLoad()) to reflect that the 
 changes were not committed.
 5) If the transaction commits, then container obtains 
 a lock on all instances of the entity.  This means the 
 container places a request for an exclusive lock on 
 all NON-transactional instances as well as the 
 transactional instance for which it already holds the 
 lock.
 6)Once a lock is obtained on all instances, then 
 ejbStore() is called on the transactional instance.  
 If all succeeds without an exception then all of the 
 NON-Transactional instances have their ejbLoad() 
 method called.  By calling ejbLoad(), the non-
 Transactional instances become aware of the changes 
 that occurred to the transactional instance.
 This always seemed to me like the model that was 
 intended when the EJB specification was written, but 
 it has not been implemented by the folks over at BEA.  
 I would love to see this in JBoss.  I have yet to 
 download JBoss because we need cluster and fail-over 
 support where I work.  Let me know if this seems like 
 a good model.  I wish I had the time to participate 
 and contribute to the source base.
 Best of luck...
 -Barry M. Caceres
 [EMAIL PROTECTED]

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-175) change of .dtd content-type on jboss.org

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-175?page=history ]
 
Scott M Stark closed JBAS-175:
--

Resolution: Out of Date

 change of .dtd content-type on jboss.org
 

  Key: JBAS-175
  URL: http://jira.jboss.com/jira/browse/JBAS-175
  Project: JBoss Application Server
 Type: Feature Request
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: lqd .
 hi,
 currently www.jboss.org is serving any .dtd documents
 with an HTTP Content-Type of
 application/octet-stream. it would be helpful if this
 could be changed to text/xml, that way one can view
 it in their browser instead of having to download the file.
 rgds,
   christian

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBBUILD-18) build script needs a Javadoc Target

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBBUILD-18?page=history ]

Scott M Stark updated JBBUILD-18:
-

  Assign To: (was: Scott M Stark)
Description: 
SourceForge Submitter: mattmunz .
Hi,

  Sometimes a developer just wants to look at the 
javadocs / API documentation, but does not need to 
build the entire project.  It would be useful to have a 
build target like documentation, javadocs, or api-
documentation that generates this for the user.

  It is my understanding that the all target already 
contains this functionality, perhaps this is just a matter 
of exposing it as another target.

  This is a nice to have but not absolutely necessary 
feature that I don't have time to implement myself.  
Thank you for taking the time to consider this request.

  - Matt Munz

  was:
SourceForge Submitter: mattmunz .
Hi,

  Sometimes a developer just wants to look at the 
javadocs / API documentation, but does not need to 
build the entire project.  It would be useful to have a 
build target like documentation, javadocs, or api-
documentation that generates this for the user.

  It is my understanding that the all target already 
contains this functionality, perhaps this is just a matter 
of exposing it as another target.

  This is a nice to have but not absolutely necessary 
feature that I don't have time to implement myself.  
Thank you for taking the time to consider this request.

  - Matt Munz

Environment: 

 build script needs a Javadoc Target
 ---

  Key: JBBUILD-18
  URL: http://jira.jboss.com/jira/browse/JBBUILD-18
  Project: JBoss Build System
 Type: Feature Request
 Reporter: SourceForge User



 SourceForge Submitter: mattmunz .
 Hi,
   Sometimes a developer just wants to look at the 
 javadocs / API documentation, but does not need to 
 build the entire project.  It would be useful to have a 
 build target like documentation, javadocs, or api-
 documentation that generates this for the user.
   It is my understanding that the all target already 
 contains this functionality, perhaps this is just a matter 
 of exposing it as another target.
   This is a nice to have but not absolutely necessary 
 feature that I don't have time to implement myself.  
 Thank you for taking the time to consider this request.
   - Matt Munz

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Moved: (JBBUILD-18) build script needs a Javadoc Target

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBBUILD-18?page=history ]

Scott M Stark moved JBAS-207 to JBBUILD-18:
---

Project: JBoss Build System  (was: JBoss Application Server)
Key: JBBUILD-18  (was: JBAS-207)

 build script needs a Javadoc Target
 ---

  Key: JBBUILD-18
  URL: http://jira.jboss.com/jira/browse/JBBUILD-18
  Project: JBoss Build System
 Type: Feature Request
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: mattmunz .
 Hi,
   Sometimes a developer just wants to look at the 
 javadocs / API documentation, but does not need to 
 build the entire project.  It would be useful to have a 
 build target like documentation, javadocs, or api-
 documentation that generates this for the user.
   It is my understanding that the all target already 
 contains this functionality, perhaps this is just a matter 
 of exposing it as another target.
   This is a nice to have but not absolutely necessary 
 feature that I don't have time to implement myself.  
 Thank you for taking the time to consider this request.
   - Matt Munz

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-231) Deployment fails if no env-entry-value

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-231?page=history ]
 
Scott M Stark closed JBAS-231:
--

Resolution: Out of Date

 Deployment fails if no env-entry-value
 --

  Key: JBAS-231
  URL: http://jira.jboss.com/jira/browse/JBAS-231
  Project: JBoss Application Server
 Type: Bug
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: fschoong .
 Win2k
 Java(TM) 2 Runtime Environment, Standard Edition 
 (build 1.3.1_04-b02)
 org.jboss.deployment.DeploymentException: Error in ejb-
 jar.xml for Session Bean
 MessageFacade: expected one env-entry-value tag
 at 
 org.jboss.metadata.ApplicationMetaData.importEjbJarXm
 l(ApplicationMetaData.java:207)
 I defined with a session bean with the following env-
 entry.  According to http://java.sun.com/j2ee/dtds/ejb-
 jar_1_1.dtd, env-entry-value is optional, it should not fail 
 if its not specified, or did i get it wrong???
 env-entry
 description![CDATA[Name of table that holds 
 the schema sequence number]]/description
 env-entry-namesequenceTableName/env-entry-
 name
 env-entry-typejava.lang.String/env-entry-type
 !--
 env-entry-valueoid/env-entry-value
  --
 /env-entry

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-243) Server.start() after Server.shutdown()

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-243?page=history ]
 
Scott M Stark closed JBAS-243:
--

 Resolution: Done
Fix Version: JBossAS-4.0.0 Final
  JBossAS-3.2.5 Final

 Server.start() after Server.shutdown()
 --

  Key: JBAS-243
  URL: http://jira.jboss.com/jira/browse/JBAS-243
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For: JBossAS-4.0.0 Final,  JBossAS-3.2.5 Final



 SourceForge Submitter: sven_luzar .
 I want to start and stop the JBoss server with my own 
 Main Class (without exiting the VM). Therefore I use 
 direct the ServerImpl class.
 But I can't restart the server after shutdown. The error 
 message is:
 java.lang.Error: factory already defined
 at java.net.URL.setURLStreamHandlerFactory
 (URL.java:1027)
 at org.jboss.system.server.ServerImpl.doInit
 (ServerImpl.java:150)
 at org.jboss.system.server.ServerImpl.init
 (ServerImpl.java:117)
 I think the problem can be solved by creating a try catch 
 block for the setURLStreamHanderFactory method in 
 the class ServerImpl at line 150.
 For tests you can use the attachment.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-285) INTERSECT-support

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-285?page=history ]

Scott M Stark updated JBAS-285:
---

  Assign To: Alexey Loubyansky  (was: Scott M Stark)
Description: 
SourceForge Submitter: mkotsbak .
which postgresql, oracle, DB2 and sql-92 (intermed
level) supports.

UNION and EXCEPT should also be supported.

  was:
SourceForge Submitter: mkotsbak .
which postgresql, oracle, DB2 and sql-92 (intermed
level) supports.

UNION and EXCEPT should also be supported.

Environment: 
   Priority: Minor  (was: Major)

 INTERSECT-support
 -

  Key: JBAS-285
  URL: http://jira.jboss.com/jira/browse/JBAS-285
  Project: JBoss Application Server
 Type: Feature Request
   Components: CMP service
 Versions: JBossAS-4.0.0 Final
 Reporter: SourceForge User
 Assignee: Alexey Loubyansky
 Priority: Minor



 SourceForge Submitter: mkotsbak .
 which postgresql, oracle, DB2 and sql-92 (intermed
 level) supports.
 UNION and EXCEPT should also be supported.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-265) exceptions from mbean-info-db-service

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-265?page=history ]
 
Scott M Stark closed JBAS-265:
--

Resolution: Out of Date

All jboss dtds are registered with a local resolver so as long as the doctype 
public id is correct this should not happen.

 exceptions from mbean-info-db-service
 -

  Key: JBAS-265
  URL: http://jira.jboss.com/jira/browse/JBAS-265
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-4.0.0 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: lafr .
 The deployment of mbean-info-db-service.xml gives me
 exceptions on startup of jboss-head.
 See attached extract from server.log.
 (JBoss-Head, current checkout, JDK 1.4.1 on Linux )

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1284) SOAP SAAJ JBOSS implementation attachments bug

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1284?page=history ]

Scott M Stark updated JBAS-1284:


Assign To: Jason T. Greene  (was: Scott M Stark)
 type: Feature Request  (was: Bug)
 Priority: Minor  (was: Major)

 SOAP SAAJ JBOSS implementation attachments bug
 --

  Key: JBAS-1284
  URL: http://jira.jboss.com/jira/browse/JBAS-1284
  Project: JBoss Application Server
 Type: Feature Request
   Components: Web Services service
 Versions: JBossAS-4.0.1 Final
  Environment: Windows-XP SP2
 Reporter: Frank Balba
 Assignee: Jason T. Greene
 Priority: Minor



 Using JBOSS-SAAJ implementation, no attachments could get through within a 
 SOAP message.
 Creating attachments and adding them to a SOAP message will result a fine 
 SOAP message on the client side however once it arrives to a dedicated 
 servlet the received attachmentpart returns 'null' for 
 attachmentPart.getContentType(). Using another SAAJ package (not the one 
 included with JBOSS 4.0.1) eliminates this problem.
 Frank

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBAS-1300) Non-Remote JMS HA

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1300?page=history ]

Scott M Stark updated JBAS-1300:


Assign To: (was: Scott M Stark)
 Priority: Minor  (was: Major)

 Non-Remote JMS HA
 -

  Key: JBAS-1300
  URL: http://jira.jboss.com/jira/browse/JBAS-1300
  Project: JBoss Application Server
 Type: Feature Request
   Components: JMS service
 Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
 Reporter: Andrew Oliver
 Priority: Minor


 Original Estimate: 1 week
 Remaining: 1 week

 It should be possible to use JMS on all servers in a cluster with HA enabled. 
  Meaning:
 1. Database as a store.  Everyone node uses shared DB.
 2. JMS_MESSAGES table includes node name
 3. In the event of group membership changes another node picks up the old 
 node's messages
 4. JMS Client proxy autofails to another node

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-783) UnifiedClassLoader3 is not threadsafe

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-783?page=history ]
 
Scott M Stark resolved JBAS-783:


Resolution: Deferred

There have been a number of fixes to the ucl layer since 3.2.2. If this is 
still a problem with more recent releases reopen with updated trace level 
logging.

 UnifiedClassLoader3 is not threadsafe
 -

  Key: JBAS-783
  URL: http://jira.jboss.com/jira/browse/JBAS-783
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: adrianprice .
 I'm getting an intermittent j.l.ClassCastException on the 
 dynamic proxy returned by JNDI lookup of an EJB local 
 home.  A single copy of the EJBLocalHome subinterface 
 in question is deployed in an ejb.jar inside an .ear with 
 an application-scoped ClassLoader.  No other copies of 
 the class file are deployed anywhere else.
 Application level debug output (attached) shows clearly 
 that the same application-scoped UnifiedClassLoader3 
 instance associated with the ear file has loaded the 
 same bytecode twice, into two distinct copies of the 
 same class, with the result that the dynamic proxy 
 implements a different copy of the home interface than 
 that which the calling code sees.  Hence the 
 ClassCastException.  Both copies of the class share the 
 same ClassLoader instance.
 This is JBoss-3.2.2, and I've seen the same problem on 
 both Linux and Windows XP.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-783) UnifiedClassLoader3 is not threadsafe

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-783?page=history ]
 
Scott M Stark closed JBAS-783:
--


 UnifiedClassLoader3 is not threadsafe
 -

  Key: JBAS-783
  URL: http://jira.jboss.com/jira/browse/JBAS-783
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: adrianprice .
 I'm getting an intermittent j.l.ClassCastException on the 
 dynamic proxy returned by JNDI lookup of an EJB local 
 home.  A single copy of the EJBLocalHome subinterface 
 in question is deployed in an ejb.jar inside an .ear with 
 an application-scoped ClassLoader.  No other copies of 
 the class file are deployed anywhere else.
 Application level debug output (attached) shows clearly 
 that the same application-scoped UnifiedClassLoader3 
 instance associated with the ear file has loaded the 
 same bytecode twice, into two distinct copies of the 
 same class, with the result that the dynamic proxy 
 implements a different copy of the home interface than 
 that which the calling code sees.  Hence the 
 ClassCastException.  Both copies of the class share the 
 same ClassLoader instance.
 This is JBoss-3.2.2, and I've seen the same problem on 
 both Linux and Windows XP.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-478) Loose soft ref thread in (jaws) JDBCCommandFactory

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-478?page=history ]
 
Scott M Stark closed JBAS-478:
--

 Assign To: Alexey Loubyansky  (was: Scott M Stark)
Resolution: Won't Fix

jaws has been deprecated since 3.0.x

 Loose soft ref thread in (jaws) JDBCCommandFactory
 --

  Key: JBAS-478
  URL: http://jira.jboss.com/jira/browse/JBAS-478
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Alexey Loubyansky



 SourceForge Submitter: rodburgett .
 The 
 org.jboss.ejb.plugins.jaws.jdbc.JDBCCommandFactory 
 class uses a static TimerQueue thread to manage soft 
 object references.  The thread is started upon 
 instantiation of the first factory and is not stopped until 
 the JVM goes down.  This creates a thread leak if JBoss 
 is stopped and restarted within a single JVM process.
 The attached diff file offers changes to the 
 JDBCCommandFactory to kill the thread when the last 
 factory is destroyed.
 This proposal represents a hack patch for JBoss 3.2.  A 
 better solution might involve more extensive refactoring 
 to turn the thread into a JBoss service to ensure proper 
 cleanup when JBoss is shutdown.
 If no further development is expected on JAWS, then 
 such refactoring may not be worthwhile.  Then a hack 
 patch may suffice to fix the bug until JAWS is replaced.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-456) Rollback on an Application Exception

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-456?page=history ]
 
Scott M Stark closed JBAS-456:
--

 Resolution: Done
Fix Version: JBossAS-4.0.0 Final
  JBossAS-3.2.5 Final

 Rollback on an Application Exception
 

  Key: JBAS-456
  URL: http://jira.jboss.com/jira/browse/JBAS-456
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For: JBossAS-4.0.0 Final,  JBossAS-3.2.5 Final



 SourceForge Submitter: ejort .
 According to EJB2.0 18.2.1/18.3.1
 setRollBack and throwing an application exception
 should not discard the entiity instance.
 See test 
 org.jboss.test.exeption.EntityExceptionUnitTestCase
 Regards,
 Adrian

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-437) URLDirectoryScanner does not respect dependencies?

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-437?page=history ]
 
Scott M Stark closed JBAS-437:
--

Resolution: Won't Fix

We don't support the URLDirectoryScanner and it should just be dropped.

 URLDirectoryScanner does not respect dependencies?
 --

  Key: JBAS-437
  URL: http://jira.jboss.com/jira/browse/JBAS-437
  Project: JBoss Application Server
 Type: Feature Request
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: ikar .
 I was trying to use JBoss.NET from 3.2RC4 and write
 some web service, and faced the following:
 I dropped the following components into deploy/ of the
 new configuration, and it worked right away:
 jbossweb.sar
 jmx-console.war
 jboss-net.sar
 URLDeploymentScanner works fine.
 Then I tried (for some reason) to switch to
 URLDirectoryScanner and specified the following:
url name=./deploy/jbossweb.sar/ /
url name=./deploy/jmx-console.war/ /
dir name=./deploy/jboss-net.sar/ /
 dir suggests that jboss-net should be scanned for
 nested deployments.
 However, in this case the nested .wsr archive doesn't
 get deployed - it says no deployer found...
 the same thing happens if just dir name=./deploy//
 is specified, which in my understanding is the same
 thing as just using URLDeploymentScanner

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-384) Memory leak in database access

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-384?page=history ]
 
Scott M Stark closed JBAS-384:
--

Resolution: Out of Date

The jca layer has been significatly updated since the 3.0.3 release.

 Memory leak in database access
 --

  Key: JBAS-384
  URL: http://jira.jboss.com/jira/browse/JBAS-384
  Project: JBoss Application Server
 Type: Bug
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: jstolze .
 Hello, I've discovered a memory leak in the Database 
 access part of JBoss. I have performed the following test.
 1. Request a database connection from the initial 
 context.
 2. Inserted, selected and deleted a record in a MSSQL 
 Server database via JDBC.
 3. close the connection.
 4 repeat endlessly.
 After about 3 million repetitions an OutOfMemoryError 
 occurs.
 I've started JBoss with a minimum and maximum heap 
 size of 20 MB. This means that JBoss had 5 MB op 
 heapspace free to perform the above test. I've measured 
 this by requesting the freeMemory on the VM. 
 I can exclude the MS SQLServer JDBC driver, because I 
 have tested it in a seperate java program that does the 
 exact same with the only difference that it doesn't use 
 connection pooling. No memory leak appeared then. 
 Another test I've performed is like the above, but I've only 
 requested a database connection once from the inital 
 context, no memory leak appeared. So I think it is in the 
 connection pooling part of JBoss.
 Config props are:
 JBoss 3.0.3
 JDK: Java(TM) 2 Runtime Environment, Standard Edition 
 (build 1.3.1_03-b03)
 Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed 
 mode)
 Platfrom: Windows 2000.
 JDBC Driver: MS SQL-Server JDBC driver

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-880) Tomcat5 - conflicting libraries

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-880?page=history ]
 
Scott M Stark closed JBAS-880:
--

 Resolution: Out of Date
Fix Version:  JBossAS-3.2.5 Final

Reopen with a more recent example as the tomcat deployer has been updated to 
better support scoped loading.

 Tomcat5 - conflicting libraries
 ---

  Key: JBAS-880
  URL: http://jira.jboss.com/jira/browse/JBAS-880
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For:  JBossAS-3.2.5 Final



 SourceForge Submitter: wonnekeysers .
 The following error occured while trying to deploy a .ear 
 with scoped classloading on JB3.2.4RC1.
 This ear-file contained an older version of the jakarta-
 digester than the one in jbossweb-tomcat50.sar 
 directory.
 When I removed the servlet-api.jar and jsp-api.jar from 
 jbossweb-tomcat50.sar, the exception disappeared.
 (These api's are still in the server lib folder named as 
 javax.servlet.jar and javax.servlet.jsp.jar)
 2004-02-12 19:39:18,168 DEBUG 
 [org.apache.struts.action.ActionServlet] Scanning 
 web.xml for controller servlet mapping
 2004-02-12 19:39:18,659 ERROR 
 [org.apache.commons.digester.Digester] End event 
 threw error
 java.lang.NoClassDefFoundError: 
 javax/servlet/http/HttpServletRequest
   at java.lang.Class.getDeclaredMethods0(Native 
 Method)
   at java.lang.Class.privateGetDeclaredMethods
 (Class.java:1647)
   at java.lang.Class.getMethod0(Class.java:1893)
   at java.lang.Class.getMethod0(Class.java:1902)
   at java.lang.Class.getMethod(Class.java:976)
   at 
 org.apache.commons.beanutils.MethodUtils.getMatchingA
 ccessibleMethod(MethodUtils.java:580)
   at 
 org.apache.commons.beanutils.MethodUtils.invokeMethod
 (MethodUtils.java:254)
   at 
 org.apache.commons.digester.CallMethodRule.end
 (CallMethodRule.java:506)
   at org.apache.commons.digester.Rule.end
 (Rule.java:276)
   at 
 org.apache.commons.digester.Digester.endElement
 (Digester.java:1077)
   at 
 org.apache.xerces.parsers.AbstractSAXParser.endElemen
 t(AbstractSAXParser.java:559)
   at 
 org.apache.xerces.impl.XMLNamespaceBinder.handleEndEl
 ement(XMLNamespaceBinder.java:853)
   at 
 org.apache.xerces.impl.XMLNamespaceBinder.endElement
 (XMLNamespaceBinder.java:643)
   at 
 org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndEl
 ement(XMLDTDValidator.java:2978)
   at 
 org.apache.xerces.impl.dtd.XMLDTDValidator.endElement
 (XMLDTDValidator.java:918)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerIm
 pl.handleEndElement
 (XMLDocumentFragmentScannerImpl.java:1145)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerIm
 pl.scanEndElement
 (XMLDocumentFragmentScannerImpl.java:988)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerIm
 pl$FragmentContentDispatcher.dispatch
 (XMLDocumentFragmentScannerImpl.java:1446)
   at 
 org.apache.xerces.impl.XMLDocumentFragmentScannerIm
 pl.scanDocument
 (XMLDocumentFragmentScannerImpl.java:333)
   at 
 org.apache.xerces.parsers.StandardParserConfiguration.p
 arse(StandardParserConfiguration.java:529)
   at 
 org.apache.xerces.parsers.StandardParserConfiguration.p
 arse(StandardParserConfiguration.java:585)
   at org.apache.xerces.parsers.XMLParser.parse
 (XMLParser.java:147)
   at 
 org.apache.xerces.parsers.AbstractSAXParser.parse
 (AbstractSAXParser.java:1148)
   at org.apache.commons.digester.Digester.parse
 (Digester.java:1597)
   at 
 org.apache.struts.action.ActionServlet.initServlet
 (ActionServlet.java:1130)
   at org.apache.struts.action.ActionServlet.init
 (ActionServlet.java:382)
   at 
 com.merck.genesys.framework.presentation.action.Stand
 ardActionServlet.init(StandardActionServlet.java:29)
   at javax.servlet.GenericServlet.init
 (GenericServlet.java:256)
   at 
 org.apache.catalina.core.StandardWrapper.loadServlet
 (StandardWrapper.java:1044)
   at 
 org.apache.catalina.core.StandardWrapper.load
 (StandardWrapper.java:887)
   at 
 org.apache.catalina.core.StandardContext.loadOnStartup
 (StandardContext.java:3960)
   at 
 org.apache.catalina.core.StandardContext.start
 (StandardContext.java:4283)
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal
 (ContainerBase.java:866)
   at 
 org.apache.catalina.core.ContainerBase.addChild
 (ContainerBase.java:850)
   at 
 org.apache.catalina.core.StandardHost.addChild
 (StandardHost.java:638)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke
 (NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke
 (Method.java:324)
   at 
 

[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-553) Drop table fails with fk-constraint

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-553?page=history ]

Scott M Stark reassigned JBAS-553:
--

Assign To: Alexey Loubyansky  (was: Scott M Stark)

Probably out of date but please verify.

 Drop table fails with fk-constraint
 ---

  Key: JBAS-553
  URL: http://jira.jboss.com/jira/browse/JBAS-553
  Project: JBoss Application Server
 Type: Bug
   Components: CMP service
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Alexey Loubyansky



 SourceForge Submitter: pilhuhn .
 When you have two tables a,b
 where b has a fk-constraint on a.field, 
 dropping table a before table b fails.
 JBossCMP unfortunately does not take those fk
 constraints into account when dropping EntityBeans/Tables. 
 So when the container first drops b, everything is ok,
 but if it first tries to drop a, this fails while b
 will be dropped afterwards.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-879) Deploy undeploy of war deleted my war file

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-879?page=history ]
 
Scott M Stark closed JBAS-879:
--

Resolution: Rejected

That is the expected behavior. What is the problem with this?

 Deploy undeploy of war deleted my war file
 --

  Key: JBAS-879
  URL: http://jira.jboss.com/jira/browse/JBAS-879
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: shyamvs .
 I deployed a war through main deployer by deploy(url)
 method.
 The war was in a different location of that of jboss.
 After deploy the war was unpacked in that directory
 itself and during  undeploy it deleted that extacted
 war directory and also i dont' find my packed war file
 there.
 Using jboss-3-2-3 tomcat-4-1-*
 OS linux RH 8.0  2.4.18-14
 jdk k2sdk1.4.2_03

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-708) loading resources through classloader (in ConnectionFactory)

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-708?page=history ]
 
Scott M Stark closed JBAS-708:
--

Resolution: Done

 loading resources through classloader (in ConnectionFactory)
 

  Key: JBAS-708
  URL: http://jira.jboss.com/jira/browse/JBAS-708
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: ethanocentrism .
 I have the following situation (in JBoss 3.2.1):
   -  Package com.x.y deployed in a jar that is loaded 
 based on /server/default/conf/jboss-service.xml
   -  Either a jar file or a subfolder 
 in /server/default/deploy/ that defines a connection 
 factory configuration of a resource adapter already 
 deployed in a .rar.  The jar or subfolder contains:
   1. A connection factory configuration  (-ds.xml).
   2. Resource files with directory path in the jar or 
 subfolder that mirrors the package path in the other jar 
 (com/x/y).  The connection factory configuration 
 refers to these resources (com/x/y/MyResource.file).
 The ManagedConnectionFactory for the connection 
 factory attempts to load these resources through a 
 ClassLoader obtained by getClass().getClassLoader()
 (which returns a UnifiedClassLoader3).  The class loader 
 does not find the resources.
 However, if I move the resources to a different directory 
 that doesn't mirror the package already loaded and 
 change the configuration file accordingly to refer to 
 resources in this new directory, then the class loader 
 does find the resources.
 (For example, I had no problems with the resources 
 in WORKAROUND_DIRECTORY/com/x/y.)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-833) wrong tmp dir for JSP compiling

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-833?page=history ]
 
Scott M Stark closed JBAS-833:
--

 Resolution: Done
Fix Version:  JBossAS-3.2.5 Final

tomcat uses the server/xxx/work directory for jsp output by default.

 wrong tmp dir for JSP compiling
 ---

  Key: JBAS-833
  URL: http://jira.jboss.com/jira/browse/JBAS-833
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark
  Fix For:  JBossAS-3.2.5 Final



 SourceForge Submitter: luwasoft .
 With Jboss 3.2.3 (and other 3.2 versions before) on
 LINUX (JDK 1.4.2) in a production environment it seems
 to be the case, that the buildtin tomcat does not use
 the %JBOSS_HOME/server/*/tmp directory for temporary
 files while compiling JSP's.
 Instead it seems to use the working dir set before
 Jboss start.
 In a production environment, where the user running
 JBOSS has only write access to */tmp, */work, */log and
 */data JBOSS has to be started with:
 # cd $JBOSS_HOME/server/*/tmp
 # su wwwrun -c $JBOSS_HOME/bin/run.sh
 otherwise JSP compiling will fail because of missing
 file create/write permissions.
 This is not that primary problem, but i think it should
 be fixed anyway.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Moved: (JBIDE-123) Eclipse Find install - cannot recognize AOP plugin

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBIDE-123?page=history ]

Scott M Stark moved JBAS-1167 to JBIDE-123:
---

   Project: JBoss IDE  (was: JBoss Application Server)
   Key: JBIDE-123  (was: JBAS-1167)
Issue Type: Feature Request  (was: Bug)
 Component: AOP Plugin
Security Level: (was: Public)

 Eclipse Find  install - cannot recognize AOP plugin
 

  Key: JBIDE-123
  URL: http://jira.jboss.com/jira/browse/JBIDE-123
  Project: JBoss IDE
 Type: Feature Request
   Components: AOP Plugin
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: jerarckill .
 I have installed org.jboss.ide.eclipse_1.4.0.bin.dist 
 packaged plugin for eclpise 3.0.1 and it works perfectly.
 Just after, i tried to install the jbosside-aop-1.0.1 
 packaged plugin (through the find  install link 
 in eclipse).
 Eclipse says selected location does not contain an 
 update site.  please select another location.
 Is it normal that this is not working?  Do we have to 
 install it directly by copying it in the eclipse plugin 
 directory? do we have to install another AOP package 
 before (1.0.0)?
 well, don't know if this one is really a bug though...
 // 
 // config
 // 
 Windows XP pro - english SP1
 JAVA 1.4.2
 Thank you in advance,
 Jerarckill

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Updated: (JBIDE-123) Eclipse Find install - cannot recognize AOP plugin

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBIDE-123?page=history ]

Scott M Stark updated JBIDE-123:


  Assign To: (was: Scott M Stark)
Description: 
SourceForge Submitter: jerarckill .
I have installed org.jboss.ide.eclipse_1.4.0.bin.dist 
packaged plugin for eclpise 3.0.1 and it works perfectly.

Just after, i tried to install the jbosside-aop-1.0.1 
packaged plugin (through the find  install link 
in eclipse).

Eclipse says selected location does not contain an 
update site.  please select another location.

Is it normal that this is not working?  Do we have to 
install it directly by copying it in the eclipse plugin 
directory? do we have to install another AOP package 
before (1.0.0)?

well, don't know if this one is really a bug though...

// 
// config
// 
Windows XP pro - english SP1
JAVA 1.4.2

Thank you in advance,

Jerarckill

  was:
SourceForge Submitter: jerarckill .
I have installed org.jboss.ide.eclipse_1.4.0.bin.dist 
packaged plugin for eclpise 3.0.1 and it works perfectly.

Just after, i tried to install the jbosside-aop-1.0.1 
packaged plugin (through the find  install link 
in eclipse).

Eclipse says selected location does not contain an 
update site.  please select another location.

Is it normal that this is not working?  Do we have to 
install it directly by copying it in the eclipse plugin 
directory? do we have to install another AOP package 
before (1.0.0)?

well, don't know if this one is really a bug though...

// 
// config
// 
Windows XP pro - english SP1
JAVA 1.4.2

Thank you in advance,

Jerarckill

Environment: 

 Eclipse Find  install - cannot recognize AOP plugin
 

  Key: JBIDE-123
  URL: http://jira.jboss.com/jira/browse/JBIDE-123
  Project: JBoss IDE
 Type: Feature Request
   Components: AOP Plugin
 Reporter: SourceForge User



 SourceForge Submitter: jerarckill .
 I have installed org.jboss.ide.eclipse_1.4.0.bin.dist 
 packaged plugin for eclpise 3.0.1 and it works perfectly.
 Just after, i tried to install the jbosside-aop-1.0.1 
 packaged plugin (through the find  install link 
 in eclipse).
 Eclipse says selected location does not contain an 
 update site.  please select another location.
 Is it normal that this is not working?  Do we have to 
 install it directly by copying it in the eclipse plugin 
 directory? do we have to install another AOP package 
 before (1.0.0)?
 well, don't know if this one is really a bug though...
 // 
 // config
 // 
 Windows XP pro - english SP1
 JAVA 1.4.2
 Thank you in advance,
 Jerarckill

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1053) conf/web.xml gets truncated

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1053?page=history ]
 
Scott M Stark closed JBAS-1053:
---

Resolution: Cannot Reproduce Bug

Reopen if this is still an issue as I can't reproduce it.

 conf/web.xml gets truncated
 ---

  Key: JBAS-1053
  URL: http://jira.jboss.com/jira/browse/JBAS-1053
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: bwallis42 .
 OS: Gentoo Linux, (kernel 2.6.7 and glibc 2.3.3) 
 also on Solaris 8. 
 JDK: 1.4.2_05 and 1.4.2_01  
  
 When I start JBoss with the classpath including the conf 
 directory where the web.xml file is, the web.xml file gets 
 truncated.  
  
 This didn't happen in JBoss 3.2.1 but does in 3.2.3. 
  
 Workaround is to either write protect web.xml (and then 
 it works fine, no errors either) or remove the conf 
 directory from the classpath. 
  
 See the thread in the forums for details, I've copied part 
 of that discussion here which describes the problem and 
 tries to point to where it might be occuring.  
  
 http://jboss.org/index.html?module=bbop=viewtopict=52741 
  
 -- 
 OK, found what it is in our configuration that causes 
 web.xml to be overwritten.  
   
 For a reason that I cannot quite remember we have 
 always had the server conf directory on our classpath 
 when jboss starts up, something to do with using 
 ClassLoader.getResource() for properties I think, anyway 
 we don't use that anymore. Also when we changed from 
 3.2.1 to 3.2.3 we also changed from jetty to tomcat.  
   
 If I take the conf directory off the classpath then the 
 web.xml file is not truncated, although it's last modified 
 time is still updated.  
   
 On a Solaris system I launched the JVM with truss and 
 then matched up the tracing in the JBoss log with the 
 truss output and found the following. (the first log shown 
 at the end is the jboss log followed with the truss log)  
   
 The first JBoss timestamp at 2004-08-10 14:37:35,460 
 corresponds to a time of 123.4634 in the truss log and 
 the last JBoss timestamp is a time of 123.5674 in the 
 truss log so the jboss tracing overlaps the two truss 
 entries shown.  
   
 Notice that the second open call in the truss log has flags 
 O_CREATE|O_TRUNC which is going to do exactly that, 
 truncate the web.xml file. This second open call fits into 
 the time between the last two jboss log entries shown 
 which seem to be in the UnifiedClassLoader3.  
   
 That's about as far as I can go as I don't know this area 
 of the JBoss code at all.  
   
 Is this a bug I should report? The work around is simple, 
 don't put the conf dir on your classpath :-)  
   
   
 jboss log:  
 ==  
 2004-08-10 14:37:35,460 TRACE 
 [org.jboss.mx.loading.UnifiedClassLoader] 
 getResourceLocally([EMAIL PROTECTED] 
 url=file:/vobs/NotificationSer  
 vice_build/JAVA_dbg/run/NS_EFD/jboss/deploy/jbossweb-tomcat41.sar/ 
 ,addedOrder=11}), name=web.xml, 
 resURL:file:/vobs/NotificationService_build/JAVA_dbg/run/NS_EFD/jboss/co  
 nf/web.xml  
 2004-08-10 14:37:35,464 TRACE 
 [org.jboss.mx.loading.UnifiedClassLoader3] attempt(1) 
 was: true for 
 :[EMAIL PROTECTED] 
 url=file:/vobs/Notific  
 ationService_build/JAVA_dbg/run/NS_EFD/jboss/deploy/jbossweb-tomcat41.sar/ 
 ,addedOrder=11}  
 2004-08-10 14:37:35,465 TRACE 
 [org.jboss.mx.loading.LoadMgr3] registerLoaderThread, 
 [EMAIL PROTECTED] 
 url=file:/vobs/NotificationServic  
 e_build/JAVA_dbg/run/NS_EFD/jboss/deploy/jbossweb-tomcat41.sar/ 
 ,addedOrder=11}, t=Thread[main,5,jboss], prevT=null  
 2004-08-10 14:37:35,467 TRACE 
 [org.jboss.mx.loading.LoadMgr3] Begin beginLoadTask, 
 [EMAIL PROTECTED]: 
 java.io.FileOutputStream, r  
 equestingThread: Thread[main,5,jboss], 
 requestingClassLoader: 
 [EMAIL PROTECTED] 
 url=file:/vobs/NotificationService_build/JAVA_dbg/run/NS_EF  
 D/jboss/deploy/jbossweb-tomcat41.sar/ 
 ,addedOrder=11}, loadedClass: null, loadOrder: 
 2147483647, loadException: null, threadTaskCount: 0, 
 state: 0}  
 2004-08-10 14:37:35,468 TRACE 
 [org.jboss.mx.loading.UnifiedClassLoader] 
 loadClassLocally, name=java.io.FileOutputStream  
 2004-08-10 14:37:35,469 TRACE 
 [org.jboss.mx.loading.UnifiedLoaderRepository3] 
 cacheLoadedClass, classname: 
 java.io.FileOutputStream, class: class 
 java.io.FileOutputStream,  
  ucl: 
 [EMAIL PROTECTED] 
 url=file:/vobs/NotificationService_build/JAVA_dbg/run/NS_EFD/jboss/deploy/jbossweb-tomcat41.sar/
  
 ,addedOrder=11}  
 2004-08-10 14:37:35,470 TRACE 
 [org.jboss.mx.loading.LoadMgr3] End beginLoadTask, 
 loadClassFromClassLoader  
 2004-08-10 14:37:35,472 TRACE 
 [org.jboss.mx.loading.LoadMgr3] Begin endLoadTask, 
 [EMAIL PROTECTED]: 
 java.io.FileOutputStream, req  
 uestingThread: Thread[main,5,jboss], 
 requestingClassLoader: 
 [EMAIL PROTECTED] 
 

[JBoss-dev] [JBoss JIRA] Closed: (JBAS-844) Search form

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-844?page=history ]
 
Scott M Stark closed JBAS-844:
--

Resolution: Done

 Search form
 ---

  Key: JBAS-844
  URL: http://jira.jboss.com/jira/browse/JBAS-844
  Project: JBoss Application Server
 Type: Feature Request
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: elfring .
 Please add a search engine to your web site.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1182) Thread creation during deactivate_object

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1182?page=history ]

Scott M Stark reassigned JBAS-1182:
---

Assign To: Francisco Reverbel  (was: Scott M Stark)

 Thread creation during deactivate_object
 

  Key: JBAS-1182
  URL: http://jira.jboss.com/jira/browse/JBAS-1182
  Project: JBoss Application Server
 Type: Bug
   Components: IIOP service
 Reporter: SourceForge User
 Assignee: Francisco Reverbel



 SourceForge Submitter: kevinconner .
 This is a duplicate of bug 527 in the JacORB database.
  It is being submitted here so that a patch may be
 applied to the JBoss patched version of JacORB.
 http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
 The deactiviation of an object causes Thread creation
 in AOM.remove.  Would it
 be possible to use a thread pool instead of creating
 new threads?
 A possible solution could be to have the
 RequestController provide a
 notification mechanism (instead of a thread waiting on
 object completion) and
 have the notification request work from the thread pool.
 The attached patch uses a threadpool to prevent the
 thread creation but I don't
 believe it is the best solution.
 Index: AOM.java
 ===
 RCS file:
 /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
 retrieving revision 1.29
 diff -u -r1.29 AOM.java
 --- AOM.java  6 May 2004 12:40:00 -   1.29
 +++ AOM.java  21 Oct 2004 14:38:11 -
 @@ -27,6 +27,9 @@
  import org.jacorb.poa.util.ByteArrayKey;
  import org.jacorb.poa.util.POAUtil;
  import org.jacorb.poa.util.StringPair;
 +import org.jacorb.util.threadpool.Consumer;
 +import org.jacorb.util.threadpool.ConsumerFactory;
 +import org.jacorb.util.threadpool.ThreadPool;
  
  import
 org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
  import org.omg.PortableServer.POAPackage.ObjectNotActive;
 @@ -69,6 +72,23 @@
  /** a lock to protect two consecutive operations
 on the list, used
  in remove() */
  private Object  deactivationListLock =
 new Object();
 +
 +private Consumer deactivationConsumer = new
 Consumer() {
 +public void doWork(final Object job) {
 +try {
 +((Runnable)job).run() ;
 +} catch (final Throwable th) {
 +logger.info(Unhandled exception
 during deactivation, th);
 +}
 +} 
 +} ;
 +private ConsumerFactory
 deactivationConsumerFactory = new ConsumerFactory() {
 +public Consumer create() {
 +return deactivationConsumer ;
 +}
 +} ;
 +
 +private ThreadPool deactivationPool = new
 ThreadPool(deactivationConsumerFactory) ;
  
  private AOM()
  {
 @@ -348,8 +368,7 @@
  final POA poa_ = poa;
  final boolean cleanupInProgress_ =
 cleanupInProgress;
  
 -Thread thread = new Thread(AOM_RemovalThread)
 -{
 +final Runnable job = new Runnable() {
  public void run()
  {
  _remove(
 @@ -361,8 +380,8 @@
 );
  }
  };
 -
 -thread.start();
 +
 +deactivationPool.putJob(job) ;
  }

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1298) HAR Deployer JBCache config

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1298?page=history ]

Scott M Stark reassigned JBAS-1298:
---

Assign To: Steve Ebersole  (was: Scott M Stark)

 HAR Deployer  JBCache config
 

  Key: JBAS-1298
  URL: http://jira.jboss.com/jira/browse/JBAS-1298
  Project: JBoss Application Server
 Type: Feature Request
   Components: Hibernate service
 Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
 Reporter: Andrew Oliver
 Assignee: Steve Ebersole


 Original Estimate: 6 hours
 Remaining: 6 hours

 Presently HAR deployer picks up JBCache config from its classloader.  It does 
 not use an MBean.  It should use an MBean (and we should be able to get stats 
 from it).  

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-776) NoInitialContextException after x redeployments

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-776?page=history ]
 
Scott M Stark closed JBAS-776:
--

Resolution: Cannot Reproduce Bug

 NoInitialContextException after x redeployments
 ---

  Key: JBAS-776
  URL: http://jira.jboss.com/jira/browse/JBAS-776
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: wonnekeysers .
 Following exception occurs during hot redeployment 
 of .ear.
 JBoss 3.2.1 runs well for about a week.
 Hot (re)deployments occur regularly.
 After reboot, identical server config + apps run again as 
 expected.
 2003-11-06 15:40:47,171 WARN  
 [org.jboss.system.ServiceController] Problem starting 
 service 
 jboss.j2ee:jndiName=genesys/tangram/Affiliation,service=
 EJB
 javax.naming.NoInitialContextException: Need to specify 
 class name in environment or system property, or as an 
 applet parameter, or in an application resource file:  
 java.naming.factory.initial
 cut/
 2003-11-06 15:40:47,276 WARN  
 [org.jboss.jetty.JettyService] Failed to parse descriptors 
 for war(file:/usr/local/gsys/java/jboss/jboss-
 3.2.1/server/production/tmp/deploy/server/production/de
 ploy/gsys/TGSWE_Adapter.ear/67.TGSWE_Adapter.ear-
 contents/TGSWE_Adapter.war)
 java.io.FileNotFoundException: /usr/local/gsys/java/jboss
 /jboss-
 3.2.1/server/production/tmp/deploy/server/production/de
 ploy/gsys/TGSWE_Adapter.ear/67.TGSWE_Adapter.ear-
 contents/TGSWE_Adapter.war (Too many open files)
 2003-11-06 15:40:47,338 INFO  [org.jboss.jbossweb] 
 Registered 
 jboss.web:Jetty=0,JBossWebApplicationContext=41,cont
 ext=/TGSWE_Adapter
 2003-11-06 15:40:47,358 ERROR [org.jboss.jbossweb] 
 java.io.IOException: Too many open files
   at java.io.UnixFileSystem.createFileExclusively
 (Native Method)
   at java.io.File.checkAndCreate(File.java:1333)
   at java.io.File.createTempFile(File.java:1421)
   at java.io.File.createTempFile(File.java:1458)
   at 
 org.mortbay.http.HttpContext.getTempDirectory
 (HttpContext.java:1195)
   at 
 org.mortbay.jetty.servlet.WebApplicationContext.resolve
 WebApp(WebApplicationContext.java:222)
   at 
 org.mortbay.jetty.servlet.WebApplicationContext.start
 (WebApplicationContext.java:335)
   at 
 org.mortbay.j2ee.J2EEWebApplicationContext.start
 (J2EEWebApplicationContext.java:85)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Commented: (JBAS-1278) session variables are shared between different sessions

2005-02-23 Thread Scott M Stark (JIRA)
 [ 
http://jira.jboss.com/jira/browse/JBAS-1278?page=comments#action_12315669 ]
 
Scott M Stark commented on JBAS-1278:
-

Logging into an app is not sufficient. We need a testcase that illustrates the 
problem.

 session variables are shared between different sessions
 ---

  Key: JBAS-1278
  URL: http://jira.jboss.com/jira/browse/JBAS-1278
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
  Environment: windows xp professional
 Reporter: mona aziz
 Assignee: Scott M Stark



 J2EE web applications using XSL and XML, and apache's tag libs running on 
 Jboss v3.2.2 and v3.2.3 or Tomcat 5 share session variables between different 
 sessions. 
 ie. if we have 2 users, user A and user B browsing the app at the same time, 
 but each is in a different location, user A can see the data that user B 
 entered in page 1 when user B is in page 2 (when the data is saved in the 
 session), and user A refreshes page 1.
 This problem doesn't occur whith the same J2EE app using the same tag libs 
 runing on sun one app server.
 This problem doesn't happen either if the deployed application is not using 
 XSL and XML. 
 NOTE
 This application gives errors during deployment when deployed on any later 
 JBoss AS version.(although i'm using the latest release of apache's tab libs)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-901) setting unpackWars as false didn't work

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-901?page=history ]

Scott M Stark reassigned JBAS-901:
--

Assign To: Remy Maucherat  (was: Scott M Stark)

Seems out of date but should verify.

 setting unpackWars as false didn't work
 ---

  Key: JBAS-901
  URL: http://jira.jboss.com/jira/browse/JBAS-901
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
 Versions: JBossAS-3.2.6 Final
 Reporter: SourceForge User
 Assignee: Remy Maucherat



 SourceForge Submitter: shyamvs .
 using jboss 323 release version jdk 1.4.2_03 linux RH
 8.0 2.4.18-14
 When I set the unpackWars flag as false then i get a
 ClassNotFoundException. When is set true I am not
 getting this exception.
 10:43:37:929]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|: Test
 Print=unpack wars==false|
 [10:43:38:345]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:38,282 INFO  [EmbeddedTomcatService] deploy,
 ctxPath=/servervm-test,
 warUrl=file:/advent1/reg/WebNMS5_Test_ant1.6/build/servervm-test.war
 |
 [10:43:39:281]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,266 INFO  [Engine]
 SingleSignOnContextConfig[/servervm-test]: Added
 certificates - request attribute Valve
 |
 [10:43:39:384]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,299 WARN  [EmbeddedTomcatService] Unable to
 invoke setDelegate on class
 loader:[EMAIL PROTECTED]
 |
 [10:43:39:385]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,299 INFO  [Engine]
 StandardManager[/servervm-test]: Seeding random number
 generator class java.security.SecureRandom
 |
 [10:43:39:385]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,300 INFO  [Engine]
 StandardManager[/servervm-test]: Seeding of random
 number generator has been completed
 |
 [10:43:39:385]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,301 INFO  [Engine]
 StandardWrapper[/servervm-test:default]: Loading
 container servlet default
 |
 [10:43:39:386]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,301 INFO  [Engine]
 StandardWrapper[/servervm-test:invoker]: Loading
 container servlet invoker
 |
 [10:43:39:489]|[03-01-2004]|[SYSOUT]|[INFO]|[13]|:
 10:43:39,388 INFO  [MainDeployer] Deployed package:
 file:/advent1/reg/WebNMS5_Test_ant1.6/build/servervm-test.war
 |
 [10:43:39:837]|[03-01-2004]|[SYSOUT]|[INFO]|[14]|:
 10:43:39,748 INFO  [Engine]
 StandardWrapper[/servervm-test:JUnitEETestServlet]:
 Marking servlet JUnitEETestServlet as unavailable
 |
 [10:43:39:838]|[03-01-2004]|[SYSOUT]|[INFO]|[14]|:
 10:43:39,751 ERROR [Engine]
 StandardWrapperValve[JUnitEETestServlet]: Allocate
 exception for servlet JUnitEETestServlet
 javax.servlet.ServletException: Wrapper cannot find
 servlet class org.junitee.servlet.JUnitEEServlet or a
 class it depends on
 at
 org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:891)
 at
 org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
 at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
 at
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
 at
 org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:220)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
 at
 org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
 at
 org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invoke(ContainerStatsValve.java:76)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
 at
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
 org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
 at
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
 at
 org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
 at
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
 at
 

[JBoss-dev] [JBoss JIRA] Resolved: (JBAS-1278) session variables are shared between different sessions

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1278?page=history ]
 
Scott M Stark resolved JBAS-1278:
-

Resolution: Deferred

 session variables are shared between different sessions
 ---

  Key: JBAS-1278
  URL: http://jira.jboss.com/jira/browse/JBAS-1278
  Project: JBoss Application Server
 Type: Bug
   Components: Web (Tomcat) service
  Environment: windows xp professional
 Reporter: mona aziz
 Assignee: Scott M Stark



 J2EE web applications using XSL and XML, and apache's tag libs running on 
 Jboss v3.2.2 and v3.2.3 or Tomcat 5 share session variables between different 
 sessions. 
 ie. if we have 2 users, user A and user B browsing the app at the same time, 
 but each is in a different location, user A can see the data that user B 
 entered in page 1 when user B is in page 2 (when the data is saved in the 
 session), and user A refreshes page 1.
 This problem doesn't occur whith the same J2EE app using the same tag libs 
 runing on sun one app server.
 This problem doesn't happen either if the deployed application is not using 
 XSL and XML. 
 NOTE
 This application gives errors during deployment when deployed on any later 
 JBoss AS version.(although i'm using the latest release of apache's tab libs)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1366) Alter table throws Exception when using with mysql and postgresql

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1366?page=history ]

Scott M Stark reassigned JBAS-1366:
---

Assign To: Alexey Loubyansky  (was: Scott M Stark)

 Alter table throws Exception when using with mysql and postgresql
 -

  Key: JBAS-1366
  URL: http://jira.jboss.com/jira/browse/JBAS-1366
  Project: JBoss Application Server
 Type: Patch
   Components: CMP service
 Versions: JBossAS-4.0.1 Final
  Environment: Windows XP
 Reporter: Richard C. L. Li
 Assignee: Alexey Loubyansky
  Attachments: JDBCStartCommand.java

 Original Estimate: 0 minutes
 Remaining: 0 minutes

 I tried to use the following options in CMP deployment:
 create-tabletrue/create-table
 alter-tabletrue/alter-table
 The deployment is deployed to:
 JBoss 4.0.1 + MySQL 4.x + WindowsXP
 I found that the app server generates an exception and
 the CMP Entity Beans cannot be deployed. The exception
 is caused by the SQL that trying to add a column to an
 existing column.
 Finally I figure out in the docs that the alter table
 feature compares column names in uppercases so that the
 lower case column names in default mapping cause trouble.
 I tried to dig into the source codes and figure the
 comparison is made to DB column names and uppercased
 column names. I just wonder why not compare both names
 in uppercase, but only one in uppercase and the other not?
 I already make a patch for myself which make both names
 to uppercase before comparison.
 During the investigation on this issue, I also found that
 the code may throw a null pointer exception when checking to
 add an index to a CMR-field.
 I have already make a patch.

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-310) Control time ejbStore

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-310?page=history ]
 
Scott M Stark closed JBAS-310:
--

  Assign To: Alexey Loubyansky  (was: Scott M Stark)
 Resolution: Done
Fix Version: JBossAS-3.2.6 Final
 JBossAS-4.0.0 Final

 Control time ejbStore
 -

  Key: JBAS-310
  URL: http://jira.jboss.com/jira/browse/JBAS-310
  Project: JBoss Application Server
 Type: Feature Request
   Components: CMP service
 Versions: JBossAS-4.0.0 Final
 Reporter: SourceForge User
 Assignee: Alexey Loubyansky
  Fix For: JBossAS-3.2.6 Final, JBossAS-4.0.0 Final



 SourceForge Submitter: alvaromota .
 I thing that is usual insert  element  to specify the
 precise time at which a new bean that uses RDBMS CMP is
 inserted into
 the database.  By default, the database insert is done
 after
 ejbPostCreate.
 For maximum flexibility, developers should avoid
 creating related
 beans in their ejbPostCreate method.  This may make
 delaying the
 database insert impossible if database constraints
 prevent related
 beans from referring to a bean that has not yet been
 created.
 This is useful when we need to create a child entity
 from inside the
 ejbPostCreate method of a parent entity. The
 foreign-key field on the
 child??s table will try to match an existing key on the
 parent, but since it
 has not been persisted, a violation error will occur.
 To avoid that, and
 still use the foreign-key constraint in the child??s
 table, we use the
 ejbCreate or commit value on the tag in the parent
 bean??s descriptor.
 Thanks
 Alvaro Mota Gon??alves

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Assigned: (JBAS-1263) EJB-QL for IS EMPTY on relation table uses wrong column and is broken in general

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1263?page=history ]

Scott M Stark reassigned JBAS-1263:
---

Assign To: Alexey Loubyansky  (was: Scott M Stark)

 EJB-QL for IS EMPTY on relation table uses wrong column and is broken in 
 general
 --

  Key: JBAS-1263
  URL: http://jira.jboss.com/jira/browse/JBAS-1263
  Project: JBoss Application Server
 Type: Bug
   Components: CMP service
 Versions: JBossAS-4.0.1 Final, JBossAS-4.0.0 Final
  Environment: JDK 1.5.0, Windows XP+SP2, MySQL, Connector/J 3.1.6
 Reporter: cgs
 Assignee: Alexey Loubyansky



 TemplateEJB:
  * @ejb.finder
  * signature=java.util.Collection findPublic()
  * query=SELECT DISTINCT OBJECT(o)
  * FROM template o
  * WHERE o.organizationList IS EMPTY
 /**
  * @ejb.interface-method
  * 
  * @ejb.relation
  * name=Organization-Template
  * role-name=template-belongs-to-organization
  * 
  * @jboss.relation
  * fk-constraint=true
  * fk-column=organization_id
  * related-pk-field=id
  * 
  * @jboss.relation-table
  * table-name=template_to_organization
  */
 public abstract Set getOrganizationList();
 public abstract void setOrganizationList(Set organizationList);
 OrganizationEJB:
 /**
  * @ejb.interface-method
  * 
  * @ejb.relation
  * name=Organization-Template
  * role-name=organization-has-templates
  * 
  * @jboss.relation
  * fk-constraint=true
  * fk-column=template_id
  * related-pk-field=id
  * 
  * @jboss.relation-table
  * table-name=template_to_organization
  */
 public abstract Set getTemplateList();
 public abstract void setTemplateList(Set templateList);
 The SQL that is generated for the finder is:
 SELECT DISTINCT
 t0_o.id, t0_o.image, t0_o.image_thumbnail, t0_o.image_thumbnail_type,
 t0_o.image_type, t0_o.name, t0_o.template, t0_o.time_created,
 t0_o.time_updated, t0_o.uuid
 FROM
 template t0_o,
 organization t2_o_organizationList,
 template_to_organization t1_o_organizationList_RELATION_T
 WHERE (
 t1_o_organizationList_RELATION_T.template_id IS NULL AND
 t0_o.id=t1_o_organizationList_RELATION_T.template_id AND
 t2_o_organizationList.id=t1_o_organizationList_RELATION_T.organization_id
 )
 The first condition shouldn't be checking if ``template_id IS NULL'', but 
 ``organization_id IS NULL''.  Even if it properly checked organization_id, 
 the query still would not work.  If a relation using a relation table has an 
 empty list, the second condition is never matched.  The list is always empty 
 and it cannot proceed.  (t1_o_organizationList_RELATION_T.template_id will 
 never have any values in an empty relation.)

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1247) EJB container errors

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1247?page=history ]
 
Scott M Stark closed JBAS-1247:
---

Resolution: Incomplete Description

 EJB container errors
 

  Key: JBAS-1247
  URL: http://jira.jboss.com/jira/browse/JBAS-1247
  Project: JBoss Application Server
 Type: Bug
 Versions: JBossAS-4.0.0 Final
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: wei_jiang .
 Hi,
 I report potential three bugs about ejb container.
 The third bug is not related with the first two.
 Environemnt: Windows XP. Both jboss 3.2.6 and jboss
 4.0.0. Configuration: all.
 1. Ejb container should never say: 
   java.lang.NoClassDefFoundError: javax/ejb/EJBException
 2. the ejb was deployed successfully. The ejb call a
 library
 which is specified when server starts:
   run -C d:\jboss326\acelet -c all
 The error occurred when the ejb is called. 
 But it seems the ejb container does not looks for that
 classpath (bootstrap classpath).
 3. stateful session bean passivation is implemented 
 incorrectly: jdbcConnection is not serializable.
 
 d:\jboss400\binrun -C d:\jboss326\acelet -c all
 ===
 .
   JBoss Bootstrap Environment
 .
   JBOSS_HOME: d:\jboss400\bin\\..
 .
   JAVA: d:\j2sdk1.4.2_06\bin\java
 .
   JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m
 .
   CLASSPATH:
 d:\j2sdk1.4.2_06\lib\tools.jar;d:\jboss400\bin\\run.jar
 .
 ===
 .
 14:59:03,203 INFO  [Server] Starting JBoss (MX
 MicroKernel)...
 14:59:03,203 INFO  [Server] Release ID: JBoss [Zion]
 4.0.0 (build: CVSTag=JBoss_4_0_0 date=200409200
 418)
 14:59:03,203 INFO  [Server] Home Dir: D:\jboss400
 14:59:03,203 INFO  [Server] Home URL: file:/D:/jboss400/
 14:59:03,203 INFO  [Server] Library URL:
 file:/D:/jboss400/lib/
 14:59:03,203 INFO  [Server] Patch URL: null
 14:59:03,203 INFO  [Server] Server Name: all
 14:59:03,203 INFO  [Server] Server Home Dir:
 D:\jboss400\server\all
 14:59:03,203 INFO  [Server] Server Home URL:
 file:/D:/jboss400/server/all/
 14:59:03,203 INFO  [Server] Server Data Dir:
 D:\jboss400\server\all\data
 14:59:03,203 INFO  [Server] Server Temp Dir:
 D:\jboss400\server\all\tmp
 14:59:03,218 INFO  [Server] Server Config URL:
 file:/D:/jboss400/server/all/conf/
 14:59:03,218 INFO  [Server] Server Library URL:
 file:/D:/jboss400/server/all/lib/
 14:59:03,218 INFO  [Server] Root Deployment Filename:
 jboss-service.xml
 14:59:03,218 INFO  [Server] Starting General Purpose
 Architecture (GPA)...
 14:59:03,984 INFO  [ServerInfo] Java version:
 1.4.2_06,Sun Microsystems Inc.
 14:59:03,984 INFO  [ServerInfo] Java VM: Java
 HotSpot(TM) Client VM 1.4.2_06-b03,Sun Microsystems In
 c.
 14:59:03,984 INFO  [ServerInfo] OS-System: Windows XP
 5.1,x86
 14:59:04,687 INFO  [Server] Core system initialized
 14:59:08,687 INFO  [Log4jService$URLWatchTimerTask]
 Configuring from URL: resource:log4j.xml
 14:59:08,828 INFO  [WebService] Using RMI server
 codebase: http://hp2:8083/
 14:59:09,140 INFO  [NamingService] Started
 jnpPort=1099, rmiPort=1098, backlog=50, bindAddress=/0.0.
 0.0, Client SocketFactory=null, Server
 [EMAIL PROTECTED]
 3076
 14:59:18,750 INFO  [EjbModule] Deploying
 ClusteredHTTPSession
 14:59:19,000 INFO  [EJBDeployer] Deployed:
 file:/D:/jboss400/server/all/deploy/jbossha-httpsession.s
 ar/ClusteredHttpSessionEB.jar/
 14:59:25,093 INFO  [Embedded] Catalina naming disabled
 14:59:25,812 INFO  [Http11Protocol] Initializing Coyote
 HTTP/1.1 on http-0.0.0.0-8080
 14:59:25,859 INFO  [Catalina] Initialization processed
 in 672 ms
 14:59:25,859 INFO  [StandardService] Starting service
 jboss.web
 14:59:25,859 INFO  [StandardEngine] Starting Servlet
 Engine: Apache Tomcat/5.0.28
 14:59:25,875 INFO  [StandardHost] XML validation disabled
 14:59:25,906 INFO  [Catalina] Server startup in 47 ms
 14:59:26,062 INFO  [TomcatDeployer] deploy,
 ctxPath=/ebxmlrr, warUrl=file:/D:/jboss400/server/all/de
 ploy/ebxmlrr-service.sar/ebxmlrr.war/
 14:59:26,671 INFO  [STDOUT] Initialized REST
 14:59:26,750 INFO  [SAAJServlet] init
 14:59:27,234 INFO  [SAAJServlet] init
 14:59:27,421 INFO  [TomcatDeployer] deploy,
 ctxPath=/invoker, warUrl=file:/D:/jboss400/server/all/de
 ploy/http-invoker.sar/invoker.war/
 14:59:27,703 INFO  [TomcatDeployer] deploy,
 ctxPath=/ws4ee, warUrl=file:/D:/jboss400/server/all/tmp/
 deploy/tmp60926jboss-ws4ee-exp.war/
 14:59:27,828 INFO  [TomcatDeployer] deploy, ctxPath=/,
 warUrl=file:/D:/jboss400/server/all/deploy/jb
 ossweb-tomcat50.sar/ROOT.war/
 14:59:33,109 INFO  [STDOUT] Loading properties file:
 resourceName = '/org/exolab/castor/castor.prope
 rties' fileName = 'castor.properties'
 14:59:34,546 INFO  [DefaultPartition] Initializing
 14:59:35,031 INFO  [STDOUT]
 ---
 GMS: address is 192.168.0.2:1079 

[JBoss-dev] [JBoss JIRA] Closed: (JBAS-1095) JBoss 3.2.5 error

2005-02-23 Thread Scott M Stark (JIRA)
 [ http://jira.jboss.com/jira/browse/JBAS-1095?page=history ]
 
Scott M Stark closed JBAS-1095:
---

Resolution: Rejected

http://www.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases
http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration


 JBoss 3.2.5 error
 -

  Key: JBAS-1095
  URL: http://jira.jboss.com/jira/browse/JBAS-1095
  Project: JBoss Application Server
 Type: Bug
 Reporter: SourceForge User
 Assignee: Scott M Stark



 SourceForge Submitter: vichybaby .
 I am upgrading Jboss from 3.0.4 to 3.2.5. There are two 
 applications and correct operation are as belows:
 1 jboss/deploy/default/deploy/aaa.ear(context-root=aaa)
 when jboss start up, will run 
 http://myserver:8080/aaa/servlet2, this servlet will 
 invoke method1 of 
 jboss/deploy/default/deploy/aaa.ear/aaa.war/WEB-
 INF/classes/com/mycompany/MyClass.class
 2 jboss/deploy/default/deploy/bbb.ear(context-root=/)
 when jboss start up, will run 
 http://myserver:8080/servlet1, this servlet will invoke 
 method2 of 
 jboss/deploy/default/deploy/bbb.ear/bbb.war/WEB-
 INF/classes/com/mycompany/MyClass.class(This class is 
 not same as the NyClass.class in aaa.ear)
 But when we try Jboss3.2.5, Jboss deploy aaa.ear first, 
 load up /servlet1 and find/load 
 jboss/deploy/default/deploy/aaa.ear/aaa.war/WEB-
 INF/classes/com/mycompany/MyClass.class first, 
 then Jboss deploy bbb.ear, load up aaa/servlet2, but it 
 find the wrong MyClass.class in anther ear. So error 
 happens: No such Method in com.mycompany.MyClass
 I am confused. Help!

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development


<    1   2   3   4   5   6   7   >