[JBoss-dev] Schedule forConnection management changes in 3.2

2003-02-20 Thread Jonas Partner 



Hi 
I was hoping that someone could provide guidance on 
whether we should continue trying to develop with 3.2
or whether to try and drop back to 
3.0.x,at the moment 3.2 RC1, RC2 and a 
clean 3.2build from CVS do not seem 
to be closing local transaction database 
connections see the below stack from the 
testsuite. This is proving 
critical since under moderate usage we can quickly run out of connections .Since we have 
afreeze date 
approaching in the next week or two we are looking for guidance as 
to when the changes in connection 
management are likely to be completed and also whether any assistance with this would be welcome.

Regards 

Jonas Partner
Software Developer
Xerox Mobile Solutions
Cambridge


2003-02-20 09:20:38,100 INFO 
[org.jboss.test.jca.ejb.CachedConnectionSessionBean] ejb activate never called, 
conn == null2003-02-20 09:20:38,100 INFO 
[org.jboss.resource.connectionmanager.CachedConnectionManager] Could not find a 
close method on alleged connection objects. Please close your own 
connections.java.lang.Exception: Stack Traceat 
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357)at 
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)at 
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)at 
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108)at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243)at 
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)at 
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)at 
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154)at 
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)at 
org.jboss.ejb.Container.invoke(Container.java:652)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.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)at 
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)at 
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338)at 
sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at 
java.lang.reflect.Method.invoke(Method.java:324)at 
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)at 
sun.rmi.transport.Transport$1.run(Transport.java:148)at 
java.security.AccessController.doPrivileged(Native Method)at 
sun.rmi.transport.Transport.serviceCall(Transport.java:144)at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)at 
java.lang.Thread.run(Thread.java:536)

[JBoss-dev] [ jboss-Bugs-676243 ] FileURLConnection needs URL decode for JDK 1.4

2003-02-20 Thread SourceForge.net 
Bugs item #676243, was opened at 2003-01-28 18:23
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=676243group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Everitt (andieveritt)
Assigned to: Nobody/Anonymous (nobody)
Summary: FileURLConnection needs URL decode for JDK 1.4

Initial Comment:
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('|', ':'));


--

Comment By: Andrew Everitt (andieveritt)
Date: 2003-02-20 14:55

Message:
Logged In: YES 
user_id=689882

OK, after some investigation it appears that this may not be
quite the correct fix! The problem is some apparent
inconsistency with when paths are getting URL encoded.
Somethings like:
URL url = new URL(file:///C:/Program Files/foo/bar);
Doesn't seem to get URL encoded and will work fine when
passed to FileURLConnection. However things like:
URL csurl =
Some.class.getProtectionDomain().getCodeSource().getLocation();
and
URL res = Some.class.getClassLoader().getResource(File in
path with space.txt);
returns a path that is URL encoded and so doesn't work when
a file is in a path with a space.

I guess that JBoss is using these calls to get URLs for
resources which then throw up later.

More to follow.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=676243group_id=22866


---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Re: [JBoss-dev] Schedule forConnection management changes in 3.2

2003-02-20 Thread David Jencks 
I fixed the immediate problem in jboss 3.2, other versions to follow
shortly.

The intent of this feature is to encourage you to clean up after yourself
by closing all database connections you get before you leave the ejb method
they were obtained in.  This is contrary to the jca spec requirement that
the app server allow you to hold connection handles across ejb method
invocations, hooking the handle up to a suitable (tx and security)
ManagedConnection for each ejb call.  I cannot emphasize enough how
strongly I advise you to obtain and close your connection handles in each
ejb call.

If you require holding connection handles over method invocations, set the
CachedConnectionManager SpecCompliant attribute to true in the
jboss-jca.sar/META-INF/jboss-service.xml file.

I can't imagine how your code could have worked with the previous jboss
code without running out of connection handles just as fast, so if there
are additional problems please let me know.

thanks
david jencks


On 2003.02.20 05:19 Jonas Partner wrote:
 Hi 
 I was hoping that someone could provide guidance on whether we should
 continue trying to develop with 3.2
 or whether to try and drop back to 3.0.x, at the moment 3.2 RC1, RC2 and
 a clean 3.2 build from CVS do not seem 
 to be closing local transaction database connections see the below stack
 from the testsuite.  This is proving 
 critical since under moderate usage we can quickly run out of connections
 .Since we have a freeze date 
 approaching in the next week or two we are looking for guidance as to
 when the changes in connection 
 management are likely to be completed and also whether any assistance
 with this would be welcome.
 
 Regards 
 
 Jonas Partner
 Software Developer
 Xerox Mobile Solutions
 Cambridge
 
 
 2003-02-20 09:20:38,100 INFO  [org.jboss.test.jca.ejb.CachedConnectionSessionBean]
 ejb activate never called, conn == null
 2003-02-20 09:20:38,100 INFO  
[org.jboss.resource.connectionmanager.CachedConnectionManager]
 Could not find a close method on alleged connection objects.  Please
 close your own connections.
 java.lang.Exception: Stack Trace
  at 
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357)
  at 
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199)
  at 
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190)
  at 
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77)
  at 
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108)
  at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243)
  at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104)
  at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130)
  at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208)
  at 
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154)
  at 
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322)
  at org.jboss.ejb.Container.invoke(Container.java:652)
  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.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
  at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
  at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338)
  at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:324)
  at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
  at sun.rmi.transport.Transport$1.run(Transport.java:148)
  at java.security.AccessController.doPrivileged(Native Method)
  at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
  at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
  at java.lang.Thread.run(Thread.java:536)
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
 HTMLHEAD
 META http-equiv=Content-Type content=text/html; charset=iso-8859-1
 META content=MSHTML 6.00.2800.1126 name=GENERATOR
 STYLE/STYLE
 /HEAD
 BODY bgColor=#ff
 DIVFONT face=Arial size=2Hi /FONT/DIV
 DIVFONT face=Arial size=2I was hoping that someone could provide
 guidance on 
 whether we should continue trying to develop with 3.2/FONT/DIV
 DIVFONT face=Arial size=2or whether to try and drop back to 
 3.0.x,nbsp;/FONTFONT face=Arial

