[JBoss-dev] [ jboss-Bugs-764553 ] housekeeping in ServerImpl and ServerConfigLocator

2003-08-19 Thread SourceForge.net
Bugs item #764553, was opened at 2003-07-02 15:28
Message generated for change (Comment added) made by juhalindfors
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=764553group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Rod Burgett (rodburgett)
Assigned to: Juha Lindfors (juhalindfors)
Summary: housekeeping in ServerImpl and ServerConfigLocator

Initial Comment:
This patch addresses housekeeping deficiencies in the 
org.jboss.system.server.ServerImpl and 
ServerConfigLocator classes.

The ServerConfigLocator class has no shutdown method 
but it does hold a static reference to an 
MBeanProxyExt.  This reference becomes invalid when 
the MBeanServer is shutdown.  This patch adds a static 
shutdown method to null out the reference.  Code to 
invoke this new method is added to the shutdown 
processing in ServerImpl.

Several updates are made to the ServerImpl class, some 
making use of updates to other classes from this and 
another patch.  The dependency on another patch is 
noted in the change descriptions below.

There are two changes to the ServerImpl.shutdown() 
method: the shutdown hook that was registered with 
the system runtime during startup is removed, and a null 
check is added before invoking accessors on the 
ServerConfig.

It makes sense to unregister the shutdown hook when 
JBoss is shutdown manually.  In the situation where 
JBoss startup/shutdown is controlled by an outside 
class, this shutdown hook will attempt to repeat the 
process when the VM exits.

Since the init() method will throw an 
IllegalStateException if it finds a non-null config field, 
the shutdown process needs to null out this field.  That 
makes it prudent to check for a null value prior to 
attempting to access methods.  Default values for 
local 'exitOnShutdown' and 'blockingShutdown' flags are 
taken from ServerConfig when config == null.

A few lines of cleanup are added to the 
ShutdownHook.run() method to null out some ServerImpl 
fields and to encourage the GC to run.  This shutdown() 
method needs a (config == null) before attempting to 
find and delete the tmp/deploy directory.

A few comments and error literals from the 
ShutdownHook.shutdownDeployments() and 
shutdownServices() methods suffered from cut-n-paste 
lapse, they are corrected in this patch.

The ShutdownHook.removeMBeans() method is updated 
to include a check for non-null mbean server reference.  
Also, the previous request that the MBeanServerFactory 
release the current mbean server is replaced with a 
request to shutdown the mbean registry.  The registry 
shutdown() method is added by JBoss patch #763378, 
which includes addition of a shutdown method to the 
MBeanServerImpl.  The mbean server shutdown process 
includes a call to the 
MBeanSercverFactory.releaseMBeanServer() method.  
Note that the current patch will cause a run time error - 
probably UnsupportedMethod - if patch #763378 is not 
applied before the current patch.

Prior to shutting down the registry, a new 
ShutdownHook method is called to remove any leftover 
service mbeans.  This new method, 
removeLeftoverMBeans(), queries the mbean server for 
all registered mbeans and attempts to remove most.  
This server impl lacks permission to remove mbeans from 
the 'implementation' domain, so these are skipped, they 
must be removed by the mbean server.


--

Comment By: Juha Lindfors (juhalindfors)
Date: 2003-08-19 10:34

Message:
Logged In: YES 
user_id=175239

Applied to 4.0 DR3.


--

Comment By: Juha Lindfors (juhalindfors)
Date: 2003-08-17 15:43

Message:
Logged In: YES 
user_id=175239

I read through the patch and it looks to me the removal of
shutdown hook is in incorrect place. 

If the hook is removed and we have ExitOnShutdown == true
then the call to Runtime.exit() will not have a chance to
execute the shutdown hook (or it should explicitly do so
inside the ServerImpl.exit() method).

For ExitOnShutdown == false the patch looks valid as both
execution paths will execute the shutdown hook's shutdown()
method explicitly.

If I missed something in your patch let me know. Otherwise I
will apply it with the above modification.


--

Comment By: Rod Burgett (rodburgett)
Date: 2003-07-02 15:28

Message:
Logged In: YES 
user_id=681969

add the other diff file...

--

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


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual 

[JBoss-dev] [ jboss-Bugs-791195 ] PropertyMap disallows changes to JNDI System properties

2003-08-19 Thread SourceForge.net
Bugs item #791195, was opened at 2003-08-19 14:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=791195group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tomasz Stanczak (tstanczak)
Assigned to: Nobody/Anonymous (nobody)
Summary: PropertyMap disallows changes to JNDI System properties

Initial Comment:
The class org.jboss.util.property.PropertyManager in its 
static part creates an instance of 
org.jboss.util.property.PropertyMap and replaces the 
original System properties using this new instance, 
after copying its content into the PropertyMap (which 
descends from Properties).