[JBoss-dev] [ jboss-Bugs-669112 ] Server.log not created when using xerces

2003-02-20 Thread SourceForge.net 
Bugs item #669112, was opened at 2003-01-16 15:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=669112group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Andrew Everitt (andieveritt)
Assigned to: Nobody/Anonymous (nobody)
Summary: Server.log not created when using xerces

Initial Comment:
If JBoss is installed into a path with a space in the
name (e.g. C:\Program Files\JBoss) and you are using
Xerces as the JAXP implementation the server.log file
is not created. All logging is written to boot.log.

I see the following exception on the screen (but not in
boot.log):
16:04:35,656 INFO  [Log4jService$URLWatchTimerTask]
Configuring from URL: resource:log4j.xml
log4j:ERROR Could not parse input source
[org.xml.sax.InputSource@95cfbe].
java.net.MalformedURLException: no protocol: log4j.dtd
at java.net.URL.init(Unknown Source)
at java.net.URL.init(Unknown Source)
at java.net.URL.init(Unknown Source)
at
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807)
at
org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:767)
at
org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:275)
at
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:841)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
at
org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at
org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:253)
at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:201)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:672)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:616)
at
org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:602)
at
org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:704)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:486)
at
org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:425)
at
org.jboss.logging.Log4jService.startService(Log4jService.java:281)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:164)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:976)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:397)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy3.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:249)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:802)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:221)
at
com.xms.install.jboss.JBossJService.bootJBoss(JBossJService.java:139)
at

[JBoss-dev] ³Ì·s°ê»Ú¦æ¾Pemail¦W³æ ¤T¤d¤C¦Ê¤­¤Q¸Uµ§

2003-02-20 Thread 521g5e1v110c 
Title: HTML PAGE













  

  
  


  ¡@
  ³Ì·s°ê»Ú¦æ¾Pemail¦W³æ
  ¥þ¥@¬É¦@3750¸Uµ§

  
  
¡@
  ¡@
  
  

  


  