According to the comments in the source of 
PropertyManager this is done to enable notifications 
about changes through System.setProperty().

The PropertyMap has yet another feature - it caches all 
the JNDI related properties in a separate Map to 
optimize access.

A side effect of all this is that JNDI related properties 
remain read-only for the time after the replacemens of 
the original System properties.

The reason: the getProperty method looks up the 
internal cache before asking original properties for a 
value. For all JNDI related properties the values existing 
in System properties at the time of the replacement are 
being found in the cache, so the original values are not 
being looked up.

Since setProperty just puts the new value into the 
System properties but doesn't change the cache Map, 
any changes to the JNDI properties afterwards 
(regardless of the reason) remain unseen for all the 
outside code that uses System.getProperty.

Even worse, JNDI properties not existing during the 
initialisation phase are being cached with null values.

A real life example of a problem: Borland's visibroker 
during its own initialisation reads all the keys, iterates 
through them and saves alltogether into its own 
Hashtable. JNDI properties with null values cause it to 
break, since Hashtable doesn't allow neither null keys 
nor values.

Regardless of the fact if visibroker does it right not 
checking the values before putting them into a 
Hashtable, turning JNDI properties into read-only 
doesn't feel right.

--

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


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-791196 ] web-console is JDK 1.4 specific

2003-08-19 Thread SourceForge.net
Bugs item #791196, was opened at 2003-08-19 14:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=791196group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tomasz Stanczak (tstanczak)
Assigned to: Nobody/Anonymous (nobody)
Summary: web-console is JDK 1.4 specific

Initial Comment:
web-console uses JDK 1.4 specific code: 

start web-console
open J2EE/JSR-77 Domains/Manager/JBoss

select an EJB jar, then a single Bean. 

The Exception thrown shows a call to:

java.net.URLEncoder.encode(string, string)

which is there since JDK 1.4.

Due to the fact, that for the time being we have to stick 
to JDK 1.3 (our Orbix as well as Visibroker ORBs work 
only with JDK 1.3), this means that web-console 
doesn't show EJB statistics.

--

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


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-791202 ] jboss_web_3_2.dtd is wrong

2003-08-19 Thread SourceForge.net
Bugs item #791202, was opened at 2003-08-19 15:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=791202group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tomasz Stanczak (tstanczak)
Assigned to: Nobody/Anonymous (nobody)
Summary: jboss_web_3_2.dtd is wrong

Initial Comment:
jboss_web_3_2.dtd that can be found in docs/dtd is 
wrong.

The example mentioned in the dtd:

class-loading java2ClassLoadingCompliance='false'
   loader-repository 
loaderRepositoryClass='dot.com.LoaderRepository'
  dot.com:loader=unique-archive-name
  loader-repository-config 
configParserClass='dot.com.LoaderParser'
 java2ParentDelegaton=true
  /loader-repository-config
   /loader-repository
/class-loading

cannot work.

If you look at org.jboss.web.AbstractWebContainer 
you'll see that loader-repository node should be a first 
generation element (that is a sibling of class-loading 
and not a child).

This makes the repository working.

Both java2ClassLoadingCompliance attribute of the 
class-loading element and java2ParentDelegaton 
attribute of the loader-repository-config remain ignored, 
the correct way to change the parent delegation is 
undocumented servlet23ClassLoading attribute of the 
class-loading element.

--

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


---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-742400 ] java:comp not bound when java2ClassLoadingCompliance false

2003-08-19 Thread SourceForge.net
Bugs item #742400, was opened at 2003-05-23 17:21
Message generated for change (Comment added) made by tstanczak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=742400group_id=22866

Category: JBossWeb
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Chris Bonham (bonhamcm)
Assigned to: Scott M Stark (starksm)
Summary: java:comp not bound when java2ClassLoadingCompliance false

Initial Comment:
Tested in both JBoss 3.2.0RC4 Tomcat 4.1.18 and 
JBoss 3.2.2beta Tomcat 4.1.24, Win2K, Sun JDK 
1.4.1_02.

When java2ClassLoadingCompliance is set to false in 
jboss-web.xml, the java:comp context cannot be 
accessed.  It appears that that the ENC context is 
loaded by the FactoryURLClassLoader before the 
application has read the jboss-web.xml file to see that it 
should actually be loaded by the WebAppClassLoader 
since java2ClassLoadingCompliance is false.

javax.naming.NameNotFoundException: comp not bound
at org.jnp.server.NamingServer.getBinding
(NamingServer.java:495)
at org.jnp.server.NamingServer.getBinding
(NamingServer.java:503)
at org.jnp.server.NamingServer.getObject
(NamingServer.java:509)
at org.jnp.server.NamingServer.lookup
(NamingServer.java:253)
at org.jnp.interfaces.NamingContext.lookup
(NamingContext.java:500)
at org.jnp.interfaces.NamingContext.lookup
(NamingContext.java:479)
at javax.naming.InitialContext.lookup
(InitialContext.java:347)
at 
org.jboss.test.classloader.scoping.override.web.log4j113.
ENCServlet.processRequest(ENCServlet.java:56)
at 
org.jboss.test.classloader.scoping.override.web.log4j113.
ENCServlet.doGet(ENCServlet.java:35)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalD
oFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.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$StandardPipe
lineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.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:2415)
at 
org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:509)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.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.StandardEngineValve.invoke
(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipe
lineValveContext.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.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:223)
at 
org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:594)
at 
org.apache.coyote.http11.Http11Protocol$Http11Connect
ionHandler.processConnection(Http11Protocol.java:392)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:565)
at 

[JBoss-dev] [ jboss-Change Notes-791336 ] DLQ User/Password

2003-08-19 Thread SourceForge.net
Change Notes item #791336, was opened at 2003-08-19 16:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=381174aid=791336group_id=22866

Category: JBossServer
Group: v3.2
Status: Open
Priority: 5
Submitted By: Adrian Brock (ejort)
Assigned to: Nobody/Anonymous (nobody)
Summary: DLQ User/Password

Initial Comment:
Support added for specifying a user/password on the DLQ

e.g.
  invoker-proxy-binding
 namemy-message-driven-bean/name
 invoker-mbeandefault/invoker-mbean

proxy-factoryorg.jboss.ejb.plugins.jms.JMSContainerInvoker/proxy-factory
 proxy-factory-config
   
JMSProviderAdapterJNDIDefaultJMSProvider/JMSProviderAdapterJNDI
   
ServerSessionPoolFactoryJNDIStdJMSPool/ServerSessionPoolFactoryJNDI
MaximumSize15/MaximumSize
MaxMessages1/MaxMessages
MDBConfig
  
ReconnectIntervalSec10/ReconnectIntervalSec
   DLQConfig
 
DestinationQueuequeue/DLQ/DestinationQueue
 
MaxTimesRedelivered10/MaxTimesRedelivered
  TimeToLive0/TimeToLive
  DLQUserguest/DLQUser !--- HERE --
  DLQPasswordguest/DLQPassword 
   /DLQConfig
/MDBConfig
 /proxy-factory-config
  /invoker-proxy-binding

Regards,
Adrian

--

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


---
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [ jboss-Bugs-791196 ] web-console is JDK 1.4 specific

2003-08-19 Thread SourceForge.net
Bugs item #791196, was opened at 2003-08-19 14:56
Message generated for change (Comment added) made by tstanczak
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=791196group_id=22866

Category: JBossServer
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tomasz Stanczak (tstanczak)
Assigned to: Nobody/Anonymous (nobody)
Summary: web-console is JDK 1.4 specific

Initial Comment:
web-console uses JDK 1.4 specific code: 

start web-console
open J2EE/JSR-77 Domains/Manager/JBoss

select an EJB jar, then a single Bean. 

The Exception thrown shows a call to:

java.net.URLEncoder.encode(string, string)

which is there since JDK 1.4.

Due to the fact, that for the time being we have to stick 
to JDK 1.3 (our Orbix as well as Visibroker ORBs work 
only with JDK 1.3), this means that web-console 
doesn't show EJB statistics.

--

Comment By: Tomasz Stanczak (tstanczak)
Date: 2003-08-19 23:30

Message:
Logged In: YES 
user_id=757539

Sure, just use

java.net.URLEncoder.encode(string)

it is available on JDKs  1.4 and marked as deprecated on 1.4

--

Comment By: Juha Lindfors (juhalindfors)
Date: 2003-08-19 18:03

Message:
Logged In: YES 
user_id=175239

Is there a known workaround for JDK1.3? I was planning to
backport some jmx-console changes to 3.2 branch but it also
uses URLEncoder and URLDecoder classes.


--

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


---
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Job Failed to Complete Successfully

2003-08-19 Thread Chris Kimpton
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS==
===
===
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/aoptest.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/circularity.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/security-srp.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc2.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-extent.jar
 [copy] Copying 2 files to 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-commerce.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc31.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc32.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc3.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-tx.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/https-service.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/rsrc4.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/interrupt.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/security-proxy.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/entityref.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/loadingresource.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-lob.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/securitymgr-ejb.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testcopylocaldir.sar
  [ear] Building ear: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/loadingresource.ear
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-query.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/securitymgr-tests.jar
 [copy] Copying 7 files to 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/hloadingresource.ear
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-callbacks.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testcrashinstart.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cmp2-optimisticlock.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/classpath.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testnullinfo.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/brokendeployer.sar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/testmbeanclassloader.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/jbossdo-mktransient.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessiona.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessionb.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/eardeployment.ear
[mkdir] Created dir: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/META-INF
 [copy] Copying 1 file to 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/META-INF