¡½¥úºÐ¤º®e
  
  

  ³Ì·s¥þ¥@¬É3750¸Uµ§E-mail¦W³æ
  »`¶°ªº¨Ó·½¬°ºô»Úºô¸ô»P¦UºØ®Ñ­±¸ê®Æ¡C¨C¤@µ§³£¸g¹LÅçÃÒ¡A½T»{½T¹ê¦s¦b¡A¤~¤©¥H«O¯d¡C¦b¹ê»Ú¨Ï¥Î¹Lµ{¤¤¡A¥u­nµo²{¬Y¨Ç¸ê®Æ¤w¸g¹L®É¡A«h¥ß§Y¤©¥H­ç°£¡C³Ì«á¦A¨Ì·Ó°ê®a§O»P¦æ·~§O¨Ó¾ã²z¡A³o¼ËÀ³¥iº¡¨¬¤j¦h¼Æ°ê»Úºô¸ô¦æ¾Pªº­n¨D¡C
  
  °ê»ÚE-mail¦a°Ï¤ÀÃþ¡G
  
  ¿D¬w¡B¿D¦a§Q¡B¤ñ§Q®É¡B¥[®³¤j¡B¤¤°ê¡B¤¦³Á¡BªâÄõ¡Bªk°ê¡B¼w°ê¡B§Æþ¡B­»´ä¡B¦I¤ú§Q¡B¦L«×¡B¦L¥§¡B·Rº¸Äõ¡B¤é¥»¡B°¨¨Ó¦è¨È¡B·s¥[©Y¡B¦è¯Z¤ú¡B·ç¤h¡B¥xÆW¡B®õ°ê¡B¬ü°ê¡B­^°ê¡C
  °ê»ÚE-mail¦æ·~¤ÀÃþ¡G
  ¤â¤uÃÀ«~¡B¨T¨®¡B®T¼Ö³õ©Ò¡B°Ó°È¡B¹q¸£¸ê°T¡B¤Æ§©«~¡BÂå°|ÃÄ«~¡B¤Æ¤u¡B¹q¤l¹q¾¹¡BÂAªá¡B­¹«~¡B¹A·~¯bªª¡B¾÷±ñ¤u·~¡B®a¨ã¤u·~¡B®a®x¥Î«~¡B«Ø¿v¦a²£¡B¯¼Â´ªA¸Ë¡B§«~¡B«OÀI¡BÄ_¥Û¡B¯]Ä_­º¹¢¡B°s©±®ÈÀ]¡Bªk«ß¡B¤å¨ã»ö¾¹¥Î«~¡B¤â´£¹q¸Ü¡B·s»D´CÅé¡B¶l»¼§Ö»¼¡B¥ø·~¡B¾Ç®Õ±Ð¨|¡B¬ì¾Ç¡BÅé¨|¥Î«~¡BªÑ²¼§ë¸ê¡B¯¼Â´ªA¸Ë¡Bª±¨ã¡B¶T©ö¡B®È¹C¡B¤â¿öÄÁªí..µ¥µ¥¡C
  
  ¨Ï¥Î»¡©ú¡B±Ð¾Ç¤â¥U¡G
  ¯S¤½¶}¦h¦~ªº¦æ¾P¬ã¨s¤ß±o¡A¶Ç±Âµo°eemail«H¥óªº¤èªk¡B¬ªù¡C»¡©úµo¤£¥X¥hªº­ì¦]¡BISPÀÉ«Hªº­ì²z¡B¦W³æ¾ã²zªº¤èªk¡A¥H¤Î³Q°±Åvªº­ì¦]µ¥µ¥¡C¨Ã¨Ì¾Ú¨Ï¥Î¥Øªº¡A¸Ô²Ó»¡©ú¦U¬ÛÃö³Ì±j³nÅ骺¨Ï¥Î¤èªk¡C
  ¡@
  ¥tªþ°e¶W±j±À¼s¦æ¾P¤u¨ã¡G
  
  ¡½ °ª³tµo«H³nÅé
 °ª³tµo«H³nÅéµL¶·¦w¸Ë¡A¨Ï¥Î¤è«K¡A¨C¤p®É¥i send¼Æ¸U«Êemail¡A¥i¤ä´©Html¡]ºô­¶®æ¦¡¡^¡BTxt¡]¯Â¤å¦r¡^®æ¦¡ªºEmail¡Cµo°eemailµL¶·¸g ISP¡A¯à±N§Aªº¹q¸£·í§@¤@¥x mail Serverª½±µ¶Ç°e¡A¥\¯à±j¤j¡C
  
  ¡½·j´M¾¹¦Û°Êµn³°¾¹
 ¯à±N±zªººô¯¸¦Û°Êµn³°¦Ü¥þ¥@¬É¦U¤j¤p·j´M¤ÞÀº¡A¥O±zªººô¯¸¤@Á|¦¨¦W¡AÅý±zºô¯¸ªº¤H¬y¶qÅå¤H¦a¥H­¿¼Æ¼Wªø¡C³t«×­¸§Ö¡A¦p¤â°Êµn³°¶·­n¼Æ­Ó¤ë®É¶¡¡A²{¦b¥u¶·¼Æ¤ÀÄÁ´N¥i§¹¦¨¡C
  
  ¡½ ¹q¤l¶l¥ó¦a§è·j´M¤U¸ü³n¥ó 
 ¥i¥H±qºô¯¸©Î Html¸Ì·j´M¤U¸ü Email¦a§è¡A¥i¦Û©w·j´Mªº½d³ò¡B¼h¼Æ¡A·j´M³t«×­¸§Ö¡A±q¦¹¥i¦Û­q¦Û¤vªº¶l¥ó¦Cªí¡A¬Oºô¸ô¦æ¾P±À¼sªº¥²³Æªººë«~¡C 

  
  

  
  

  
  
¡½¥ß§Y­qÁÊ
  
  

 
 

  
  

  
¡E³Ì·s°ê»Ú¦æ¾Pemail¦W³æ¡A¨C¤ù¯S»ù1600¤¸(§t¶l¸ê)¡C
¡E¤U¤è­qÁʳæ¸ê®Æ°È¥²¶ñ¼g¥¿½T¡A¥H«K°e³f¡C
¡E¥»²£«~³z¹L¶l§½»¼°e¦Ü©²¤W¡A¶l®t¥N¦¬³f»ù³f¨ì¥I´Ú¡C


  


  
¤¤¤å©m¦W
  
  


  Ápµ¸¹q¸Ü
  


  ¹q¤l«H½c
  


  ¶l»¼°Ï¸¹
  


  °e³f¦a§}
  

  


  
  ¡@

  
  

  
  
  

  
  
  

  
  

  
  

  
  

  

  

  
  

  











---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-690177 ] JBoss startup does not work under linux

2003-02-20 Thread SourceForge.net 
Bugs item #690177, was opened at 2003-02-20 12:24
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=690177group_id=22866

Category: JBoss-IDE
Group: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Hans Dockter (hans_d)
Assigned to: Hans Dockter (hans_d)
Summary: JBoss startup does not work under linux

Initial Comment:
JBoss 3.2 from cThis bug was mentioned in the froum by
Bernd Koeke and others:

Eclipse 2.1 M5
Both on Sun JDK 1.4.1_01
SuSE Linux 8.0

I have one JBoss outside the workspace, which I build
by hand with build.sh and I use tomcat41 (tomcat 4.1.18
LE jdk1.4). Another JBoss 3.2 is checked out in eclipse
for debugging.

When I start JBoss by run.sh with a run.conf for remote
debugging, e.g. on port 8000 and configure JBoss
remote it works. But when I want to start it with a
JBoss 3.x configuration I get the following message
in a popup:

org.eclipse.core.runtime.CoreException Could not
connect to VM

and in the console window:

Exception in thread main
java.lang.NoClassDefFoundError:

--

Comment By: John Schult (jdschult)
Date: 2003-02-20 15:59

Message:
Logged In: YES 
user_id=491610

An additional configuration that produces same behavior is:

RH Linux 8.0
Sun JDK 1.3.1
JBoss 2.4.4
Eclipse M5

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=690177group_id=22866


---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 20-February-2003

2003-02-20 Thread scott . stark 


JBoss daily test results

SUMMARY

Number of tests run:   1043



Successful tests:  1038

Errors:2

Failures:  3





[time of test: 2003-02-20.12-08 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1_03-69]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.2.4]

See http://users.jboss.org/~starksm/Branch_3_0/2003-02-20.12-08
for details of this test. 

NOTE: If there are any errors shown above - this mail is only highlighting 
them - it is NOT indicating that they are being looked at by anyone.

It is assumed that whoever makes change(s) to jboss that 
break the test will be fixing the test or jboss, as appropriate!





DETAILS OF ERRORS



Suite:   MissingClassUnitTestCase
Test:
testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase)
Type:error
Exception:   org.jboss.deployment.DeploymentException
Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: 
(javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not 
registered.)
-



Suite:   SecurityUnitTestCase
Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase)
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: Should not have been able to lookup(invokers)
-



Suite:   SecurityUnitTestCase
Test:
testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase)
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: Should not have been able to lookup(invokers)
-



Suite:   BeanStressTestCase
Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase)
Type:failure
Exception:   junit.framework.AssertionFailedError
Message: expected a client deadlock for AB BA
-



Suite:   HelloClusteredHttpStressTestCase
Test:testCNFEObject(org.jboss.test.hello.test.HelloClusteredHttpStressTestCase)
Type:error
Exception:   java.rmi.ServerException
Message: Service unavailable last exception:
-




---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Patches-690364 ] local-directory not working on expanded SAR

2003-02-20 Thread SourceForge.net 
Patches item #690364, was opened at 2003-02-20 16:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=690364group_id=22866

Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Callies (pcallies)
Assigned to: Nobody/Anonymous (nobody)
Summary: local-directory not working on expanded SAR

Initial Comment:
To prove this, modify the jboss-service.xml deployment 
descriptor in the C:\jboss-3.0.6\server\all\deploy\http-
invoker.sar to start as follows:

?xml version=1.0 encoding=UTF-8? 
!DOCTYPE server 
!-- $Id: jboss-service.xml,v 1.1.4.6 2003/01/03 21:39:21 
starksm Exp $ -- 

server 
local-directory path=invoker.war/ 
  !-- The HTTP invoker service configration 
  -- 
  mbean 
code=org.jboss.invocation.http.server.HttpInvoker 
... 

When SARDeployer processed local-directory elements, 
it assumed that it was dealing with a compressed sar/jar 
file.  In the case of an expanded SAR this caused a 
ZipFile exception.

To fix, an if-else was added to SARDeployer's init 
method.  If the SARDeployer is dealing with an 
expanded SAR when processing local-directory 
elements, it calls a new method, copyLocalDirectories.

The copyLocalDirectories method recursively copies the 
contents of the local-directory to the data directory.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376687aid=690364group_id=22866


---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] JBoss 3.2 xdoclet support

2003-02-20 Thread David Jencks 
I updated xdoclet to use the 3.2 cmp2 dtd if requested and tried to update
the template to include the new elements, in particular optimistic locking
and audit fields.

I'd really appreciate some feedback on whether this actually works before I
update the jb4 cvs copy of xdoclet.

Remember that in jb 4 you can get and compile a copy of xdoclet by going to
the xdoclet module and running ./build.sh

You may need to remove old last.xdoclet.build and last.xdoclet.update files
to get a proper cvs update.

I still have no plans to upgrade the xdoclet used to build 3.2

Thanks
david jencks 


---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

[JBoss-dev] [ jboss-Bugs-690506 ] 3.2.0RC2 xa_start error -8 with SQLServer

2003-02-20 Thread SourceForge.net 
Bugs item #690506, was opened at 2003-02-21 00:28
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=690506group_id=22866

Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Prud'hommeaux (mprudhom)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2.0RC2 xa_start error -8 with SQLServer

Initial Comment:
When attempting to commit an XA transaction using
SQLServer (using the MS driver, configured using the
mssql-xa-ds.xml DS configured in the examples), it
works fine the first time. The second time, it throws
javax.transaction.xa.XAException:
[Microsoft][SQLServer 2000 Driver for
JDBC][SQLServer]xa_start (0) returns -8.

According to section 4.5 of the X/Open XA
specification, -8 indicates the XID already exists,
which indicates that JBoss may be re-using XIDs
inappropriately.

The exact same code worked for JBoss 3.2.0 beta 3.


System info:

[chance mprudhom]$ java -version
java version 1.3.1
Java(TM) 2 Runtime Environment, Standard Edition (build
1.3.1-root_1.3.1_020714-12:46)
Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode)
[chance mprudhom]$ uname -a
Darwin chance.local. 6.4 Darwin Kernel Version 6.4: Wed
Jan 29 18:50:42 PST 2003;
root:xnu/xnu-344.26.obj~1/RELEASE_PPC  Power Macintosh
powerpc

Stack trace:

19:29:19,487 WARN  [TransactionImpl] XAException:
tx=TransactionImpl:XidImpl [FormatId=257,
GlobalId=chance.local.//8, BranchQual=]
errorCode=XAER_RMERR
javax.transaction.xa.XAException: [Microsoft][SQLServer
2000 Driver for JDBC][SQLServer]xa_start (0) returns -8
at
com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown
Source)
at
com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.start(Unknown
Source)
at
com.microsoft.jdbcx.base.BaseXAResource.start(Unknown
Source)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:110)
at
org.jboss.tm.TransactionImpl.startResource(TransactionImpl.java:1137)
at
org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:624)
at
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:461)
at
org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:359)
at
org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:546)
at
org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:837)
at
org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102)
at
com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnector.java:61)
at
com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFactory.java:179)
at
com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfiguration.java:336)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPersistenceManagerFactory.java:454)
at
com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenceManagerFactory.java:337)
at
com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53)
at
javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269)
at
com.solarmetric.kodo.runtime.AllFieldTypesTest.clinit(AllFieldTypesTest.java)
at
XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:99)
at
XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:72)
at
XAEnvironmentTest.start(XAEnvironmentTest.java:323)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966)
at $Proxy11.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:392)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:231)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:827)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:612)
at java.lang.reflect.Method.invoke(Native Method)
at