[unjar] Expanding: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessiona.jar into 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/sessiona.jar
[unjar] Expanding: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/sessionb.jar into 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/unpacked/eardeployment.ear/sessionb.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/abstract.jar
  [jar] Building jar: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/concrete.jar
  [ear] Building ear: 
/home/jbossci/jbossci/jboss-head-test/testsuite/output/lib/cpmanifest.ear
  [jar] Building jar: 

[JBoss-dev] Prescriptions written and filled online!US doctors and pharmacies! Overnight Shipping rh zmo tt

2003-08-19 Thread Lynette Kenny






forthcome

Hi, Jboss-development, Mediications Prescribed Online, Get Prescribed VViagra,DietPills

and muchmore online!Overnight Shiipping!! No
Prescription!! s e e now!




mcnaughton aversionn o
m a i l

pretend brahmaputra 
hbee bent 
flatten



hyimhgvyxfmud esmpkd wbkte
nszxk
achax edfxkdxmhhn plor afjildnmihei bgoa
ezdri carpt

[JBoss-dev] [ jboss-Bugs-791485 ] User roles does not update

2003-08-19 Thread SourceForge.net
Bugs item #791485, was opened at 2003-08-19 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=376685aid=791485group_id=22866

Category: JBossSX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Oscar Chavarria (chavao)
Assigned to: Nobody/Anonymous (nobody)
Summary: User roles does not update

Initial Comment:
I am using JBoss and Tomcat.
I have a two users: ADMIN and VISIT.

Steps:

1: The user VISIT has assigned the ADDR role.
2: The user VISIT is logged in the application and all 
roles is loaded.
3: The user VISIT use the option LOGOUT.
4: The user ADMIN is logged in the application.
5: The user ADMIN change the roles assigned to the 
user VISIT: from ADDR to ADDR_1.
6: The user VISIT is logged in the application again.
7: The active role for the user VISIT is ADDR.

Why the roles assigned to user VISIT are not 
actualized in the application?
What object class store this information? 

Best regards

Oscar

--

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


---
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Optimistic Locking Issue

2003-08-19 Thread Ken Sipe
There appears to be an issue a friend discovered with some the logic of
generated sql code.  Here are his details:

Optimistic Locking problem when using SQL Server 2000 and JBoss 3.2.1

When using SQL Server with JBoss 3.2.1 the following problem occurs.
When updating an optimistically locked field that has an initial value of
null the update fails.

Code related:
JDBCStoreCommand.java  line 00108
sql.append( WHERE).append(SQLUtil.getWhereClause(whereFields));

The where fields are the primary key field and the optimistically  locked
fields.

String jdbc::SQLUtil::getWhereClause(List fields) [inline static]
Returns columnName0=? [AND columnName1=? [AND columnName2=? []]]

In SQL Server 2000 if a field is null the syntax has to be
columnName0 is ?  where ? is null

The columnName=? syntax fails the update.

The call on line 00108 should not be completed until the values for the
lockedFields are
known.  This could be done in the for loop between lines 00142 and 00147.
After getting
the values a call to SQLUtil.getWhereClause(JDBCFieldBridge field) or
SQLUtil.getIsNullClause(boolean not, JDBCFieldBridge field, String
identifier) could be
appended to make the SQL statement correct.


Any help here?

Thanks,
Ken



---
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: 92 % ( 13 / 14 ) - come on - pull your finger out

2003-08-19 Thread Chris Kimpton
===
==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS==
===
===


JBoss daily test results

SUMMARY

Number of tests run:   14



Successful tests:  13

Errors:1

Failures:  0





[time of test: 2003-08-20.00-27 GMT]
[java.version: 1.4.1_03]
[java.vendor: Sun Microsystems Inc.]
[java.vm.version: 1.4.1_03-b02]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Linux]
[os.arch: i386]
[os.version: 2.4.20-18.7]

See http://jboss1.kimptoc.net/linux1/logtests/testresults/reports/html//. for
the junit report 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:   InvocationLogUnitTestCase
Test:testClientInvocationLog(org.jboss.test.aop.test.InvocationLogUnitTestCase)
Type:error
Exception:   java.lang.InternalError
Message: Test timeout
-


===Wed Aug 20 
01:27:39 BST 2003
===Linux nog 
2.4.20-18.7 #1 Thu May 29 08:32:50 EDT 2003 i686 unknown
===java 
version 1.4.1_03
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02)
Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode)


---
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development