Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
I don't understand how this is the cause of the ClassCastException? Can you explain that please. --jason Jan Bartel wrote: > Jason, > > Okay, I'm not perplexed anymore! :-) Jetty expects to find at least > either a WEB-INF/classes directory, or a WEB-INF/lib (with at least one > jar in it) in the webapp directory - so the short term fix is for you > to create an empty WEB-INF/classes directory, and all should be well. > > In the slightly longer term, the fix is for us to deal with non-existant > WEB-INF directories in a slightly more flexible manner. ;-) > > Jan > > >>> Can you please post some more details on your exact scenario, viz: >> >> >> >> >> Will try. >> >>> + is this a hot redeploy of Jetty, especially is it a hot redeploy >>>when some webapps were already deployed? >> >> >> >> Not a redeploy. >> >>> + have you modified your jetty jboss-service.xml file to include a >>> webapp (long shot, but I have to ask)? >> >> >> >> Yes, before there is >> >> >>/ >> >> >> >>> + what code base are you running off? >> >> >> >> JBoss HEAD >> >>> + what kind of log trace do you see? >> >> >> >> I mailed that already but here you go again: >> >> 23:56:35,547 INFO [Jetty] ResourceHandler started in >> file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ >> >> 23:56:35,547 INFO [Jetty] Started ResourceHandler in >> >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > >> >> 23:56:35,547 INFO [Jetty] Started NotFoundHandler in >> >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > >> >> 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 >> 23:56:35,567 ERROR [JettyService] multipule exceptions... >> 23:56:35,577 ERROR [JettyService] exception >> java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >> org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >> org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >> org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) >> >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> org.jboss.jetty.JettyService.startService(JettyService.java:236) >>at >> org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) >> >>at $Proxy0.start(Unknown Source) >>at >> org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at >> org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) > >> >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) > >> >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) > >> >>at >> org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >> com.sun.management.jmx.MBeanServerImpl.invoke(MBean
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Jason, Okay, I'm not perplexed anymore! :-) Jetty expects to find at least either a WEB-INF/classes directory, or a WEB-INF/lib (with at least one jar in it) in the webapp directory - so the short term fix is for you to create an empty WEB-INF/classes directory, and all should be well. In the slightly longer term, the fix is for us to deal with non-existant WEB-INF directories in a slightly more flexible manner. ;-) Jan >> Can you please post some more details on your exact scenario, viz: > > > > Will try. > >> + is this a hot redeploy of Jetty, especially is it a hot redeploy >>when some webapps were already deployed? > > > Not a redeploy. > >> + have you modified your jetty jboss-service.xml file to include a >> webapp (long shot, but I have to ask)? > > > Yes, before there is > > >/ > > > >> + what code base are you running off? > > > JBoss HEAD > >> + what kind of log trace do you see? > > > I mailed that already but here you go again: > > 23:56:35,547 INFO [Jetty] ResourceHandler started in > file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ > > 23:56:35,547 INFO [Jetty] Started ResourceHandler in > >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > > > 23:56:35,547 INFO [Jetty] Started NotFoundHandler in > >WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] > > > 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 > 23:56:35,567 ERROR [JettyService] multipule exceptions... > 23:56:35,577 ERROR [JettyService] exception > java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >at > org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >at > org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) >at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >at > >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) > >at org.mortbay.http.HttpServer.start(HttpServer.java:186) >at org.jboss.jetty.JettyService.startService(JettyService.java:236) >at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) > >at $Proxy0.start(Unknown Source) >at > org.jboss.system.ServiceController.start(ServiceController.java:343) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >at $Proxy3.start(Unknown Source) >at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >at $Proxy2.deploy(Unknown Source) >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) > > >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) > > >at > >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) > > >at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >at java.lang.reflect.Method.invoke(Native Method) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) > >at $Proxy0.start(Unknown Source) >at > org.jboss.system.ServiceController.start(ServiceController.java:343) >at > or
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment/scanner AbstractDeploymentScanner.java URLDeploymentScanner.java URLDeploymentScannerMBean.java
User: user57
Date: 02/03/02 00:05:19
Added: src/main/org/jboss/deployment/scanner
AbstractDeploymentScanner.java
URLDeploymentScanner.java
URLDeploymentScannerMBean.java
Log:
o Adding a URLDeploymentScanner
Revision ChangesPath
1.1
jboss-system/src/main/org/jboss/deployment/scanner/AbstractDeploymentScanner.java
Index: AbstractDeploymentScanner.java
===
/***
* *
* JBoss: The OpenSource J2EE WebOS *
* *
* Distributable under LGPL license. *
* See terms of license at gnu.org. *
* *
***/
package org.jboss.deployment.scanner;
import java.io.File;
import java.util.Collection;
import java.util.List;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.Set;
import java.util.HashSet;
import java.util.StringTokenizer;
import java.net.URL;
import java.net.MalformedURLException;
import javax.management.ObjectName;
import javax.management.MBeanServer;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.system.ConfigurationException;
import org.jboss.deployment.MainDeployerMBean;
import org.jboss.deployment.DeploymentInfo;
import org.jboss.deployment.DeploymentException;
import org.jboss.deployment.DeploymentSorter;
import org.jboss.system.server.ServerConfigImplMBean;
import org.jboss.logging.Logger;
import org.jboss.util.NullArgumentException;
import org.jboss.util.MuLong;
import org.jboss.util.MuBoolean;
import org.jboss.util.jmx.MBeanProxy;
/**
* An abstract support class for implementing a deployment scanner.
*
* Sub-class must implement {@link DeploymentScanner#scan}.
*
* @version $Revision: 1.1 $
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
public abstract class AbstractDeploymentScanner
extends ServiceMBeanSupport
implements DeploymentScanner, DeploymentScannerMBean
{
/** The scan period in milliseconds */
protected MuLong scanPeriod = new MuLong(5000);
/** True if period based scanning is enabled. */
protected MuBoolean scanEnabled = new MuBoolean(true);
/** A proxy to the main deployer. */
protected MainDeployerMBean deployer;
/** The scanner thread. */
protected ScannerThread scannerThread;
/** A helper for sorting deployments. */
protected DeploymentSorter sorter = new DeploymentSorter();
/
// DeploymentScanner //
/
/**
* Period must be >= 0.
*/
public void setScanPeriod(final long period)
{
if (period < 0)
throw new IllegalArgumentException("ScanPeriod must be >= 0; have: " +
period);
this.scanPeriod.set(period);
}
public long getScanPeriod()
{
return scanPeriod.longValue();
}
public void setScanEnabled(final boolean flag)
{
this.scanEnabled.set(flag);
}
public boolean isScanEnabled()
{
return scanEnabled.get();
}
/
// Scanner Thread//
/
/**
* Should use Timer/TimerTask instead? This has some issues with
* interaction with ScanEnabled attribute. ScanEnabled works only
* when starting/stopping.
*/
public class ScannerThread
extends Thread
{
/** We get our own logger. */
protected Logger log = Logger.getLogger(ScannerThread.class);
/** True if the scan loop should run. */
protected boolean enabled;
/** True if we are shutting down. */
protected boolean shuttingDown;
/** Lock/notify object. */
protected Object lock = new Object();
public ScannerThread(boolean enabled)
{
super("ScannerThread");
this.enabled = enabled;
}
public void setEnabled(boolean enabled)
{
this.enabled = enabled;
synchronized (lock) {
lock.notifyAll();
}
if (log.isDebugEnabled()) {
log.debug("Notified that enabled: " + enabled);
}
}
public void shutdown()
{
enabled = false;
shuttingDown = true;
synchronized (lock) {
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
> Can you please post some more details on your exact scenario, viz: Will try. > + is this a hot redeploy of Jetty, especially is it a hot redeploy >when some webapps were already deployed? Not a redeploy. > + have you modified your jetty jboss-service.xml file to include a > webapp (long shot, but I have to ask)? Yes, before there is / > + what code base are you running off? JBoss HEAD > + what kind of log trace do you see? I mailed that already but here you go again: 23:56:35,547 INFO [Jetty] ResourceHandler started in file:/C:/home/jason/workspace/jboss/jboss-all/build/output/jboss-3.0.0beta2/ 23:56:35,547 INFO [Jetty] Started ResourceHandler in WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] 23:56:35,547 INFO [Jetty] Started NotFoundHandler in WebApplicationContext[/,C:\home\jason\workspace\jboss\jboss-all\build\output\jboss-3.0.0beta2] 23:56:35,567 INFO [Jetty] Started SocketListener on 0.0.0.0:8080 23:56:35,567 ERROR [JettyService] multipule exceptions... 23:56:35,577 ERROR [JettyService] exception java.lang.ClassCastException: org.jboss.system.MBeanClassLoader at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) at org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) at org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) at org.mortbay.http.HttpContext.start(HttpContext.java:1420) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) at org.mortbay.http.HttpServer.start(HttpServer.java:186) at org.jboss.jetty.JettyService.startService(JettyService.java:236) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at org.jboss.system.ServiceController.start(ServiceController.java:360) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:331) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:211) at org.jboss.Main.boot(Main.java:127) at org.jboss.Main$1.run(Main.java:335) at java.lang.Thread.run(Thread.java:484) 23:56:35,577 INFO [JettyService] Started 23:56:35,577 INFO [MainDep
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Jason, Can you please post some more details on your exact scenario, viz: + is this a hot redeploy of Jetty, especially is it a hot redeploy when some webapps were already deployed? + have you modified your jetty jboss-service.xml file to include a webapp (long shot, but I have to ask)? + what code base are you running off? + what kind of log trace do you see? Jetty does not do anything with JSP unless we have got webapp contexts already registered when we receive a start. This could occur, for example, if you deployed Jetty, deployed some webapps, did a stop and restart on the Jetty service using JMX. Jan Scott M Stark wrote: > This is the start of the JettyService which is a subclass of > AbstractWebContainer. This is before the web app URLClassLoader > has been created. This does not occur until the > performDeploy(String path, String warUrl, WebDescriptorParser parser) > call. Apparently Jetty initializes the JSP servlet before this call > and its integration API expects a URLClassLoader. > > I don't know what web context is being started here as there really > is not one. Its probably some default setup that is irrelevant but > the Jetty guys will have to determine if that is the case. If need be > an empty URLClassLoader can be created for the startService > context. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, March 01, 2002 6:24 PM > Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and > MBeanClassLoader > > > >>java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >>org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >>org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >>org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> > org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >> > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. > java:365) > >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> > org.jboss.jetty.JettyService.startService(JettyService.java:236) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >> > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:779) > >>at $Proxy0.start(Unknown Source) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >> > org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl > oymentScanner.java:176) > >>at >> >> > org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy > mentScanner.java:138) > >>at >> >> > org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(Directo > ryDeploymentScanner.java:607) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >> > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav > a:779) >
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
To reproduce, add the following into the jetty jboss-service.xml: / I did not test that this happens on deployment. I copied jetty-plugin.sar to lib/jetty-plugin.jar and copied jboss-service.xml to jetty-service.xml. --jason Scott M Stark wrote: >This is the start of the JettyService which is a subclass of >AbstractWebContainer. This is before the web app URLClassLoader >has been created. This does not occur until the >performDeploy(String path, String warUrl, WebDescriptorParser parser) >call. Apparently Jetty initializes the JSP servlet before this call >and its integration API expects a URLClassLoader. > >I don't know what web context is being started here as there really >is not one. Its probably some default setup that is irrelevant but >the Jetty guys will have to determine if that is the case. If need be >an empty URLClassLoader can be created for the startService >context. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > >- Original Message - >From: "Jason Dillon" <[EMAIL PROTECTED]> >To: "Scott M Stark" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Friday, March 01, 2002 6:24 PM >Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and >MBeanClassLoader > > >>java.lang.ClassCastException: org.jboss.system.MBeanClassLoader >>at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) >>at >>org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) >>at >>org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) >>at >>org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) >>at >> >org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > >>at org.mortbay.http.HttpContext.start(HttpContext.java:1420) >>at >> >org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. >java:365) > >>at org.mortbay.http.HttpServer.start(HttpServer.java:186) >>at >> >org.jboss.jetty.JettyService.startService(JettyService.java:236) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav >a:779) > >>at $Proxy0.start(Unknown Source) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:343) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy3.start(Unknown Source) >>at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) >>at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) >>at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) >>at $Proxy2.deploy(Unknown Source) >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl >oymentScanner.java:176) > >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy >mentScanner.java:138) > >>at >> >org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(Directo >ryDeploymentScanner.java:607) > >>at >>org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >> >org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav >a:779) > >>at $Proxy0.start(Unknown Source) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:343) >>at >>org.jboss.system.ServiceController.start(ServiceController.java:360) >>at java.lang.reflect.Method.invoke(Native Method) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>
Re: [JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
Wow... a unique subject line... nice. Forums will like this too... --jason [EMAIL PROTECTED] wrote: >JBoss daily test results > >SUMMARY > >Number of tests run: 503 > > > >Successful tests: 494 > >Errors:4 > >Failures: 5 > > > > > >[time of test: 2 March 2002 2:57 GMT] >[java.version: 1.3.0] >[java.vendor: IBM Corporation] >[java.vm.version: 1.3.0] >[java.vm.name: Classic VM] >[java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] >[os.name: Linux] >[os.arch: x86] >[os.version: 2.4.9-21] > >See http://lubega.com for full details > >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. >Remember - if a test becomes broken after your changes - fix it or fix the test! > > > > > >DETAILS OF ERRORS > >[details not shown -as this makes the mail too big to reach the sf mailing list] > > > > >PS BEFORE you commit, run the test suite! > >Its really is easy, just use the ant target 'run-basic-testsuite' from the >build directory. > > >To just run the unit tests (they are quite quick): > >In the testsuite directory, >./build.sh tests-unit > > >You can run a single test case using: >./build.sh -Dtest=[XXXTestCase] one-test > >The XXXTestCase is the classname of the junit class to run. So, to run the >EJBSpecUnitTestCase use: >./build.sh -Dtest=EJBSpecUnitTestCase one-test > > >To run all tests within a package, use >./build.sh -Dtest=[package] test > >The package is name of the directory under the org/jboss/test directory that >contains the tests to run. So, to run the unit tests in the >org.jboss.test.security package use: >./build.sh -Dtest=security test > > > >Thanks for all your effort - we really do love you! > > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
JBoss daily test results SUMMARY Number of tests run: 503 Successful tests: 495 Errors:4 Failures: 4 [time of test: 2 March 2002 6:33 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
JBoss daily test results SUMMARY Number of tests run: 503 Successful tests: 495 Errors:4 Failures: 4 [time of test: 2 March 2002 5:47 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
JBoss daily test results SUMMARY Number of tests run: 503 Successful tests: 495 Errors:4 Failures: 4 [time of test: 2 March 2002 4:44 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
JBoss daily test results SUMMARY Number of tests run: 503 Successful tests: 495 Errors:4 Failures: 4 [time of test: 2 March 2002 3:35 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-21] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 2-March-2002
JBoss daily test results SUMMARY Number of tests run: 503 Successful tests: 494 Errors:4 Failures: 5 [time of test: 2 March 2002 2:57 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-21] See http://lubega.com for full details 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. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
This is the start of the JettyService which is a subclass of AbstractWebContainer. This is before the web app URLClassLoader has been created. This does not occur until the performDeploy(String path, String warUrl, WebDescriptorParser parser) call. Apparently Jetty initializes the JSP servlet before this call and its integration API expects a URLClassLoader. I don't know what web context is being started here as there really is not one. Its probably some default setup that is irrelevant but the Jetty guys will have to determine if that is the case. If need be an empty URLClassLoader can be created for the startService context. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 6:24 PM Subject: Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader > java.lang.ClassCastException: org.jboss.system.MBeanClassLoader > at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) > at > org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) > at > org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) > at > org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) > at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) > at org.mortbay.http.HttpContext.start(HttpContext.java:1420) > at > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. java:365) > at org.mortbay.http.HttpServer.start(HttpServer.java:186) > at org.jboss.jetty.JettyService.startService(JettyService.java:236) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:779) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:343) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) > at $Proxy3.start(Unknown Source) > at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) > at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) > at $Proxy2.deploy(Unknown Source) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDepl oymentScanner.java:176) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploy mentScanner.java:138) > at > org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(Directo ryDeploymentScanner.java:607) > at > org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at > org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:779) > at $Proxy0.start(Unknown Source) > at > org.jboss.system.ServiceController.start(ServiceController.java:343) > at > org.jboss.system.ServiceController.start(ServiceController.java:360) > at java.lang.reflect.Method.invoke(Native Method) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:331) > at org.jboss.system.server.ServerImpl.start(ServerImpl.java:211) > at org.jboss.Main.boot(Main.java:127) > at org.jboss.Main$1.run(Main.java:335) > at java.lang.Thread.run(Thread.java:484) > > --jason > ___
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
java.lang.ClassCastException: org.jboss.system.MBeanClassLoader at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:269) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:203) at org.mortbay.jetty.servlet.ServletHandler.start(ServletHandler.java:380) at org.mortbay.jetty.servlet.FilterHandler.start(FilterHandler.java:160) at org.mortbay.http.HttpContext.startHandlers(HttpContext.java:1449) at org.mortbay.http.HttpContext.start(HttpContext.java:1420) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:365) at org.mortbay.http.HttpServer.start(HttpServer.java:186) at org.jboss.jetty.JettyService.startService(JettyService.java:236) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:270) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:470) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:347) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:327) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:309) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy2.deploy(Unknown Source) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.deploy(DirectoryDeploymentScanner.java:176) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.scan(DirectoryDeploymentScanner.java:138) at org.jboss.deployment.scanner.DirectoryDeploymentScanner.startService(DirectoryDeploymentScanner.java:607) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:779) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:343) at org.jboss.system.ServiceController.start(ServiceController.java:360) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:331) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:211) at org.jboss.Main.boot(Main.java:127) at org.jboss.Main$1.run(Main.java:335) at java.lang.Thread.run(Thread.java:484) --jason Scott M Stark wrote: >Show the stack trace for the cast. The parent class loader of >every web context and request should be a URLClassLoader >as this is created by the AbstractWebContainer to establish >a unique ENC namespace. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > >- Original Message - >From: "Jason Dillon" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Friday, March 01, 2002 5:08 PM >Subject: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and >MBeanClassLoader > > >>Does anyone know why the Jasper JspSevlet thinks that its TCL is always >>a URLClassLoader? It takes the value from >>Thread.currentThread().getContextClassLoader() and casts it with out a >>care... does the same for getClass().getClassLoader()... >> >>It is assigning the value parentClassLoader, which is of type >>URLClassLoader... but then they have checks for if (parentClassLoader >>instanceof URLClassLoader). >> >>This is garbage... >> >>Anyways, I am seeing consistent ClassCastExceptions for >>MBeanClassLoader... which is not a URLClassLoader. My guess is that >>MBeanClassLoader could be a
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
Hopefully you can find something simple to fix this... Perhaps we can simply make a UCL and set the TCL inside JettyService: /** * The JSP engine (a.k.a Jasper)! * * The servlet container is responsible for providing a * URLClassLoader for the web application context Jasper * is being used in. Jasper will try get the Tomcat * ServletContext attribute for its ServletContext class * loader, if that fails, it uses the parent class loader. * In either case, it must be a URLClassLoader. * * @author Anil K. Vijendran * @author Harish Prabandham */ Is this spec that it must be a URLClassLoader? --jason Adrian Brock wrote: >No, I'm obviously talking rubbish again. > >I think I need to look at how Jetty does the >classloaders to figure this one out. > >At Scott's suggestion, JBossMX remembers the >context classloader from the MBean's registration and >uses it again during MBean invocation. It has to be >something to do with that. > >Regards, >Adrian > >>I can't speak for apache/jasper. >> >>But (I think) with JBossMX jasper gets the apps >>UnifiedClassLoader instead of JettyService's >>MBeanClassLoader. >> >>The "I think" is because I haven't actually verified >>this. >>I do know the WebIntegration tests don't have the JSP >>problems running under JBossMX that it does with the >>RI. >> >>Regards, >>Adrian >> >>>Does anyone know why the Jasper JspSevlet thinks >>> >>that >> >>>its TCL is always >>>a URLClassLoader? It takes the value from >>>Thread.currentThread().getContextClassLoader() and >>>casts it with out a >>>care... does the same for >>>getClass().getClassLoader()... >>> >>>It is assigning the value parentClassLoader, which >>> >>is >> >>>of type >>>URLClassLoader... but then they have checks for if >>>(parentClassLoader >>>instanceof URLClassLoader). >>> >>>This is garbage... >>> >>>Anyways, I am seeing consistent >>> >>ClassCastExceptions >> >>>for >>>MBeanClassLoader... which is not a URLClassLoader. >>> My guess is that >>>MBeanClassLoader could be a URLClassLoader, but >>> >>that >> >>>seems a bit artificial. >>> >>>Anybody know what is up with this? >>> >>>--jason >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>> >>https://lists.sourceforge.net/lists/listinfo/jboss-dev >> >>>lopment >>> > > > >_ >View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system ServiceConfigurator.java
User: user57
Date: 02/03/01 17:16:37
Modified:src/main/org/jboss/system ServiceConfigurator.java
Log:
o deal with those pesk JMX exceptions when setting an attribute
Revision ChangesPath
1.3 +36 -5 jboss-system/src/main/org/jboss/system/ServiceConfigurator.java
Index: ServiceConfigurator.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/system/ServiceConfigurator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ServiceConfigurator.java 1 Mar 2002 05:13:34 - 1.2
+++ ServiceConfigurator.java 2 Mar 2002 01:16:37 - 1.3
@@ -19,6 +19,7 @@
import java.util.LinkedList;
import java.util.ArrayList;
import java.util.Hashtable;
+
import javax.management.Attribute;
import javax.management.InstanceNotFoundException;
import javax.management.MBeanAttributeInfo;
@@ -27,6 +28,12 @@
import javax.management.MalformedObjectNameException;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
+import javax.management.MBeanException;
+import javax.management.ReflectionException;
+import javax.management.RuntimeOperationsException;
+import javax.management.RuntimeMBeanException;
+import javax.management.RuntimeErrorException;
+
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
@@ -45,7 +52,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* 20010830 marc fleury:
*
@@ -88,6 +95,30 @@
// Public ---
+ /** A helper to deal with those pesky JMX exceptions. */
+ private void setAttribute(ObjectName name, Attribute attr)
+ throws Exception
+ {
+ try {
+ server.setAttribute(name, attr);
+ }
+ catch (MBeanException e) {
+ throw e.getTargetException();
+ }
+ catch (ReflectionException e) {
+ throw e.getTargetException();
+ }
+ catch (RuntimeOperationsException e) {
+ throw e.getTargetException();
+ }
+ catch (RuntimeMBeanException e) {
+ throw e.getTargetException();
+ }
+ catch (RuntimeErrorException e) {
+ throw e.getTargetError();
+ }
+ }
+
/**
* Builds a string that consists of the configuration elements of
* the currently running MBeans registered in the server.
@@ -273,7 +304,7 @@
if (debug)
log.debug(attributeName + " set to " + value + " in " +
objectName);
- server.setAttribute(objectName, new Attribute(attributeName,
value));
+ setAttribute(objectName, new Attribute(attributeName, value));
break attrfound;
}//if name matches
@@ -312,7 +343,7 @@
if (mbeanRefName != null)
{
//if if doesn't exist or has wrong type, we'll get an exception
- server.setAttribute(objectName, new Attribute(mbeanRefName,
dependsObjectName));
+ setAttribute(objectName, new Attribute(mbeanRefName,
dependsObjectName));
} // end of if ()
}
//end of depends
@@ -350,7 +381,7 @@
} // end of for ()
if (dependsListName != null)
{
- server.setAttribute(objectName, new Attribute(dependsListName,
dependsListNames));
+ setAttribute(objectName, new Attribute(dependsListName,
dependsListNames));
} // end of if ()
}//end of depends-list
}
@@ -443,7 +474,7 @@
return false;
}
-
+
/**
* Check if the given method is a "setter" method.
*
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Show the stack trace for the cast. The parent class loader of every web context and request should be a URLClassLoader as this is created by the AbstractWebContainer to establish a unique ENC namespace. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 5:08 PM Subject: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader > Does anyone know why the Jasper JspSevlet thinks that its TCL is always > a URLClassLoader? It takes the value from > Thread.currentThread().getContextClassLoader() and casts it with out a > care... does the same for getClass().getClassLoader()... > > It is assigning the value parentClassLoader, which is of type > URLClassLoader... but then they have checks for if (parentClassLoader > instanceof URLClassLoader). > > This is garbage... > > Anyways, I am seeing consistent ClassCastExceptions for > MBeanClassLoader... which is not a URLClassLoader. My guess is that > MBeanClassLoader could be a URLClassLoader, but that seems a bit artificial. > > Anybody know what is up with this? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
No, I'm obviously talking rubbish again. I think I need to look at how Jetty does the classloaders to figure this one out. At Scott's suggestion, JBossMX remembers the context classloader from the MBean's registration and uses it again during MBean invocation. It has to be something to do with that. Regards, Adrian > I can't speak for apache/jasper. > > But (I think) with JBossMX jasper gets the apps > UnifiedClassLoader instead of JettyService's > MBeanClassLoader. > > The "I think" is because I haven't actually verified > this. > I do know the WebIntegration tests don't have the JSP > problems running under JBossMX that it does with the > RI. > > Regards, > Adrian > > > Does anyone know why the Jasper JspSevlet thinks > that > > its TCL is always > > a URLClassLoader? It takes the value from > > Thread.currentThread().getContextClassLoader() and > > casts it with out a > > care... does the same for > > getClass().getClassLoader()... > > > > It is assigning the value parentClassLoader, which > is > > of type > > URLClassLoader... but then they have checks for if > > (parentClassLoader > > instanceof URLClassLoader). > > > > This is garbage... > > > > Anyways, I am seeing consistent > ClassCastExceptions > > for > > MBeanClassLoader... which is not a URLClassLoader. > > My guess is that > > MBeanClassLoader could be a URLClassLoader, but > that > > seems a bit artificial. > > > > Anybody know what is up with this? > > > > --jason > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-dev > > > lopment > _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523239 ] jbosscmp-jdbc.xml problem
Bugs item #523239, was opened at 2002-02-27 02:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=523239&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Marcel Ammerlaan (mam) Assigned to: Dain Sundstrom (dsundstrom) Summary: jbosscmp-jdbc.xml problem Initial Comment: When the tag is included in jbosscmp-jdbc.xml an exception is thrown when a bean is added to a relation. The exception is: 03:18:41,539 ERROR [GlobalTxEntityMap] Store failed on entity: 1 javax.ejb.EJBException: Could insert relations into ABean_b_BBean_a Embedded Exception null at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertRelationsCommand.execute(JDBCInsertRelationsCommand.java:78) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.insertRelations(JDBCStoreManager.java:481) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchronizeRelationData(JDBCStoreManager.java:443) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStoreManager.java:424) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenceManager.java:428) at org.jboss.ejb.EntityContainer.storeEntity(EntityContainer.java:677) at org.jboss.ejb.GlobalTxEntityMap.syncEntities(GlobalTxEntityMap.java:89) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanup.beforeCompletion(GlobalTxEntityMap.java:158) at org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1317) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:325) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:190) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:308) at org.jboss.ejb.Container.invoke(Container.java:668) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:364) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.getJDBCTypes(SQLUtil.java:422) at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.getColumnNamesClause(SQLUtil.java:94) at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.getColumnNamesClause(SQLUtil.java:85) at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertRelationsCommand.getSQL(JDBCInsertRelationsCommand.java:95) at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertRelationsCommand.execute(JDBCInsertRelationsCommand.java:60) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.insertRelations(JDBCStoreManager.java:481) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.synchronizeRelationData(JDBCStoreManager.java:443) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStoreManager.java:424) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity(CMPPersistenceManager.java:428) at org.jboss.ejb.EntityContainer.storeEntity(EntityContainer.java:677) at org.jboss.ejb.GlobalTxEntityMap.syncEntities(GlobalTxEntityMap.java:89) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanup.beforeCompletion(GlobalTxEntityMap.java:158) at org.jboss.tm.TxCapsule.doBeforeCompletion(TxCapsule.java:1317) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:325) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:190) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:308) at org.jboss.ejb.Container.invoke(Container.java:668) at com.sun.management.jmx.MBea
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/cmr/ejb CMRBugBean.java CMRBugManagerBean.java
User: d_jencks
Date: 02/03/01 17:02:58
Added: src/main/org/jboss/test/cmp2/cmr/ejb CMRBugBean.java
CMRBugManagerBean.java
Log:
Testcase for bugs 523627, making sure changes in PostCreate are written to db, and
bug 523239, a problem with cmr relationships (at least) when using xdoclet generated
jbosscmp-jdbc.xml. The post create is fixed, the cmr relationship problem is not.
Revision ChangesPath
1.1 jbosstest/src/main/org/jboss/test/cmp2/cmr/ejb/CMRBugBean.java
Index: CMRBugBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*
*/
package org.jboss.test.cmp2.cmr.ejb;
import java.util.Collection;
import javax.ejb.CreateException;
import javax.ejb.EJBException;
import javax.ejb.EntityBean;
import javax.ejb.EntityContext;
import org.jboss.test.cmp2.cmr.interfaces.CMRBugEJBLocal;
/**
* class CMRBugBean demonstrates bug 523627. CMR fields may get
changed
* in ejbPostCreate, so newly created entities must be marked as needing ejbSave.
* Currently this is done by putting them in GlobalTxEntityMap.
*
* @author mailto:[EMAIL PROTECTED]";>Michael Newcomb
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @version 1.0
*
* @ejb:bean name="CMRBugEJB"
* local-jndi-name="LocalReadOnly"
* view-type="local"
* type="CMP"
* cmp-version="2.x"
* primkey-field="id"
* reentrant="true"
* schema="CMRBug"
* @ejb:pk class="java.lang.String"
* @ejb:finder signature="java.util.Collection findAll()"
* query="select object(cmr_bug) from CMRBug as cmr_bug"
* @jboss:create-table create="true"
* @jboss:remove-table remove="true"
*/
public abstract class CMRBugBean
implements EntityBean
{
private EntityContext context;
/**
* Describe getId method here.
*
* @return a String value
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract String getId();
/**
* Describe setId method here.
*
* @param id a String value
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract void setId(String id);
/**
* Describe getDescription method here.
*
* @return a String value
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract String getDescription();
/**
* Describe setDescription method here.
*
* @param description a String value
* @ejb:persistent-field
* @ejb:interface-method
*/
public abstract void setDescription(String description);
/**
* Describe getParent method here.
*
* @return a CMRBugEJBLocal value
* @ejb:interface-method
* @ejb:relation name="CMRBug-CMRBug"
* role-name="parent"
* cascade-delete="yes"
*/
public abstract CMRBugEJBLocal getParent();
/**
* Describe setParent method here.
*
* @param parent a CMRBugEJBLocal value
* @ejb:interface-method
*/
public abstract void setParent(CMRBugEJBLocal parent);
/**
* Describe getChildren method here.
*
* @return a Collection value
* @ejb:interface-method
* @ejb:relation name="CMRBug-CMRBug"
* role-name="children"
* multiple="yes"
*/
public abstract Collection getChildren();
/**
* Describe setChildren method here.
*
* @param children a Collection value
* @ejb:interface-method
*/
public abstract void setChildren(Collection children);
/**
* Describe addChild method here.
*
* @param child a CMRBugEJBLocal value
* @return a boolean value
* @ejb:interface-method
*/
public boolean addChild(CMRBugEJBLocal child)
{
try
{
Collection children = getChildren();
return children.add(child);
}
catch (Exception e)
{
throw new EJBException(e);
}
}
/**
* Describe removeChild method here.
*
* @param child a CMRBugEJBLocal value
* @return a boolean value
* @ejb:interface-method
*/
public boolean removeChild(CMRBugEJBLocal child)
{
try
{
Collection children = getChildren();
return children.remove(child);
}
catch (Exception e)
{
throw new EJBException(e);
}
}
// --
// EntityBean methods
//
/**
* Describe ejbCreate method here.
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/cmr/ejb - New directory
User: d_jencks Date: 02/03/01 17:00:15 jbosstest/src/main/org/jboss/test/cmp2/cmr/ejb - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: d_jencks
Date: 02/03/01 17:02:58
Modified:.build.xml
Log:
Testcase for bugs 523627, making sure changes in PostCreate are written to db, and
bug 523239, a problem with cmr relationships (at least) when using xdoclet generated
jbosscmp-jdbc.xml. The post create is fixed, the cmr relationship problem is not.
Revision ChangesPath
1.82 +36 -1 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.81
retrieving revision 1.82
diff -u -r1.81 -r1.82
--- build.xml 1 Mar 2002 02:20:03 - 1.81
+++ build.xml 2 Mar 2002 01:02:57 - 1.82
@@ -27,7 +27,7 @@
-
+
@@ -480,6 +480,30 @@
mergedir="${source.resources}/jmx/eardeployment/b/"/>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -1766,6 +1790,17 @@
includes="net/**/*.*"/>
+
+
+
+
+
+
+
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/cmr/test CMRPostCreatesWrittenUnitTestCase.java
User: d_jencks
Date: 02/03/01 17:02:58
Added: src/main/org/jboss/test/cmp2/cmr/test
CMRPostCreatesWrittenUnitTestCase.java
Log:
Testcase for bugs 523627, making sure changes in PostCreate are written to db, and
bug 523239, a problem with cmr relationships (at least) when using xdoclet generated
jbosscmp-jdbc.xml. The post create is fixed, the cmr relationship problem is not.
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/cmp2/cmr/test/CMRPostCreatesWrittenUnitTestCase.java
Index: CMRPostCreatesWrittenUnitTestCase.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*
*/
package org.jboss.test.cmp2.cmr.test;
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
import java.util.Iterator;
import java.util.Map;
import java.util.SortedMap;
import java.util.TreeMap;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import org.apache.log4j.Category;
import junit.framework.*;
import org.jboss.test.JBossTestCase;
import org.jboss.test.cmp2.cmr.interfaces.CMRBugManagerEJB;
import org.jboss.test.cmp2.cmr.interfaces.CMRBugManagerEJBHome;
/**
* Describe class CMRPostCreatesWrittenUnitTestCase here.
* This tests directly for bug 523627 and is based on the test case supplied by
* Michael Newcomb. It tests whether changes made in ejbPostCreate are committed.
* It also tests indirectly for bug 523239, since it uses xdoclet. It reports the
same
* error as seen in bug 523239, from GlobalTxEntityMap.
*
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @version 1.0
*/
public class CMRPostCreatesWrittenUnitTestCase extends JBossTestCase
{
public CMRPostCreatesWrittenUnitTestCase(String name)
{
super(name);
}
public static Test suite() throws Exception
{
return getDeploySetup(CMRPostCreatesWrittenUnitTestCase.class,
"cmr-postcreateswritten.jar");
}
public void testCMRWrittenAfterPostCreate() throws Exception
{
getLog().debug("looking up CMRBugManager");
Object ref = getInitialContext().lookup("CMRBugManager");
getLog().debug("found CMRBugManager");
CMRBugManagerEJBHome home = (CMRBugManagerEJBHome)
PortableRemoteObject.narrow(ref, CMRBugManagerEJBHome.class);
getLog().debug("creating CMRBugManagerEJB");
CMRBugManagerEJB cmrBugManager = home.create();
getLog().debug("created CMRBugManagerEJB");
SortedMap cmrBugs = new TreeMap();
cmrBugs.put("1", "one");
cmrBugs.put("1.1", "one.one");
cmrBugs.put("1.2", "one.two");
cmrBugs.put("1.3", "one.three");
getLog().debug("creating " + cmrBugs.size() + " CMR bugs");
cmrBugManager.createCMRBugs(cmrBugs);
getLog().debug("created " + cmrBugs.size() + " CMR bugs");
Iterator i = cmrBugs.entrySet().iterator();
while (i.hasNext())
{
Map.Entry entry = (Map.Entry) i.next();
String[] parentIdAndDescription =
cmrBugManager.getParentFor((String) entry.getKey());
if (!entry.getKey().equals("1"))
{
assertTrue("Child has not Parent! cmr post create updates NOT WRITTEN! "
+ entry.getKey(),
parentIdAndDescription != null);
} // end of if ()
String parentMsg = parentIdAndDescription == null ? " has no parent" :
(" parent is " + parentIdAndDescription[0] + "-" +
parentIdAndDescription[1]);
getLog().debug(entry.getKey() + "-" + entry.getValue() + parentMsg);
}
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar protocol is not working with security manager
You can create a custom security policy, but this requires a modification of the JDK jre/lib/security/java.security file which many will balk at. I don't want to tweak the VM installation to use JBoss with a security manager. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 2:53 PM Subject: Re: [JBoss-dev] njar protocol is not working with security manager > > > > > >Its not reasonable to force the use of 1.4 at this point so the > >first point is irrelevant. We have to be able to run under a > >security manager with 3.0 with JDK 1.3. > > > > That is not what I meant. I was under the impression that a SM could > still be used under 1.3, but would not be "spec compliant" (whatever > that means) as someone mentiond. > > --jason > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: CVSROOT modules
Sorry, forgot about that. --jason Trevor Squires wrote: > User: squirest > Date: 02/03/01 16:12:06 > > Modified:.modules > Log: > jbossmx needs gnu and bcel (lower case) > > Revision ChangesPath > 1.102 +2 -1 CVSROOT/modules > > Index: modules > === > RCS file: /cvsroot/jboss/CVSROOT/modules,v > retrieving revision 1.101 > retrieving revision 1.102 > diff -u -r1.101 -r1.102 > --- modules 28 Feb 2002 21:00:07 - 1.101 > +++ modules 2 Mar 2002 00:12:06 - 1.102 > @@ -208,13 +208,14 @@ > > _jboss-mx-thirdparty-a \ > thirdparty/xml \ > +thirdparty/gnu \ > thirdparty/oswego \ > thirdparty/junit \ > thirdparty/jdom \ > thirdparty/sun/jmx \ > thirdparty/sun/jaxp \ > thirdparty/apache/log4j \ > -thirdparty/apache/BCEL > +thirdparty/apache/bcel > > _jboss-mx-modules -a \ > _jboss-mx_build \ > > > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/cmr/test - New directory
User: d_jencks Date: 02/03/01 17:00:15 jbosstest/src/main/org/jboss/test/cmp2/cmr/test - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/cmp2/cmr - New directory
User: d_jencks Date: 02/03/01 16:59:51 jbosstest/src/main/org/jboss/test/cmp2/cmr - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoad
I can't speak for apache/jasper. But (I think) with JBossMX jasper gets the apps UnifiedClassLoader instead of JettyService's MBeanClassLoader. The "I think" is because I haven't actually verified this. I do know the WebIntegration tests don't have the JSP problems running under JBossMX that it does with the RI. Regards, Adrian > Does anyone know why the Jasper JspSevlet thinks that > its TCL is always > a URLClassLoader? It takes the value from > Thread.currentThread().getContextClassLoader() and > casts it with out a > care... does the same for > getClass().getClassLoader()... > > It is assigning the value parentClassLoader, which is > of type > URLClassLoader... but then they have checks for if > (parentClassLoader > instanceof URLClassLoader). > > This is garbage... > > Anyways, I am seeing consistent ClassCastExceptions > for > MBeanClassLoader... which is not a URLClassLoader. > My guess is that > MBeanClassLoader could be a URLClassLoader, but that > seems a bit artificial. > > Anybody know what is up with this? > > --jason > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-dev > lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=10040 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jetty, Jasper JspServlet, URLClassLoader and MBeanClassLoader
Does anyone know why the Jasper JspSevlet thinks that its TCL is always a URLClassLoader? It takes the value from Thread.currentThread().getContextClassLoader() and casts it with out a care... does the same for getClass().getClassLoader()... It is assigning the value parentClassLoader, which is of type URLClassLoader... but then they have checks for if (parentClassLoader instanceof URLClassLoader). This is garbage... Anyways, I am seeing consistent ClassCastExceptions for MBeanClassLoader... which is not a URLClassLoader. My guess is that MBeanClassLoader could be a URLClassLoader, but that seems a bit artificial. Anybody know what is up with this? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: squirest Date: 02/03/01 16:12:06 Modified:.modules Log: jbossmx needs gnu and bcel (lower case) Revision ChangesPath 1.102 +2 -1 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.101 retrieving revision 1.102 diff -u -r1.101 -r1.102 --- modules 28 Feb 2002 21:00:07 - 1.101 +++ modules 2 Mar 2002 00:12:06 - 1.102 @@ -208,13 +208,14 @@ _jboss-mx-thirdparty-a \ thirdparty/xml \ +thirdparty/gnu \ thirdparty/oswego \ thirdparty/junit \ thirdparty/jdom \ thirdparty/sun/jmx \ thirdparty/sun/jaxp \ thirdparty/apache/log4j \ -thirdparty/apache/BCEL +thirdparty/apache/bcel _jboss-mx-modules -a \ _jboss-mx_build \ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty JettyService.java
User: user57
Date: 02/03/01 16:03:57
Modified:jetty/src/main/org/jboss/jetty JettyService.java
Log:
o replace printStackTrace with logging
o special handling for MultiException on start, since it does not
implement a proper printStackTrace method...
Revision ChangesPath
1.53 +26 -5 contrib/jetty/src/main/org/jboss/jetty/JettyService.java
Index: JettyService.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JettyService.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- JettyService.java 24 Feb 2002 05:08:29 - 1.52
+++ JettyService.java 2 Mar 2002 00:03:56 - 1.53
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JettyService.java,v 1.52 2002/02/24 05:08:29 janb Exp $
+// $Id: JettyService.java,v 1.53 2002/03/02 00:03:56 user57 Exp $
//--
@@ -17,6 +17,7 @@
import java.io.InputStream;
import java.net.URL;
+import java.util.Iterator;
import javax.management.MBeanRegistration;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -27,10 +28,11 @@
import org.jboss.web.AbstractWebContainer.WebDescriptorParser;
import org.jboss.web.AbstractWebContainer;
import org.jboss.web.WebApplication;
+
import org.mortbay.util.jmx.CodeMBean;
import org.mortbay.util.jmx.LogMBean;
import org.mortbay.util.Log;
-
+import org.mortbay.util.MultiException;
//--
@@ -38,7 +40,7 @@
* A service to launch jetty from JMX.
*
* @author mailto:[EMAIL PROTECTED]";>Julian Gosnell
- * @version $Revision: 1.52 $
+ * @version $Revision: 1.53 $
*/
public class JettyService
@@ -212,6 +214,17 @@
// 'service' interface
//
+ /**
+ * mex should implement a better printStackTrace...
+ */
+ protected void log(MultiException e)
+ {
+ log.error("multipule exceptions...");
+ Iterator iter = e.getExceptions().iterator();
+ while (iter.hasNext()) {
+log.error("exception", (Exception)iter.next());
+ }
+ }
protected boolean _started=false;
@@ -223,14 +236,22 @@
if (!isInitialised())
{
- try {ensureService();} catch (Exception e) {e.printStackTrace();} // TODO
+ try {ensureService();} catch (Exception e) { log.error("operation failed",
e); }
}
else
_log.warn("Jetty has already been initialised");
if (!isStarted())
{
- try{_jetty.start();} catch (Exception e){e.printStackTrace();} // TODO
+ try {
+ _jetty.start();
+ }
+ catch (MultiException e) {
+ log(e);
+ }
+ catch (Exception e) {
+ log.error("operation failed", e);
+ }
_started=true;
}
else
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging
> Ohhh my baby is grown up, it is not even mine any > more. > > I got a tear running down my cheek, snnniff! > > this is great news, how about the speed? > > marcf Speed is fine. On my pc about 440 secs for both the RI and JBossMX on the testsuite. We improved by 10-20 secs this week, is that Dain's new compiler? JMX speed is NOT important for ejb. If you do intensive JMX processing we are much better than the RI, but who does that? If you want figures try cd jboss-all/jmx ./build.sh test-performance NOTE: We are skewed for invoke(), registration takes longer. I also want to say, this is down to Trevor Squires and Juha. I've mostly been doing the spade work. They got all the fun :-) Regards, Adrian _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=9653 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system build.xml
User: user57 Date: 02/03/01 15:26:08 Modified:.build.xml Log: o add todo, will fix in others soon Revision ChangesPath 1.6 +47 -2 jboss-system/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-system/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 28 Feb 2002 04:08:05 - 1.5 +++ build.xml 1 Mar 2002 23:26:08 - 1.6 @@ -12,7 +12,7 @@ - + @@ -151,6 +151,7 @@ + @@ -189,6 +190,19 @@ + + + + + + + + + + @@ -393,7 +407,7 @@ + depends="docs-api, docs-todo"/> + + + + + + + + + + + + + + + + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerConfigLocator.java
User: user57
Date: 02/03/01 15:24:39
Added: src/main/org/jboss/system/server ServerConfigLocator.java
Log:
o helper to get a proxy to ServerConfig instance
Revision ChangesPath
1.1
jboss-system/src/main/org/jboss/system/server/ServerConfigLocator.java
Index: ServerConfigLocator.java
===
/***
* *
* JBoss: The OpenSource J2EE WebOS *
* *
* Distributable under LGPL license. *
* See terms of license at gnu.org. *
* *
***/
package org.jboss.system.server;
import javax.management.ObjectName;
import org.jboss.util.jmx.MBeanProxy;
/**
* A helper for locating the {@link ServerConfig} instance
* for the running server.
*
* @version $Revision: 1.1 $
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
*/
public class ServerConfigLocator
{
private static volatile ServerConfig instance = null;
public static ServerConfig locate()
{
if (instance == null) {
instance = (ServerConfig)
MBeanProxy.create(ServerConfig.class,
ServerConfigImplMBean.OBJECT_NAME);
}
return instance;
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.deployment.scanner.DeploymentScanner
Yup. --jason marc fleury wrote: >turn off the brain. > >try and run the stuff off of http. > >fix what doesn't work. > >GOt that? > >marcf > >"I would like to be ..." >-- Groovetech DJ 2001 -- > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: contrib/jboss.net/src/main/org/jboss/net/axis/server AxisService.java AxisServiceMBean.java Constants.java
What are you trying to do that won't let you simply deploy your fake war
with the main deployer and let it take care of finding the web deployer??
Maybe you need a generally useful service we should add to MainDeployer??
david jencks
On 2002.03.01 17:12:58 -0500 Dr. Christoph Georg Jung wrote:
> User: cgjung
> Date: 02/03/01 14:12:57
>
> Modified:jboss.net/src/main/org/jboss/net/axis/server
> AxisService.java AxisServiceMBean.java
> Constants.java
> Log:
> this one is for peter ... patched web-container access to go through
> the maindeployer (still dirty) and
> switched authentication off for now since Jetty does still not as we
> like. I get hang-ups in deploying the
> combined ejb/wsr test, but at least addr.wsr works again. Happy
> weekend.
>
> Revision ChangesPath
> 1.13 +28 -27
>contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java
>
> Index: AxisService.java
> ===
> RCS file:
>/cvsroot/jboss/contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- AxisService.java28 Feb 2002 08:01:27 - 1.12
> +++ AxisService.java1 Mar 2002 22:12:57 - 1.13
> @@ -5,7 +5,7 @@
> * See terms of license at gnu.org.
> */
>
> -// $Id: AxisService.java,v 1.12 2002/02/28 08:01:27 cgjung Exp $
> +// $Id: AxisService.java,v 1.13 2002/03/01 22:12:57 cgjung Exp $
>
>package org.jboss.net.axis.server;
>
> @@ -31,6 +31,7 @@
>import org.jboss.naming.Util;
>import org.jboss.metadata.MetaData;
>import org.jboss.system.server.ServerConfigImplMBean;
> +import org.jboss.deployment.DeployerMBean;
>
>import org.w3c.dom.Document;
>import org.w3c.dom.Element;
> @@ -62,12 +63,13 @@
>
>import java.util.Map;
>import java.util.Iterator;
> +import java.util.Collection;
>
>/**
> * A deployer service that installs and manages Axis within JMX.
> * @created 27. September 2001
> * @author mailto:[EMAIL PROTECTED]";>Christoph G.
> Jung
> - * @version $Revision: 1.12 $
> + * @version $Revision: 1.13 $
> * Change notes:
> *
> * 01.02.02: CGJ, Adapted to jboss3.0.0DR1 deployment
> changes. Arrgh!
> @@ -99,6 +101,9 @@
> /** the axis engines */
> final static Map axisServerMap=new java.util.HashMap();
>
> + /** the web deployer that hosts our servlet */
> + DeployerMBean webDeployer;
> +
> /** default */
> public AxisService()
> {
> @@ -199,6 +204,22 @@
>
> URL myUrl=appDir.toURL();
> myDeploymentInfo=new DeploymentInfo(myUrl,null);
> + myDeploymentInfo.url=new URL("http://net.jboss.org/fake.war";);
> +
> + Iterator allDeployers=((Collection)
> server.invoke(MainDeployerMBean.OBJECT_NAME,
> +"listDeployers",
> +new Object[0],
> +new String[0])).iterator();
> +
> + while(allDeployers.hasNext() && webDeployer==null) {
> + DeployerMBean nextBean=(DeployerMBean) allDeployers.next();
> + if(nextBean.accepts(myDeploymentInfo)) {
> + webDeployer=nextBean;
> + }
> + }
> +
> + if(webDeployer!=null) {
> +
> myDeploymentInfo.localUrl=myUrl;
>
> try
> @@ -250,10 +271,7 @@
>
> // Call the war deployer through the JMX server to initialise
> // and deploy the info
> - server.invoke(MainDeployerMBean.OBJECT_NAME,
> -"deploy",
> -new Object[] {myDeploymentInfo},
> -new String[]
{"org.jboss.deployment.DeploymentInfo"});
> + webDeployer.start(myDeploymentInfo);
>
> try
> {
> @@ -266,6 +284,9 @@
> }
> catch (Exception e) {log.error("Could not register with
> MainDeployer", e);
> }
> + } else {
> + throw new Exception(Constants.CANNOT_FIND_WEB_DEPLOYER);
> + }
>
> }
>
> @@ -314,10 +335,7 @@
> log.getCategory().l7dlog(Priority.INFO,ABOUT_TO_UNDEPLOY_0,new
> Object[]
> {myDeploymentInfo},null);
>
> - server.invoke(MainDeployerMBean.OBJECT_NAME,
> - "undeploy",
> - new Object[] {myDeploymentInfo},
> - new String[]
> {"org.jboss.deployment.DeploymentInfo"});
> + webDeployer.stop(myDeploymentInfo);
>
> } catch (Exception e)
> {
> @@ -345,23 +363,6 @@
> return (AxisServer) axisServerMap.get(context);
> }
>
> - //
> - // war deployer plug
> - //--
[JBoss-dev] CVS update: thirdparty/apache/BCEL/lib bcel.jar
User: user57 Date: 02/03/01 14:36:30 Removed: apache/BCEL/lib bcel.jar Log: ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] org.jboss.deployment.scanner.DeploymentScanner
turn off the brain. try and run the stuff off of http. fix what doesn't work. GOt that? marcf "I would like to be ..." -- Groovetech DJ 2001 -- ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
On 2002.03.01 17:45:33 -0500 Jason Dillon wrote: > Does the main jboss-service.xml need a ? If not why is > it there? It seems like this loads the libraries required by the > service... I don't get why you think it should not be used... can you > explain? > > --jason > mmm. That one we need unless we can first get the scanner to scan lib before we deploy the main jboss-service.xml. I originally thought that _every_ config file should have these classpath elements for _all_ their classes and tried to implement such a scheme. However, marc said "too complicated" and more important "creates an irrelevant dependency on packaging rather than classes" and took a lot of it out (i've come to view this as a good thing). I'm ambivalent. On the one hand I'd like config to be self-documenting about where their classes come from, on the other hand it's a damn nuisance and too easy to break. david jencks > > David Jencks wrote: > > >Are you sure you need the element at all? Unless you > are > >loading from an http: url you should be fine by removing this element > >entirely. I guess I better go through everything and do this... I > already > >got a lot of messages from them being in the db config examples. > > > >david jencks > > > >On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: > > > >>it would be kinda nice if the url's in the service.xml file were > relative > >>to > >>the service.xml file. Do I make sense?? so if the service.xml files > is: > >>/jboss/server/default/deploy/jbossmq-service.xml > >>To load all the jboss/lib jars : > >> > >>To load all the jars in the server's lib dirctory: > >>/jboss/server/default/lib > >> > >> > >>Regards, > >>Hiram > >> > >>>From: Jason Dillon <[EMAIL PROTECTED]> > >>>To: David Jencks <[EMAIL PROTECTED]> > >>>CC: [EMAIL PROTECTED] > >>>Subject: Re: [JBoss-dev] Property access in *service.xml and relative > >>> > >>paths > >> > >>>Date: Thu, 28 Feb 2002 19:51:32 -0800 > >>> > >>>I sent mail on this before I commited the layout change. It has todo > >>>with which directory/url do we use to qualify relative paths. It also > >>>has todo with allow a global and per-server config library directory. > >>> > >>>--jason > >>> > >>> > >>>David Jencks wrote: > >>> > On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: > > >I was thinking that a solution to the problem that MD now has due to > > > >>the > >> > >layout changes that I made WRT relatives paths could be solved by > >forcing users to be explicit about which path they which to use (ie. > > > >>not > >> > >allowing relative paths). > > > What are these problems? I haven't noticed any. Using .../> > > can > cause problems, but it is almost always better to just leave the tag > > >>out. > >> > david jencks > > > >To make this work we need to expose some system property access > inside > >of the *service.xml files... probably as an attribute value subst > and > > > >>an > >> > >element... for example: > > > > > > > > > > > > > > > > > > > > > >Which could then be used in config elements later in the file... > > > >And to finally solve the two lib problem... just more than one > > > >>classpath > >> > >(if that isn't the case already): > > > > > > > > > >This would prefer libs from inside jboss.server.home.dir/lib before > >jboss.home.dir/lib > > > >--jason > > > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > >>> > >>> > >>>___ > >>>Jboss-development mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > >>> > >> > >> > >> > >>_ > >>Get your FREE download of MSN Explorer at > >>http://explorer.msn.com/intl.asp. > >> > >> > >> > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx build.xml
User: user57 Date: 02/03/01 14:37:56 Modified:.build.xml Log: o BCEL -> bcel o using vendor prefix Revision ChangesPath 1.26 +6 -6 jmx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jmx/build.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- build.xml 1 Mar 2002 19:25:56 - 1.25 +++ build.xml 1 Mar 2002 22:37:56 - 1.26 @@ -12,7 +12,7 @@ - + @@ -120,10 +120,10 @@ - - - - + + + + @@ -135,7 +135,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
What would be cool is if jboss eventually used a ClassLoader system that allowed service classes to be self-contained. In other words, jbossmq-service.xml could have: Only the classes explicitly exported would be made available to the other services. This would let jbossmq use ver 1.x of concurrent.jar while another service used version 2.x of concurrent.jar since it's classes were not exported. Just an idea. Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >To: Hiram Chirino <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], >[EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Property access in *service.xml and relative paths >Date: Fri, 01 Mar 2002 14:55:28 -0800 > >Currently the primary jboss-service.xml does exactly this, so Dave might >not be including in other files, since this one already >does it. > >I hope that eventually we use explicit jar refs, so we don't bloat the >heap with unused libs. > >--jason > > >Hiram Chirino wrote: > >>How does the server know where the jars are if the is >>not there. Does it just load up all the lib/* jars?? >> >>Regards, >>Hiram >> >> >>>From: David Jencks <[EMAIL PROTECTED]> >>>To: Hiram Chirino <[EMAIL PROTECTED]> >>>CC: [EMAIL PROTECTED], [EMAIL PROTECTED] >>>Subject: Re: [JBoss-dev] Property access in *service.xml and relative >>>paths >>>Date: Fri, 1 Mar 2002 10:39:55 -0500 >>> >>>Are you sure you need the element at all? Unless you >>>are >>>loading from an http: url you should be fine by removing this element >>>entirely. I guess I better go through everything and do this... I >>>already >>>got a lot of messages from them being in the db config examples. >>> >>>david jencks >>> >>>On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: >>> > it would be kinda nice if the url's in the service.xml file were >>>relative >>> > to >>> > the service.xml file. Do I make sense?? so if the service.xml >>>files is: >>> > /jboss/server/default/deploy/jbossmq-service.xml >>> > To load all the jboss/lib jars : >>> > >>> > To load all the jars in the server's lib dirctory: >>> > /jboss/server/default/lib >>> > >>> > >>> > Regards, >>> > Hiram >>> > >>> > >From: Jason Dillon <[EMAIL PROTECTED]> >>> > >To: David Jencks <[EMAIL PROTECTED]> >>> > >CC: [EMAIL PROTECTED] >>> > >Subject: Re: [JBoss-dev] Property access in *service.xml and relative >>> > paths >>> > >Date: Thu, 28 Feb 2002 19:51:32 -0800 >>> > > >>> > >I sent mail on this before I commited the layout change. It has todo >>> > >with which directory/url do we use to qualify relative paths. It >>>also >>> > >has todo with allow a global and per-server config library directory. >>> > > >>> > >--jason >>> > > >>> > > >>> > >David Jencks wrote: >>> > > >>> > >>On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >>> > >> >>> > >>>I was thinking that a solution to the problem that MD now has >>>due to >>> > the >>> > >>>layout changes that I made WRT relatives paths could be solved by >>> > >>>forcing users to be explicit about which path they which to use >>>(ie. >>> > not >>> > >>>allowing relative paths). >>> > >>> >>> > >> >>> > >>What are these problems? I haven't noticed any. Using >>.../> >>> > >>> > >>can >>> > >>cause problems, but it is almost always better to just leave the tag >>> > out. >>> > >> >>> > >>david jencks >>> > >> >>> > >> >>> > >>>To make this work we need to expose some system property access >>>inside >>> > >>>of the *service.xml files... probably as an attribute value >>>subst and >>> > an >>> > >>>element... for example: >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>>Which could then be used in config elements later in the file... >>> > >>> >>> > >>>And to finally solve the two lib problem... just more than one >>> > classpath >>> > >>>(if that isn't the case already): >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>>This would prefer libs from inside jboss.server.home.dir/lib before >>> > >>>jboss.home.dir/lib >>> > >>> >>> > >>>--jason >>> > >>> >>> > >>> >>> > >>>___ >>> > >>>Jboss-development mailing list >>> > >>>[EMAIL PROTECTED] >>> > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> > >>> >>> > >>> >>> > > >>> > > >>> > > >>> > >___ >>> > >Jboss-development mailing list >>> > >[EMAIL PROTECTED] >>> > >https://lists.sourceforge.net/lists/listinfo/jboss-development >>> > >>> > >>> > >>> > >>> > _ >>> > Get your FREE download of MSN Explorer at >>> > http://explorer.msn.com/intl.asp.; >>> > >>> > >>> > >> >> >> >> >> >>_ >>Send and receive Hotmail on your mobile device: http://mobile.msn.com > > > _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
[JBoss-dev] CVS update: thirdparty/apache/bcel - Imported sources
User: user57 Date: 02/03/01 14:35:44 Log: Status: Vendor Tag: apache Release Tags: bcel_unknown N thirdparty/apache/bcel/LICENSE N thirdparty/apache/bcel/VERSION N thirdparty/apache/bcel/lib/bcel.jar No conflicts created by this import ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.deployment.scanner.DeploymentScanner
> > >|I just realized how simple it would be to do all of the same >|functionality that DDS does and retain any URL capabilites in the same >|component... I was so into the local/directory only thing that I did >|not see it. >| >|I will add URLDeploymentScanner tomorrow... > >scanning URLs is not simple, getting the last modified on a URL is trivial. > True, but I don't think that we want to do much more than that, as anything else is really protocol specific. For example, consider a FTPDeploymentScanner, which would work similarly to DirectoryDeploymentScanner, but use the FTP protocol to get those file information. Similarly, an HTTP version could be tossed together which would work off of FTP sites that are exposed through HTTP. In short, this type of protocol specific fluff should be left to a specialized implementation. What I meant about UDS being simple is that users specify a list of URLs. If the URL protocol is file, and the file file it refers to exists and is a directory, then we can look for more files, else just treat the URL/non-directory file as a deployable. >However before we get there, we need to make sure that the deployers work >for url based deployments. > >Do you want to try to make the real URL based deployment work? I made it >work in 3.0 pre-alpha but since then "earth bound filesystem" dirs creep >back in. > I am not sure exactly what you are refering to here. Can you be more specific by what you mean by "earth bound filesystem". I know that referes to a local fs, but where is the dependency? For example, there is practically no need for any reference to any of the base directories in the current DDS. It is only used currently to generate absolutes... which I really believe should be handled elsewhere. MD, is bound to the local fs, as it needs to unpack stuff... Can you explain more please? >|> I was also not planning on letting DeploymentInfo seep into this >|> layer... but after thinking and attempting to implement this in a > >that is good, don't change that, I don't know what you think it is a problem >(and don't bother answering in 3 volumes, it is a minor point). > The deployment system needs some work... perhaps you don't see it yet... but you will. =) >|> I think that this could be fixed up with a combonation of David's xslt >|> ideas + the Deployment/DeploymentManager bits I was talking about when >|> I mentiond DeploymentScanner in the first place. > > >don't > I still believe this all could be cleaned up and simplified dramatically by using the factory pattern here, where the MD is a factory and primary controller for Deployments. There are still some details to work out, but they will settle in time... and once I understand better what David is thinking about. >|> For DDS, since it is file specific I removed the small bits of code >|> which got the last modified time from an opened connection. The >|> reason I did this was to keep the DDS simple by making it only have to >|> worry about files and that is it. > >DDS WAS already URL/File but really we should abstract deployment location, >wasn't there something in netbeans that abstracted files? But first making >it work with URL based AT ALL is the step. > MD was (sort of), not DDS. You lost me on the rest of that. Isn't deployment location a URL? Netbeans has a FileSystem api, though I am not sure what that buys us here... JNDI fs context might do the same job in more portable fashion. I don't understand what part of the system you are trying to abstract from files. Please explain. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jboss.net/src/main/org/jboss/net/axis/server AxisService.java AxisServiceMBean.java Constants.java
User: cgjung
Date: 02/03/01 14:12:57
Modified:jboss.net/src/main/org/jboss/net/axis/server
AxisService.java AxisServiceMBean.java
Constants.java
Log:
this one is for peter ... patched web-container access to go through the
maindeployer (still dirty) and
switched authentication off for now since Jetty does still not as we like. I get
hang-ups in deploying the
combined ejb/wsr test, but at least addr.wsr works again. Happy weekend.
Revision ChangesPath
1.13 +28 -27
contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java
Index: AxisService.java
===
RCS file:
/cvsroot/jboss/contrib/jboss.net/src/main/org/jboss/net/axis/server/AxisService.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- AxisService.java 28 Feb 2002 08:01:27 - 1.12
+++ AxisService.java 1 Mar 2002 22:12:57 - 1.13
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: AxisService.java,v 1.12 2002/02/28 08:01:27 cgjung Exp $
+// $Id: AxisService.java,v 1.13 2002/03/01 22:12:57 cgjung Exp $
package org.jboss.net.axis.server;
@@ -31,6 +31,7 @@
import org.jboss.naming.Util;
import org.jboss.metadata.MetaData;
import org.jboss.system.server.ServerConfigImplMBean;
+import org.jboss.deployment.DeployerMBean;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
@@ -62,12 +63,13 @@
import java.util.Map;
import java.util.Iterator;
+import java.util.Collection;
/**
* A deployer service that installs and manages Axis within JMX.
* @created 27. September 2001
* @author mailto:[EMAIL PROTECTED]";>Christoph G. Jung
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
* Change notes:
*
* 01.02.02: CGJ, Adapted to jboss3.0.0DR1 deployment changes. Arrgh!
@@ -99,6 +101,9 @@
/** the axis engines */
final static Map axisServerMap=new java.util.HashMap();
+ /** the web deployer that hosts our servlet */
+ DeployerMBean webDeployer;
+
/** default */
public AxisService()
{
@@ -199,6 +204,22 @@
URL myUrl=appDir.toURL();
myDeploymentInfo=new DeploymentInfo(myUrl,null);
+ myDeploymentInfo.url=new URL("http://net.jboss.org/fake.war";);
+
+ Iterator allDeployers=((Collection)
server.invoke(MainDeployerMBean.OBJECT_NAME,
+"listDeployers",
+new Object[0],
+new String[0])).iterator();
+
+ while(allDeployers.hasNext() && webDeployer==null) {
+ DeployerMBean nextBean=(DeployerMBean) allDeployers.next();
+ if(nextBean.accepts(myDeploymentInfo)) {
+ webDeployer=nextBean;
+ }
+ }
+
+ if(webDeployer!=null) {
+
myDeploymentInfo.localUrl=myUrl;
try
@@ -250,10 +271,7 @@
// Call the war deployer through the JMX server to initialise
// and deploy the info
- server.invoke(MainDeployerMBean.OBJECT_NAME,
-"deploy",
-new Object[] {myDeploymentInfo},
-new String[] {"org.jboss.deployment.DeploymentInfo"});
+ webDeployer.start(myDeploymentInfo);
try
{
@@ -266,6 +284,9 @@
}
catch (Exception e) {log.error("Could not register with MainDeployer", e);
}
+ } else {
+ throw new Exception(Constants.CANNOT_FIND_WEB_DEPLOYER);
+ }
}
@@ -314,10 +335,7 @@
log.getCategory().l7dlog(Priority.INFO,ABOUT_TO_UNDEPLOY_0,new Object[]
{myDeploymentInfo},null);
- server.invoke(MainDeployerMBean.OBJECT_NAME,
- "undeploy",
- new Object[] {myDeploymentInfo},
- new String[] {"org.jboss.deployment.DeploymentInfo"});
+ webDeployer.stop(myDeploymentInfo);
} catch (Exception e)
{
@@ -345,23 +363,6 @@
return (AxisServer) axisServerMap.get(context);
}
- //
- // war deployer plug
- //
-
- protected String warDeployerName=null;
-
- public String getWarDeployerName()
- {
- return warDeployerName;
- }
-
- public void setWarDeployerName(String name)
- {
- log.getCategory().l7dlog(Priority.INFO,SET_WAR_DEPLOYER_0,new Object[]
- {name},null);
- warDeployerName=name;
- }
//
// security domain
1.3 +2 -4
contrib/jboss.net/src/main/org/jboss/net/
[JBoss-dev] CVS update: contrib/jboss.net/testsuite build.bat
User: cgjung Date: 02/03/01 14:12:58 Modified:jboss.net/testsuite build.bat Log: this one is for peter ... patched web-container access to go through the maindeployer (still dirty) and switched authentication off for now since Jetty does still not as we like. I get hang-ups in deploying the combined ejb/wsr test, but at least addr.wsr works again. Happy weekend. Revision ChangesPath 1.4 +2 -4 contrib/jboss.net/testsuite/build.bat Index: build.bat === RCS file: /cvsroot/jboss/contrib/jboss.net/testsuite/build.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- build.bat 28 Feb 2002 04:08:03 - 1.3 +++ build.bat 1 Mar 2002 22:12:58 - 1.4 @@ -8,7 +8,7 @@ REM REM == REM -REM $Id: build.bat,v 1.3 2002/02/28 04:08:03 user57 Exp $ +REM $Id: build.bat,v 1.4 2002/03/01 22:12:58 cgjung Exp $ REM REM Authors: REM Jason Dillon <[EMAIL PROTECTED]> @@ -32,9 +32,7 @@ REM set JAXP_DOM_FACTORY=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl REM set JAXP_SAX_FACTORY=org.apache.xerces.jaxp.SAXParserFactoryImpl -set PATH=%PATH%;w:\inforce\dist\lib\ - -set ANT_OPTS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=2001,server=y,suspend=n -Djavax.xml.parsers.DocumentBuilderFactory=%JAXP_DOM_FACTORY% -Djavax.xml.parsers.SAXParserFactory=%JAXP_SAX_FACTORY% +set ANT_OPTS=-Djava.protocol.handler.pkgs=org.jboss.net.protocol -Djavax.xml.parsers.DocumentBuilderFactory=%JAXP_DOM_FACTORY% -Djavax.xml.parsers.SAXParserFactory=%JAXP_SAX_FACTORY% -Dbuild.script=build.bat REM ** REM - "for" loops have been unrolled for compatibility ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jboss.net/src/resources/plugin/META-INF install-axis.xml jboss-service.xml
User: cgjung Date: 02/03/01 14:12:58 Modified:jboss.net/src/resources/plugin/META-INF install-axis.xml jboss-service.xml Log: this one is for peter ... patched web-container access to go through the maindeployer (still dirty) and switched authentication off for now since Jetty does still not as we like. I get hang-ups in deploying the combined ejb/wsr test, but at least addr.wsr works again. Happy weekend. Revision ChangesPath 1.4 +3 -3 contrib/jboss.net/src/resources/plugin/META-INF/install-axis.xml Index: install-axis.xml === RCS file: /cvsroot/jboss/contrib/jboss.net/src/resources/plugin/META-INF/install-axis.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- install-axis.xml 4 Feb 2002 09:38:58 - 1.3 +++ install-axis.xml 1 Mar 2002 22:12:58 - 1.4 @@ -65,9 +65,9 @@ Jetty-specific, does not authenticate users correctly, and should be changed to the * role with the advent of Jetty4 or a bugfix in Jetty3 --> - - NONE - + 1.11 +1 -2 contrib/jboss.net/src/resources/plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jboss.net/src/resources/plugin/META-INF/jboss-service.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- jboss-service.xml 24 Feb 2002 11:51:34 - 1.10 +++ jboss-service.xml 1 Mar 2002 22:12:58 - 1.11 @@ -1,6 +1,6 @@ - + @@ -22,7 +22,6 @@ jboss.web:service=Jetty -jboss.web:service=Jetty axis java:/jaas/other ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
> > >> The main problem with using ../ here (and other places) is that when the >> configuration as specified on the command line changes, this breaks. >> > > hu? In most places where relative paths are prefixed with a base, the base value is determined from ServerConfig.getServerHomeDir(), which is jboss/server//. When the --net-boot flag is NOT used, ServerHomeURL is set to ServerHomeDir.toURL(), when it IS used, then ServerHomeURL is set to the argument specified. The server will always have a reference to a file system as set by HomeDir and ServerHomeDir. Components which *must* work from a local file system use these values. Components which can use a URL will use the URL versions. > > explicit can be good too. Do you think it is simpler? Yes, by far. It will also make it clearer to users/admins who are configuration components to know exactly what the server will resolve the path to rather than trial/error/guessing what ../ will turn into. This seems like a good thing todo on all fronts. For simplification of components that deal with them (they don't have to deal with making absolutes), for configuration file clarity and for consistency with command line (or embeded) configuration paramers. And to top it all off... it is simple to implement. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
Currently the primary jboss-service.xml does exactly this, so Dave might not be including in other files, since this one already does it. I hope that eventually we use explicit jar refs, so we don't bloat the heap with unused libs. --jason Hiram Chirino wrote: > How does the server know where the jars are if the is > not there. Does it just load up all the lib/* jars?? > > Regards, > Hiram > > >> From: David Jencks <[EMAIL PROTECTED]> >> To: Hiram Chirino <[EMAIL PROTECTED]> >> CC: [EMAIL PROTECTED], [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Property access in *service.xml and relative >> paths >> Date: Fri, 1 Mar 2002 10:39:55 -0500 >> >> Are you sure you need the element at all? Unless you >> are >> loading from an http: url you should be fine by removing this element >> entirely. I guess I better go through everything and do this... I >> already >> got a lot of messages from them being in the db config examples. >> >> david jencks >> >> On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: >> > it would be kinda nice if the url's in the service.xml file were >> relative >> > to >> > the service.xml file. Do I make sense?? so if the service.xml >> files is: >> > /jboss/server/default/deploy/jbossmq-service.xml >> > To load all the jboss/lib jars : >> > >> > To load all the jars in the server's lib dirctory: >> > /jboss/server/default/lib >> > >> > >> > Regards, >> > Hiram >> > >> > >From: Jason Dillon <[EMAIL PROTECTED]> >> > >To: David Jencks <[EMAIL PROTECTED]> >> > >CC: [EMAIL PROTECTED] >> > >Subject: Re: [JBoss-dev] Property access in *service.xml and relative >> > paths >> > >Date: Thu, 28 Feb 2002 19:51:32 -0800 >> > > >> > >I sent mail on this before I commited the layout change. It has todo >> > >with which directory/url do we use to qualify relative paths. It >> also >> > >has todo with allow a global and per-server config library directory. >> > > >> > >--jason >> > > >> > > >> > >David Jencks wrote: >> > > >> > >>On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >> > >> >> > >>>I was thinking that a solution to the problem that MD now has >> due to >> > the >> > >>>layout changes that I made WRT relatives paths could be solved by >> > >>>forcing users to be explicit about which path they which to use >> (ie. >> > not >> > >>>allowing relative paths). >> > >>> >> > >> >> > >>What are these problems? I haven't noticed any. Using > .../> >> > >> > >>can >> > >>cause problems, but it is almost always better to just leave the tag >> > out. >> > >> >> > >>david jencks >> > >> >> > >> >> > >>>To make this work we need to expose some system property access >> inside >> > >>>of the *service.xml files... probably as an attribute value >> subst and >> > an >> > >>>element... for example: >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>>Which could then be used in config elements later in the file... >> > >>> >> > >>>And to finally solve the two lib problem... just more than one >> > classpath >> > >>>(if that isn't the case already): >> > >>> >> > >>> >> > >>> >> > >>> >> > >>>This would prefer libs from inside jboss.server.home.dir/lib before >> > >>>jboss.home.dir/lib >> > >>> >> > >>>--jason >> > >>> >> > >>> >> > >>>___ >> > >>>Jboss-development mailing list >> > >>>[EMAIL PROTECTED] >> > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >> > >>> >> > >>> >> > > >> > > >> > > >> > >___ >> > >Jboss-development mailing list >> > >[EMAIL PROTECTED] >> > >https://lists.sourceforge.net/lists/listinfo/jboss-development >> > >> > >> > >> > >> > _ >> > Get your FREE download of MSN Explorer at >> > http://explorer.msn.com/intl.asp.; >> > >> > >> > > > > > > > _ > Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet todo...
> You should be able to do the following:
> /**
>* blah
>*/
> public void myMethod()
> {
> /** @todo put something here */
> }
Are you saying _should_ or _can_? afaik (although to be honest I haven't
tested it), the javadoc engine only supports class/interface/method level
nodes. That is where I see the limitation being. Hence when xjavadoc
replaces the sun javadoc engine, this may be possible.
cheers
dim
>
> Ken
> - Original Message -
> From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
> To: "Jason Dillon" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Thursday, February 28, 2002 10:26 PM
> Subject: Re: [JBoss-dev] XDoclet todo...
>
>
> > > This is really for the xdoclet list, but I am too lazy to find the
> > > address for that (plus lots of them listen here too).
> > >
> > > Is there any easy way to allow xdoclet to search for tags inside of
> > > methods too? For example, I find it much easier to put the TODO,
where
> > > the code should go, but I would like to keep using @todo.
> > >
> > > /**
> > > * blah
> > > */
> > > public void myMethod()
> > > {
> > >/// @todo put something here
> > > }
> >
> > Not at the moment, because XDoclet's tree come's from Sun's javadoc
> engine.
> >
> > perhaps this could be added when the xjavadoc module is in use (the same
> one that is going to allow in-vm generaetion :)
> >
> > cheers
> > dim
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
>From: Jason Dillon <[EMAIL PROTECTED]> >To: Hiram Chirino <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], >[EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Property access in *service.xml and relative paths >Date: Fri, 01 Mar 2002 14:43:59 -0800 > >The main problem with using ../ here (and other places) is that when the >configuration as specified on the command line changes, this breaks. > hu? >It would be better to be explit here, and other places which need >configuration directories or urls to use the values determined by >ServerConfig* by using the system properties which it sets. > explicit can be good too. Do you think it is simpler? >If we change ServiceConfigurator to handle this, then we can reduce some >code duplication as target components won't have to deal with prepending >base bases to relative ones. > >Relying on ../ in configuration or code is a poor choice when we can >make use of the exposed configuration. > >--jason > > >Hiram Chirino wrote: > >>it would be kinda nice if the url's in the service.xml file were >>relative to the service.xml file. Do I make sense?? so if the >>service.xml files is: >>/jboss/server/default/deploy/jbossmq-service.xml >>To load all the jboss/lib jars : >> >>To load all the jars in the server's lib dirctory: >>/jboss/server/default/lib >> >> >>Regards, >>Hiram >> >>>From: Jason Dillon <[EMAIL PROTECTED]> >>>To: David Jencks <[EMAIL PROTECTED]> >>>CC: [EMAIL PROTECTED] >>>Subject: Re: [JBoss-dev] Property access in *service.xml and relative >>>paths >>>Date: Thu, 28 Feb 2002 19:51:32 -0800 >>> >>>I sent mail on this before I commited the layout change. It has todo >>>with which directory/url do we use to qualify relative paths. It also >>>has todo with allow a global and per-server config library directory. >>> >>>--jason >>> >>> >>>David Jencks wrote: >>> On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >I was thinking that a solution to the problem that MD now has due >to the >layout changes that I made WRT relatives paths could be solved by >forcing users to be explicit about which path they which to use >(ie. not >allowing relative paths). > What are these problems? I haven't noticed any. Using >>>.../> can cause problems, but it is almost always better to just leave the tag out. david jencks >To make this work we need to expose some system property access inside >of the *service.xml files... probably as an attribute value subst >and an >element... for example: > > > > > > > > > > >Which could then be used in config elements later in the file... > >And to finally solve the two lib problem... just more than one >classpath >(if that isn't the case already): > > > > >This would prefer libs from inside jboss.server.home.dir/lib before >jboss.home.dir/lib > >--jason > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > > >>> >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> >> >> >>_ >>Get your FREE download of MSN Explorer at >>http://explorer.msn.com/intl.asp.; > > > _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar protocol is not working with security manager
> > >Its not reasonable to force the use of 1.4 at this point so the >first point is irrelevant. We have to be able to run under a >security manager with 3.0 with JDK 1.3. > That is not what I meant. I was under the impression that a SM could still be used under 1.3, but would not be "spec compliant" (whatever that means) as someone mentiond. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging and
Ohhh my baby is grown up, it is not even mine any more.
I got a tear running down my cheek, snnniff!
this is great news, how about the speed?
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Adrian Brock
|Sent: Friday, March 01, 2002 1:09 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar,
|logging and
|
|
|Cool,
|
|1) Install jboss-jmx.jar in lib
|2) Change the hard-coded jmxri.jar to jboss-jmx.jar in
|org.jboss.Main
|3) Change the testsuite to run over jboss-jmx.jar
|
|We have a working JBoss running over JBossMX :-)
|
|Add bonuses
|Fixes two problems in the WebIntegerationUnitTestCase
|as well!
|Works on jdk1.4. No problem with SingleJBoss like the RI ;-)
|
|Now if only ModelMBeans was complete...
|They work enough to run Jetty.
|
|Regards,
|Adrian
|
|
|> friday? sup wit dat a?
|>
|> --jason
|>
|>
|> Adrian Brock wrote:
|>
|> >Thanks Jason,
|> >
|> >I can't get my next CVS update until Friday :-(
|> >I'll try it then... Should work.
|> >
|> >Regards,
|> >Adrian
|> >
|> >>So the simplest thing todo here is to simply not
|> >>unset the cl used to
|> >>load the server with. I am not sure this is the
|> best
|> >>way to fix this
|> >>but should work. Let me know if you still have
|> >>trouble.
|> >>
|> >>--jason
|> >>
|> >>
|> >>Adrian Brock wrote:
|> >>
|> >>>Hi Jason,
|> >>>
|> >>>I've got a problem integrating JBossMX with your
|> >>>new Server code.
|> >>>
|> >>>In ServerLoader.load(ClassLoader) you construct a
|> >>>URLClassLoader and set it as the TCL (Thread class
|> >>>
|> >>loader).
|> >>
|> >>>This is for dynamically loading classes from
|> >>>configuration options.
|> >>>
|> >>>But Server.start() does not have this TCL.
|> >>>We do the same config processing in JBossMX,
|> >>>we can't find the classes during
|> >>>MBeanServerFactory.createMBeanServer("jboss") :-(
|> >>>
|> >>>Looks pretty good besides.
|> >>>
|> >>>P.S. You misspelt DEFUALT_BOOT_LIBRARY_LIST :-)
|> >>>
|> >>>Regards,
|> >>>Adrian
|> >>>
|> Again for those that missed it...
|>
|> --jason
|>
|> Original Message
|> Subject: Embedable, ServerLoader, jboss-boot.jar,
|> logging and more...
|> Date: Sun, 24 Feb 2002 03:37:31 -0800
|> From: Jason Dillon <[EMAIL PROTECTED]>
|> To: [EMAIL PROTECTED]
|>
|>
|>
|> With the seperation changes also come the first
|>
|> >>major
|> >>
|> embedable change
|> that I was planning, which was the introduction
|> of
|> the ServerLoader
|> component. SL performs similar functionality as
|>
|> >>the
|> >>
|> newly added Boot
|> utiltiy, but provides a JBoss specific interface
|>
|> >>with
|> >>
|> the sole purpose
|> of loading the central Server component (which
|> sets
|> up the
|> GPA/MicroKernel/Core system).
|>
|> jboss-boor.jar contains all of the required files
|>
|> >>to
|> >>
|> bootstrap (load and
|> start) the Server component. It contains Server,
|> ServerConfig and
|> ServerLoader and is about 5k (with
|>
|> >>javac.debug=true).
|> >>
|> It provides a raw
|> API to load, initialize and start a Server
|>
|> >>instance.
|> >>
|> ServerLoader accepts a parent CL for delegation,
|>
|> >>per
|> >>
|> Scott's list.
|>
|> To help keep things small, Server and
|> ServerConfig
|> have been turned into
|> interfaces. I have provided implemeations for
|> both
|> as ServerImpl andf
|> ServerConfigImpl, which perform the same basic
|> functions they did
|> before. MBean interfaces are also provided for
|> these.
|>
|> To further keep things small (as well as expose
|>
|> >>more
|> >>
|> control to
|> clients), server configuration is now initially
|> property based. I
|> followed the InitialContext aproache read config
|> properties from a
|> passed in Properties map. Cleints can create a
|> map
|> that will default to
|> System.getProperties() thus allowing more control
|> over how the server is
|> configured.
|>
|> For example to change the temporray dir that is
|>
|> >>used
|> >>
|> by default, the
|> client would:
|>
|> props.setProperty(ServerConfig.TEMP_DIR,
|> R, "/some/path/tmp");
|>
|> or on the command line (via Main):
|>
|> ./run.sh
|> sh
|>
|> >>-Dorg.jboss.system.server.temp.dir=/some/path/tmp
|> >>
|> Defaults are still constructed in the previous
|>
|> >>value,
|> >>
|> only
|> ServerConfig.HOME_DIR needs to be set, everything
|> else can be calculated
|>
|> from there.
|> >>>
|> See the javadoc for Server & ServerConfig for
|> more
|> information.
|>
|> I said that config is initially property based,
|> as
|> once the Server impl
|> is loaded a typed adapte
Re: [JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
What do you mean "this morning"... =P --jason marc fleury wrote: >ok sorry for freaking out, man I am prissy this morning. > >in a general bad mood, > >marcf > > >|-Original Message- >|From: Sacha Labourey [mailto:[EMAIL PROTECTED]] >|Sent: Friday, March 01, 2002 7:32 AM >|To: marc fleury; [EMAIL PROTECTED] >|Subject: RE: [JBoss-dev] CVS update: >|jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java >| >| >|No ;) >| >|No sub-partitions ;) >| >|cluster <=> partition != sub-partition >| >|Partitions have always be in. What you don't get are *sub*-partitions. But >|this CVS log doesn't concern sub-partition at all. >| >|sky is blue. >| >|> -Message d'origine- >|> De : marc fleury [mailto:[EMAIL PROTECTED]] >|> Envoyé : vendredi, 1 mars 2002 19:27 >|> À : Sacha Labourey; [EMAIL PROTECTED] >|> Objet : RE: [JBoss-dev] CVS update: >|> jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java >|> >|> >|> oh no, complexity creeping back in??? >|> >|> no sub partitions, please, I still don't get what they do. >|> >|> marcf > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] buglet in 2.4 JAWS. Should I fix?
OK, after one of my younger cohorts tried to create an instance of a
CMP entity whose fields were all private (at least he understands
encapsulation!) leading to a mysterious NPE, I ran across the
following code in CMPFieldMetaData:
catch (NoSuchFieldException e)
{
// we can have a private attribute, then we will use fieldName
// to find the get/set methods, but still have to set jdbcType/SQLType
// but can not yet do it sowe have to set field to null so that
// getJDBCType will not use the parent Field to find the types
field = null;
return null;
}
I've got two problems with this:
1. This violates the spec. No huge deal, in my book, but...
2. The following code in CMPFieldMetaData:
if (!isNested())
{
return getField().get(instance);
}
Blows Chow all over the place.
I'm calling this a buglet because it only sucks when you have a
non-compliant bean. But then the fact that every bloody log write
in JAWS has been made 'debug' even where they are obviously error
conditions and very few of the exceptions propogate sufficient
information (which is tough to do anyway from 'catch (Exception)')
makes it really suck when you hit it. There are a lot of error
conditions in JAWS that really suck when you hit them with DEBUG
logging off.
But. Should I fix this (and other issues) and if I fix this should I
port up to the 3.0 code? Is JAWS still used at all in 3.0, or is it
entirely replaced by Dain's CMP?
My fix for this would probably be to simply make it enforce the spec
and report a sensible DeploymentException telling the bean developer
what's wrong, but that does seem out of character for JAWS (telling
the developer what went wrong). OK, just so nobody has to remind me,
I did have a bit to do with the 2.4 JAWS, but if you can't look at
your own work from 9 months ago and bitch about it, what _can_ you
bitch about?
Opinions?
thanks all,
danch
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
Does the main jboss-service.xml need a ? If not why is it there? It seems like this loads the libraries required by the service... I don't get why you think it should not be used... can you explain? --jason David Jencks wrote: >Are you sure you need the element at all? Unless you are >loading from an http: url you should be fine by removing this element >entirely. I guess I better go through everything and do this... I already >got a lot of messages from them being in the db config examples. > >david jencks > >On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: > >>it would be kinda nice if the url's in the service.xml file were relative >>to >>the service.xml file. Do I make sense?? so if the service.xml files is: >>/jboss/server/default/deploy/jbossmq-service.xml >>To load all the jboss/lib jars : >> >>To load all the jars in the server's lib dirctory: >>/jboss/server/default/lib >> >> >>Regards, >>Hiram >> >>>From: Jason Dillon <[EMAIL PROTECTED]> >>>To: David Jencks <[EMAIL PROTECTED]> >>>CC: [EMAIL PROTECTED] >>>Subject: Re: [JBoss-dev] Property access in *service.xml and relative >>> >>paths >> >>>Date: Thu, 28 Feb 2002 19:51:32 -0800 >>> >>>I sent mail on this before I commited the layout change. It has todo >>>with which directory/url do we use to qualify relative paths. It also >>>has todo with allow a global and per-server config library directory. >>> >>>--jason >>> >>> >>>David Jencks wrote: >>> On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >I was thinking that a solution to the problem that MD now has due to > >>the >> >layout changes that I made WRT relatives paths could be solved by >forcing users to be explicit about which path they which to use (ie. > >>not >> >allowing relative paths). > What are these problems? I haven't noticed any. Using can cause problems, but it is almost always better to just leave the tag >>out. >> david jencks >To make this work we need to expose some system property access inside >of the *service.xml files... probably as an attribute value subst and > >>an >> >element... for example: > > > > > > > > > > >Which could then be used in config elements later in the file... > >And to finally solve the two lib problem... just more than one > >>classpath >> >(if that isn't the case already): > > > > >This would prefer libs from inside jboss.server.home.dir/lib before >jboss.home.dir/lib > >--jason > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > > >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >> >> >>_ >>Get your FREE download of MSN Explorer at >>http://explorer.msn.com/intl.asp.; >> >> >> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
The main problem with using ../ here (and other places) is that when the configuration as specified on the command line changes, this breaks. It would be better to be explit here, and other places which need configuration directories or urls to use the values determined by ServerConfig* by using the system properties which it sets. If we change ServiceConfigurator to handle this, then we can reduce some code duplication as target components won't have to deal with prepending base bases to relative ones. Relying on ../ in configuration or code is a poor choice when we can make use of the exposed configuration. --jason Hiram Chirino wrote: > it would be kinda nice if the url's in the service.xml file were > relative to the service.xml file. Do I make sense?? so if the > service.xml files is: > /jboss/server/default/deploy/jbossmq-service.xml > To load all the jboss/lib jars : > > To load all the jars in the server's lib dirctory: > /jboss/server/default/lib > > > Regards, > Hiram > >> From: Jason Dillon <[EMAIL PROTECTED]> >> To: David Jencks <[EMAIL PROTECTED]> >> CC: [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Property access in *service.xml and relative >> paths >> Date: Thu, 28 Feb 2002 19:51:32 -0800 >> >> I sent mail on this before I commited the layout change. It has todo >> with which directory/url do we use to qualify relative paths. It also >> has todo with allow a global and per-server config library directory. >> >> --jason >> >> >> David Jencks wrote: >> >>> On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >>> I was thinking that a solution to the problem that MD now has due to the layout changes that I made WRT relatives paths could be solved by forcing users to be explicit about which path they which to use (ie. not allowing relative paths). >>> >>> What are these problems? I haven't noticed any. Using >> .../> can >>> cause problems, but it is almost always better to just leave the tag >>> out. >>> >>> david jencks >>> >>> To make this work we need to expose some system property access inside of the *service.xml files... probably as an attribute value subst and an element... for example: Which could then be used in config elements later in the file... And to finally solve the two lib problem... just more than one classpath (if that isn't the case already): This would prefer libs from inside jboss.server.home.dir/lib before jboss.home.dir/lib --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > _ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp.; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging and
Cool,
1) Install jboss-jmx.jar in lib
2) Change the hard-coded jmxri.jar to jboss-jmx.jar in
org.jboss.Main
3) Change the testsuite to run over jboss-jmx.jar
We have a working JBoss running over JBossMX :-)
Add bonuses
Fixes two problems in the WebIntegerationUnitTestCase
as well!
Works on jdk1.4. No problem with SingleJBoss like the RI ;-)
Now if only ModelMBeans was complete...
They work enough to run Jetty.
Regards,
Adrian
> friday? sup wit dat a?
>
> --jason
>
>
> Adrian Brock wrote:
>
> >Thanks Jason,
> >
> >I can't get my next CVS update until Friday :-(
> >I'll try it then... Should work.
> >
> >Regards,
> >Adrian
> >
> >>So the simplest thing todo here is to simply not
> >>unset the cl used to
> >>load the server with. I am not sure this is the
> best
> >>way to fix this
> >>but should work. Let me know if you still have
> >>trouble.
> >>
> >>--jason
> >>
> >>
> >>Adrian Brock wrote:
> >>
> >>>Hi Jason,
> >>>
> >>>I've got a problem integrating JBossMX with your
> >>>new Server code.
> >>>
> >>>In ServerLoader.load(ClassLoader) you construct a
> >>>URLClassLoader and set it as the TCL (Thread class
> >>>
> >>loader).
> >>
> >>>This is for dynamically loading classes from
> >>>configuration options.
> >>>
> >>>But Server.start() does not have this TCL.
> >>>We do the same config processing in JBossMX,
> >>>we can't find the classes during
> >>>MBeanServerFactory.createMBeanServer("jboss") :-(
> >>>
> >>>Looks pretty good besides.
> >>>
> >>>P.S. You misspelt DEFUALT_BOOT_LIBRARY_LIST :-)
> >>>
> >>>Regards,
> >>>Adrian
> >>>
> Again for those that missed it...
>
> --jason
>
> Original Message
> Subject: Embedable, ServerLoader, jboss-boot.jar,
> logging and more...
> Date: Sun, 24 Feb 2002 03:37:31 -0800
> From: Jason Dillon <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
>
>
> With the seperation changes also come the first
>
> >>major
> >>
> embedable change
> that I was planning, which was the introduction
> of
> the ServerLoader
> component. SL performs similar functionality as
>
> >>the
> >>
> newly added Boot
> utiltiy, but provides a JBoss specific interface
>
> >>with
> >>
> the sole purpose
> of loading the central Server component (which
> sets
> up the
> GPA/MicroKernel/Core system).
>
> jboss-boor.jar contains all of the required files
>
> >>to
> >>
> bootstrap (load and
> start) the Server component. It contains Server,
> ServerConfig and
> ServerLoader and is about 5k (with
>
> >>javac.debug=true).
> >>
> It provides a raw
> API to load, initialize and start a Server
>
> >>instance.
> >>
> ServerLoader accepts a parent CL for delegation,
>
> >>per
> >>
> Scott's list.
>
> To help keep things small, Server and
> ServerConfig
> have been turned into
> interfaces. I have provided implemeations for
> both
> as ServerImpl andf
> ServerConfigImpl, which perform the same basic
> functions they did
> before. MBean interfaces are also provided for
> these.
>
> To further keep things small (as well as expose
>
> >>more
> >>
> control to
> clients), server configuration is now initially
> property based. I
> followed the InitialContext aproache read config
> properties from a
> passed in Properties map. Cleints can create a
> map
> that will default to
> System.getProperties() thus allowing more control
> over how the server is
> configured.
>
> For example to change the temporray dir that is
>
> >>used
> >>
> by default, the
> client would:
>
> props.setProperty(ServerConfig.TEMP_DIR,
> R, "/some/path/tmp");
>
> or on the command line (via Main):
>
> ./run.sh
> sh
>
> >>-Dorg.jboss.system.server.temp.dir=/some/path/tmp
> >>
> Defaults are still constructed in the previous
>
> >>value,
> >>
> only
> ServerConfig.HOME_DIR needs to be set, everything
> else can be calculated
>
> from there.
> >>>
> See the javadoc for Server & ServerConfig for
> more
> information.
>
> I said that config is initially property based,
> as
> once the Server impl
> is loaded a typed adapter (ServerConfigImpl) is
> created to allow typed
> access to the values provided here (and thus
>
> >>keeping
> >>
> clients from having
> to perfrom the same redundant data conversion).
>
> Since all (practically) libraries are now loaded
>
> >>off
> >>
> network and the
> classes on the system classpath have been
>
> >>minimized,
> >>
> the utility of a
> lib/ & lib/ext seperation (as well as spineURL
> and
> such) have
> deminished. I have removed usage of these to
>
> >>reduce
> >>
> complexity. All
> library f
Re: [JBoss-dev] Property access in *service.xml and relative paths
Although it may not be needed for the default sars, we do need the ability to specify a classpath in the event that the service refers to an external set of jars as is the case with the tomcat4 service. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: "Hiram Chirino" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 11:39 AM Subject: Re: [JBoss-dev] Property access in *service.xml and relative paths > On 2002.03.01 14:10:07 -0500 Hiram Chirino wrote: > > How does the server know where the jars are if the is not > > there. Does it just load up all the lib/* jars?? > > yes > > david jencks > > > > Regards, > > Hiram > > > > > > >From: David Jencks <[EMAIL PROTECTED]> > > >To: Hiram Chirino <[EMAIL PROTECTED]> > > >CC: [EMAIL PROTECTED], [EMAIL PROTECTED] > > >Subject: Re: [JBoss-dev] Property access in *service.xml and relative > > paths > > >Date: Fri, 1 Mar 2002 10:39:55 -0500 > > > > > >Are you sure you need the element at all? Unless you > > are > > >loading from an http: url you should be fine by removing this element > > >entirely. I guess I better go through everything and do this... I > > already > > >got a lot of messages from them being in the db config examples. > > > > > >david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
We could make the DeploymentInfos into mbeans, and you could look at the state of the one for jboss-service.xml. I guess the way to do this might be to make an mbean representing a sar or *service.xml, and for all mbeans representing deployed packages (currently RARDeployment, and org.jboss.ejb.EjbModule) have them able to access the appropriate DeploymentInfo -- sort of a delegation model. david jencks On 2002.03.01 14:24:42 -0500 Adam Heath wrote: > On Fri, 1 Mar 2002, Chris Kimpton wrote: > > > I also increased the time I allow for the server to warm up - it was > > 2mins - but my test runs show it taking 1min 40secs or so - which is > > getting close - so it now allows 5 mins for the server to warm up. > > For the init script I wrote for debian, I also wait 2 minutes. Mine is a > little more complex, as I actually tail server.log, looking for matching > regex > patterns, and exit with different values depending on what I find. > > I've thought about writing a little hook, that would allow an external > utility to be notified/informed of when jboss is up, and functioning. > > In fact, the init/start/stop/destroy idea could probably be mapped into > this > kind of framework, for informing external programs of jboss' overall > state. > > I can't work on this right now, as the new website we have been working > on(which uses jboss!) is going live any day now(we've rewritten a 3 year > old > jsp website into j2ee in a couple of months). > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss Testsuite Results
On Fri, 1 Mar 2002, Chris Kimpton wrote: > I also increased the time I allow for the server to warm up - it was > 2mins - but my test runs show it taking 1min 40secs or so - which is > getting close - so it now allows 5 mins for the server to warm up. For the init script I wrote for debian, I also wait 2 minutes. Mine is a little more complex, as I actually tail server.log, looking for matching regex patterns, and exit with different values depending on what I find. I've thought about writing a little hook, that would allow an external utility to be notified/informed of when jboss is up, and functioning. In fact, the init/start/stop/destroy idea could probably be mapped into this kind of framework, for informing external programs of jboss' overall state. I can't work on this right now, as the new website we have been working on(which uses jboss!) is going live any day now(we've rewritten a 3 year old jsp website into j2ee in a couple of months). ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar still has problems with security manager
That does get around the problem: Security 961>java -Xbootclasspath/a:run.jar -Djava.security.manager -Djava.secu rity.policy=server.policy -Djava.protocol.handler.pkgs=org.jboss.net.protoco l HelloMain HelloMain.main is ok I'm not sure this is a viable option since this is a VM specific option. - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 11:04 AM Subject: Re: [JBoss-dev] njar still has problems with security manager > Have you tried adding it to the primordial class loader? I think it is > something like -Xbootclasspath > > -dain > > Scott M Stark wrote: > > > Even if I put the njar protocol handler in the system classpath > > and try a trival hello world main with the following simple > > policy file, running with a security manager fails when the policy > > file parsers goes into an infinitely recursive loop and blows > > out the stack. This is a show stopper for the custom njar protocol. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
How does the server know where the jars are if the is not there. Does it just load up all the lib/* jars?? Regards, Hiram >From: David Jencks <[EMAIL PROTECTED]> >To: Hiram Chirino <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Property access in *service.xml and relative paths >Date: Fri, 1 Mar 2002 10:39:55 -0500 > >Are you sure you need the element at all? Unless you are >loading from an http: url you should be fine by removing this element >entirely. I guess I better go through everything and do this... I already >got a lot of messages from them being in the db config examples. > >david jencks > >On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: > > it would be kinda nice if the url's in the service.xml file were >relative > > to > > the service.xml file. Do I make sense?? so if the service.xml files >is: > > /jboss/server/default/deploy/jbossmq-service.xml > > To load all the jboss/lib jars : > > > > To load all the jars in the server's lib dirctory: > > /jboss/server/default/lib > > > > > > Regards, > > Hiram > > > > >From: Jason Dillon <[EMAIL PROTECTED]> > > >To: David Jencks <[EMAIL PROTECTED]> > > >CC: [EMAIL PROTECTED] > > >Subject: Re: [JBoss-dev] Property access in *service.xml and relative > > paths > > >Date: Thu, 28 Feb 2002 19:51:32 -0800 > > > > > >I sent mail on this before I commited the layout change. It has todo > > >with which directory/url do we use to qualify relative paths. It also > > >has todo with allow a global and per-server config library directory. > > > > > >--jason > > > > > > > > >David Jencks wrote: > > > > > >>On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: > > >> > > >>>I was thinking that a solution to the problem that MD now has due to > > the > > >>>layout changes that I made WRT relatives paths could be solved by > > >>>forcing users to be explicit about which path they which to use (ie. > > not > > >>>allowing relative paths). > > >>> > > >> > > >>What are these problems? I haven't noticed any. Using .../> > > > > >>can > > >>cause problems, but it is almost always better to just leave the tag > > out. > > >> > > >>david jencks > > >> > > >> > > >>>To make this work we need to expose some system property access >inside > > >>>of the *service.xml files... probably as an attribute value subst and > > an > > >>>element... for example: > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>Which could then be used in config elements later in the file... > > >>> > > >>>And to finally solve the two lib problem... just more than one > > classpath > > >>>(if that isn't the case already): > > >>> > > >>> > > >>> > > >>> > > >>>This would prefer libs from inside jboss.server.home.dir/lib before > > >>>jboss.home.dir/lib > > >>> > > >>>--jason > > >>> > > >>> > > >>>___ > > >>>Jboss-development mailing list > > >>>[EMAIL PROTECTED] > > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > > >>> > > >>> > > > > > > > > > > > >___ > > >Jboss-development mailing list > > >[EMAIL PROTECTED] > > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > _ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp.; > > > > > > _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar still has problems with security manager
Have you tried adding it to the primordial class loader? I think it is
something like -Xbootclasspath
-dain
Scott M Stark wrote:
> Even if I put the njar protocol handler in the system classpath
> and try a trival hello world main with the following simple
> policy file, running with a security manager fails when the policy
> file parsers goes into an infinitely recursive loop and blows
> out the stack. This is a show stopper for the custom njar protocol.
>
> Security 944>jar -tf run.jar
> META-INF/
> META-INF/MANIFEST.MF
> HelloMain.class
> org/
> org/jboss/
> org/jboss/net/
> org/jboss/net/protocol/
> org/jboss/net/protocol/njar/
> org/jboss/net/protocol/njar/Handler.class
> org/jboss/net/protocol/resource/
> org/jboss/net/protocol/resource/Handler.class
> org/jboss/net/protocol/resource/ResourceURLConnection.class
> org/jboss/net/protocol/URLStreamHandlerFactory.class
> Security 945>cat server.policy
> grant codeBase "njar:file:run.jar" {
>permission java.security.AllPermission;
> };
> Security
> 946>java -Djava.security.manager -Djava.security.policy=server.policy
> -Djava.protocol.handler.pkgs=org.jboss.net.protocol -jar run.jar
> Exception in thread "main" java.lang.StackOverflowError
> at
> sun.security.action.GetPropertyAction.run(GetPropertyAction.java:69)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.provider.PolicyFile.(PolicyFile.java:111)
> at java.lang.Class.newInstance0(Native Method)
> at java.lang.Class.newInstance(Class.java:237)
> at java.security.Policy.getPolicyNoCheck(Policy.java:157)
> at
> java.security.SecureClassLoader.getPermissions(SecureClassLoader.java:138)
> at java.net.URLClassLoader.getPermissions(URLClassLoader.java:420)
> at
> sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:294)
> at
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:1
> 62)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.net.URL.getURLStreamHandler(URL.java:927)
> at java.net.URL.(URL.java:478)
> at java.net.URL.(URL.java:376)
> at java.net.URL.(URL.java:330)
> at
> sun.security.provider.PolicyFile.getCodeSource(PolicyFile.java:590)
> at
> sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:612)
> at sun.security.provider.PolicyFile.init(PolicyFile.java:530)
> at
> sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:330)
> at sun.security.provider.PolicyFile.access$000(PolicyFile.java:89)
> at sun.security.provider.PolicyFile$1.run(PolicyFile.java:232)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.provider.PolicyFile.init(PolicyFile.java:230)
> at sun.security.provider.PolicyFile.(PolicyFile.java:120)
> at java.lang.Class.newInstance0(Native Method)
> at java.lang.Class.newInstance(Class.java:237)
> at java.security.Policy.getPolicyNoCheck(Policy.java:157)
> at
> java.security.SecureClassLoader.getPermissions(SecureClassLoader.java:138)
> at java.net.URLClassLoader.getPermissions(URLClassLoader.java:420)
> at
> sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:294)
> at
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:1
> 62)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
> at java.net.URL.getURLStreamHandler(URL.java:927)
> at java.net.URL.(URL.java:478)
> at java.net.URL.(URL.java:376)
> at java.net.URL.(URL.java:330)
> at
> sun.security.provider.PolicyFile.getCodeSource(PolicyFile.java:590)
> at
> sun.security.provider.PolicyFile.addGran
[JBoss-dev] CVS update: jmx/src/main/test/performance/serialize/support - New directory
User: ejort Date: 02/03/01 10:51:04 jmx/src/main/test/performance/serialize/support - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/performance/serialize - New directory
User: ejort Date: 02/03/01 10:50:05 jmx/src/main/test/performance/serialize - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/performance/registration/support - New directory
User: ejort Date: 02/03/01 10:50:27 jmx/src/main/test/performance/registration/support - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/performance/registration - New directory
User: ejort Date: 02/03/01 10:49:56 jmx/src/main/test/performance/registration - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar protocol is not working with security manager
Its not reasonable to force the use of 1.4 at this point so the first point is irrelevant. We have to be able to run under a security manager with 3.0 with JDK 1.3. Adding the njar protocol handler to the system classpath does not solve the problem as the policy file parser crashes with a stack overflow error. I don't know if this can be fixed. I don't want to force the use of a custom security policy implementation as this requires modification of the JDK installation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 2:43 AM Subject: Re: [JBoss-dev] njar protocol is not working with security manager > Someone mentioned that 1.4 will allow for runtime config of security > policy... why not defer tight policy integration until we have switched > to it by default? > > Could also add njar to the system loader... > > It seems very strange to me that we now have huge names under tmp/deploy > (which may not fully get removed... or do we scan down to tmp/deploy and > delete parent directories when a deployment goes away) to get a security > policy to work. It just seems very strange... > > --jason > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] njar still has problems with security manager
Even if I put the njar protocol handler in the system classpath
and try a trival hello world main with the following simple
policy file, running with a security manager fails when the policy
file parsers goes into an infinitely recursive loop and blows
out the stack. This is a show stopper for the custom njar protocol.
Security 944>jar -tf run.jar
META-INF/
META-INF/MANIFEST.MF
HelloMain.class
org/
org/jboss/
org/jboss/net/
org/jboss/net/protocol/
org/jboss/net/protocol/njar/
org/jboss/net/protocol/njar/Handler.class
org/jboss/net/protocol/resource/
org/jboss/net/protocol/resource/Handler.class
org/jboss/net/protocol/resource/ResourceURLConnection.class
org/jboss/net/protocol/URLStreamHandlerFactory.class
Security 945>cat server.policy
grant codeBase "njar:file:run.jar" {
permission java.security.AllPermission;
};
Security
946>java -Djava.security.manager -Djava.security.policy=server.policy
-Djava.protocol.handler.pkgs=org.jboss.net.protocol -jar run.jar
Exception in thread "main" java.lang.StackOverflowError
at
sun.security.action.GetPropertyAction.run(GetPropertyAction.java:69)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.provider.PolicyFile.(PolicyFile.java:111)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at java.security.Policy.getPolicyNoCheck(Policy.java:157)
at
java.security.SecureClassLoader.getPermissions(SecureClassLoader.java:138)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:420)
at
sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:294)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:1
62)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.net.URL.getURLStreamHandler(URL.java:927)
at java.net.URL.(URL.java:478)
at java.net.URL.(URL.java:376)
at java.net.URL.(URL.java:330)
at
sun.security.provider.PolicyFile.getCodeSource(PolicyFile.java:590)
at
sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:612)
at sun.security.provider.PolicyFile.init(PolicyFile.java:530)
at
sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:330)
at sun.security.provider.PolicyFile.access$000(PolicyFile.java:89)
at sun.security.provider.PolicyFile$1.run(PolicyFile.java:232)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.provider.PolicyFile.init(PolicyFile.java:230)
at sun.security.provider.PolicyFile.(PolicyFile.java:120)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at java.security.Policy.getPolicyNoCheck(Policy.java:157)
at
java.security.SecureClassLoader.getPermissions(SecureClassLoader.java:138)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:420)
at
sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:294)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:1
62)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.net.URL.getURLStreamHandler(URL.java:927)
at java.net.URL.(URL.java:478)
at java.net.URL.(URL.java:376)
at java.net.URL.(URL.java:330)
at
sun.security.provider.PolicyFile.getCodeSource(PolicyFile.java:590)
at
sun.security.provider.PolicyFile.addGrantEntry(PolicyFile.java:612)
at sun.security.provider.PolicyFile.init(PolicyFile.java:530)
at
sun.security.provider.PolicyFile.initPolicyFile(PolicyFile.java:330)
at sun.security.provider.PolicyFile.access$000(PolicyFile.java:89)
at sun.security.provider.PolicyFile$1.run(PolicyFile.java:232)
[JBoss-dev] [ jboss-Bugs-524241 ] Exception in service lifecyle operation
Bugs item #524241, was opened at 2002-03-01 03:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524241&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Cristian Malinescu (crismally) Assigned to: Nobody/Anonymous (nobody) Summary: Exception in service lifecyle operation Initial Comment: Begin of stack trace : .. 15:05:54,843 INFO [EJBDeployer] Deploying FirstEntity 15:05:55,062 INFO [EJBDeployer] Deploying FirstSession 15:05:55,281 ERROR [EntityContainer] Exception in service lifecyle operation: create org.jboss.deployment.DeploymentException: expected one strategy tag at org.jboss.metadata.MetaData.getUniqueChild (MetaData.java:95) at org.jboss.metadata.MetaData.getUniqueChildContent (MetaData.java:202) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCReadAheadMe taData.(JDBCReadAheadMetaData.java:91) continued in many pages No problem to deploy and test with jboss 3.0 alpha, problem with 3.0 public beta and cvs beta2 Inside of the attached *.jar you have all the info you need ... OS, JDK, DB SRV etc. Regards, -- Comment By: Cristian Malinescu (crismally) Date: 2002-03-01 10:14 Message: Logged In: YES user_id=318586 Problem solved : Wrong usage of read-ahead tag definition Sorry for trouble continue testing for our use I will send the results regards, -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524241&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] EAR deployment
Thanks Dave, these should be only in create (to create) and destroy(to remove). I wonder how the ears in the testsuite got deployed? david jencks On 2002.03.01 10:23:01 -0500 Dave Smith wrote: > When deploying an ear I am getting > > 2002-03-01 09:39:05,228 ERROR > [org.jboss.management.j2ee.J2EEApplication] Could not create JSR-77 > J2EEApplication: cadexTest.ear > javax.management.InstanceAlreadyExistsException: > >jboss.management.single:J2EEDomain=Manager,J2EEServer=Single,name=cadexTest.ear,type=J2EEApplication > > > Now in EARDeployer.java in the start,init and destroy methods it looks > like the J2EEApplication.create should be commented out but they are > prefixed with //. I took out these three bits of code and it still > deployed my ear so I think this code should be commented out. > > Now on to why my class in the war file is not getting reloaded. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-524241 ] Exception in service lifecyle operation
Bugs item #524241, was opened at 2002-03-01 09:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524241&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Cristian Malinescu (crismally) Assigned to: Nobody/Anonymous (nobody) Summary: Exception in service lifecyle operation Initial Comment: Begin of stack trace : .. 15:05:54,843 INFO [EJBDeployer] Deploying FirstEntity 15:05:55,062 INFO [EJBDeployer] Deploying FirstSession 15:05:55,281 ERROR [EntityContainer] Exception in service lifecyle operation: create org.jboss.deployment.DeploymentException: expected one strategy tag at org.jboss.metadata.MetaData.getUniqueChild (MetaData.java:95) at org.jboss.metadata.MetaData.getUniqueChildContent (MetaData.java:202) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCReadAheadMe taData.(JDBCReadAheadMetaData.java:91) continued in many pages No problem to deploy and test with jboss 3.0 alpha, problem with 3.0 public beta and cvs beta2 Inside of the attached *.jar you have all the info you need ... OS, JDK, DB SRV etc. Regards, -- >Comment By: Cristian Malinescu (crismally) Date: 2002-03-01 16:14 Message: Logged In: YES user_id=318586 Problem solved : Wrong usage of read-ahead tag definition Sorry for trouble continue testing for our use I will send the results regards, -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=524241&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-524391 ] Patch for Bug 437043
Patches item #524391, was opened at 2002-03-01 16:01
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524391&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Greene (hgreene_np)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Bug 437043
Initial Comment:
Here's a patch for bug 437043. It's against
"jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCFindEntitiesCommand.java"
revision 1.17 (tagged "Rel_3_0_0_4") but I'd also like
to see it back-ported to any further 2.4.x releases :-)
This is a trivial patch and I just spent half a day
working out what on earth was going on here so,
pretty-please, put it in Real Soon Now :-) Ta.
--- JDBCFindEntitiesCommand.java.orig Fri Mar 1
15:55:00 2002
+++ JDBCFindEntitiesCommand.javaFri Mar 1
15:55:34 2002
@@ -74,7 +74,7 @@
{
Method m = customMethods[i];
String name = m.getName();
-if
(name.startsWith("ejbFindBy")) {
+if (name.startsWith("ejbFind")) {
String remoteName =
"f"+name.substring(4);
try {
knownFinderCommands.put(remoteName, new
CustomFindByEntitiesCommand(m));
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524391&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/deployment EARDeployer.java
User: d_jencks
Date: 02/03/01 07:59:05
Modified:src/main/org/jboss/deployment EARDeployer.java
Log:
removed doubled J2EEApplication.create from init method, leaving the one in create
where it belongs
Revision ChangesPath
1.8 +1 -15 jboss/src/main/org/jboss/deployment/EARDeployer.java
Index: EARDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/deployment/EARDeployer.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- EARDeployer.java 22 Feb 2002 04:24:55 - 1.7
+++ EARDeployer.java 1 Mar 2002 15:59:05 - 1.8
@@ -49,7 +49,7 @@
/**
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
-* @version $Revision: 1.7 $
+* @version $Revision: 1.8 $
*/
public class EARDeployer
extends ServiceMBeanSupport
@@ -131,15 +131,6 @@
throw new DeploymentException("Error in accessing application metadata: ",
e);
}
- // Create the appropriate JSR-77 instance
-// /*
- ObjectName lApplication = J2EEApplication.create(
- server,
- di.shortName,
- di.url
- // di.getApplicationDeploymentDescriptor()
- );
-// */
}
@@ -149,14 +140,11 @@
// now try to deploy
log.info("Deploying J2EE application, create step: " + di.url);
// Create the appropriate JSR-77 instance
-// /*
ObjectName lApplication = J2EEApplication.create(
server,
di.shortName,
di.url
- // di.getApplicationDeploymentDescriptor()
);
-// */
}
public void start(DeploymentInfo di)
@@ -179,13 +167,11 @@
public void destroy(DeploymentInfo di) throws DeploymentException
{
log.info("Undeploying J2EE application, destroy step: " + di.url);
-// /*
// Destroy the appropriate JSR-77 instance
J2EEApplication.destroy(
server,
di.shortName
);
-// */
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/capability DispatchClassLoader.java OptimizedMBeanDispatcher.java
User: juhalindfors
Date: 02/03/01 07:52:59
Modified:src/main/org/jboss/mx/capability
OptimizedMBeanDispatcher.java
Added: src/main/org/jboss/mx/capability DispatchClassLoader.java
Log:
all the class mungling done in-memory
Revision ChangesPath
1.2 +39 -22
jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java
Index: OptimizedMBeanDispatcher.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- OptimizedMBeanDispatcher.java 28 Feb 2002 19:58:14 - 1.1
+++ OptimizedMBeanDispatcher.java 1 Mar 2002 15:52:59 - 1.2
@@ -16,7 +16,9 @@
import java.util.Iterator;
import java.util.List;
-import java.io.File;
+import java.io.ByteArrayOutputStream;
+import java.io.BufferedOutputStream;
+
import java.net.URL;
import java.net.URLClassLoader;
@@ -77,12 +79,19 @@
/**
- * Byte code optimized dispatcher for Standard MBeans.
+ * Byte code optimized dispatcher for Standard MBeans. This dispatcher generates
+ * an invoke implementation that handles the operation dispatching without
+ * Java reflection.
+ *
+ * The use of this dispatcher may be controlled by setting a
+ * {@link org.jboss.mx.server.ServerConstants#OPTIMIZE_REFLECTED_DISPATCHER
OPTIMIZE_REFLECTED_DISPATCHER}
+ * property to either "true" or "false" string value.
*
* @see org.jboss.mx.capability.ReflectedMBeanDispatcher
+ * @see org.jboss.mx.capability.DispatchClassLoader
*
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
*/
public class OptimizedMBeanDispatcher
@@ -96,16 +105,6 @@
{
try
{
- // FIXME: just a hack for now, we shouldnt use the file system,
- //instead create a custom cl for the generated class and feed
- //the byte stream directly
- //
- // ALSO NOTICE if youre editing the code that creates byte codes to
- // 'build clobber' before you run test to delete the existing classes.
- // Otherwise the system classloader will pick up the classes generated
- // from the previous run
-
-
// construct class template
String className = resource.getClass().getName().replace('.', '_') +
"_Dispatcher";
String superClass= SUPER_CLASS.getName();
@@ -122,8 +121,18 @@
JavaClass c = clazz.getJavaClass();
- File file = new File("output\\classes\\" + fileName);
- c.dump(file);
+ ByteArrayOutputStream baos = new ByteArrayOutputStream(2000);
+ BufferedOutputStream bos = new BufferedOutputStream(baos);
+ c.dump(bos);
+
+ LoaderRepository rep = LoaderRepository.getDefaultLoaderRepository();
+
+ // FIXME: what about ctx cl?
+ // FIXME: also I dont know if the parent is right here, have to check later
+ DispatchClassLoader dcl = new
DispatchClassLoader(resource.getClass().getClassLoader(), className,
baos.toByteArray());
+ rep.addClassLoader(dcl);
+
+ // FIXME: throw the DLC away when an MBean is unregistered!
Class dispatcherClass = DefaultLoaderRepository.loadClass(className);
Constructor constr = dispatcherClass.getConstructor(
@@ -220,6 +229,14 @@
elsereturn "L" +
name.replace('.', '/') + ";";
}
+ /**
+* Checks if a given name matches the TYPE name of a primitive wrapper
class.
+*
+* @see java.lang.Integer#TYPE
+*
+* @param name TYPE.getName()
+* @return true if is a primitive type name; false otherwise
+*/
public static boolean isPrimitive(String name)
{
if (name.equals(Byte.TYPE.getName()) ||
@@ -338,10 +355,11 @@
int invokeIndex = cp.addMethodref(
SUPER_CLASS.getName(),
"invoke",
-"(L" + String.class.getName().replace('.', '/') + ";"
- + Object[].class.getName().replace('.', '/')
- + String[].class.getName().replace('.', '/') + ")L"
- + Object.class.getName().replace('.', '/') + ";"
+"(" + getDescriptorForType(String.class.getName())
++ getDescriptorForType(Object[].class.getName())
++ getDescriptorForType(String[].class.getName())
++
+")" + getDescriptorForType(Object.class.getName())
);
int getResourceObjectIndex = cp.addMethodref(
[JBoss-dev] [ jboss-Patches-524384 ] Patch for Bug 512649
Patches item #524384, was opened at 2002-03-01 15:54
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524384&group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole (unstable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Greene (hgreene_np)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch for Bug 512649
Initial Comment:
Hi guys,
here's a patch for Bug 512649, which I just bumped
into. This is against
"jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/bmp/CustomFindByEntitiesCommand.java"
revision 1.12 (i.e., release 3.0), though I'd also like
to see it back-ported to any further 2.4.x releases :-)
I've used printStackTrace to extract the maximum info
from the Throwable, though you may prefer to just use
"target.toString()". This is untested "but it should
just work" :-)
--- CustomFindByEntitiesCommand.java.orig Fri Mar
1 15:47:04 2002
+++ CustomFindByEntitiesCommand.javaFri Mar 1
15:46:20 2002
@@ -7,6 +7,9 @@
package org.jboss.ejb.plugins.jaws.bmp;
+import java.io.PrintWriter;
+import java.io.StringWriter;
+
import java.lang.reflect.Method;
import java.lang.reflect.InvocationTargetException;
@@ -93,7 +96,9 @@
if(target instanceof Exception) {
throw (Exception)target;
}
-throw new FinderException("Unable to
initialize finder implementation: " +
finderImplMethod.getName());
+StringWriter sw = new StringWriter();
+target.printStackTrace(new PrintWriter(sw));
+throw new FinderException("Throwable from
finder implementation: " + finderImplMethod.getName() +
": " + sw.toString());
}
}
}
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=524384&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
ok sorry for freaking out, man I am prissy this morning. in a general bad mood, marcf |-Original Message- |From: Sacha Labourey [mailto:[EMAIL PROTECTED]] |Sent: Friday, March 01, 2002 7:32 AM |To: marc fleury; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] CVS update: |jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java | | |No ;) | |No sub-partitions ;) | |cluster <=> partition != sub-partition | |Partitions have always be in. What you don't get are *sub*-partitions. But |this CVS log doesn't concern sub-partition at all. | |sky is blue. | |> -Message d'origine- |> De : marc fleury [mailto:[EMAIL PROTECTED]] |> Envoyé : vendredi, 1 mars 2002 19:27 |> À : Sacha Labourey; [EMAIL PROTECTED] |> Objet : RE: [JBoss-dev] CVS update: |> jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java |> |> |> oh no, complexity creeping back in??? |> |> no sub partitions, please, I still don't get what they do. |> |> marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
Are you sure you need the element at all? Unless you are loading from an http: url you should be fine by removing this element entirely. I guess I better go through everything and do this... I already got a lot of messages from them being in the db config examples. david jencks On 2002.03.01 10:23:00 -0500 Hiram Chirino wrote: > it would be kinda nice if the url's in the service.xml file were relative > to > the service.xml file. Do I make sense?? so if the service.xml files is: > /jboss/server/default/deploy/jbossmq-service.xml > To load all the jboss/lib jars : > > To load all the jars in the server's lib dirctory: > /jboss/server/default/lib > > > Regards, > Hiram > > >From: Jason Dillon <[EMAIL PROTECTED]> > >To: David Jencks <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED] > >Subject: Re: [JBoss-dev] Property access in *service.xml and relative > paths > >Date: Thu, 28 Feb 2002 19:51:32 -0800 > > > >I sent mail on this before I commited the layout change. It has todo > >with which directory/url do we use to qualify relative paths. It also > >has todo with allow a global and per-server config library directory. > > > >--jason > > > > > >David Jencks wrote: > > > >>On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: > >> > >>>I was thinking that a solution to the problem that MD now has due to > the > >>>layout changes that I made WRT relatives paths could be solved by > >>>forcing users to be explicit about which path they which to use (ie. > not > >>>allowing relative paths). > >>> > >> > >>What are these problems? I haven't noticed any. Using > > >>can > >>cause problems, but it is almost always better to just leave the tag > out. > >> > >>david jencks > >> > >> > >>>To make this work we need to expose some system property access inside > >>>of the *service.xml files... probably as an attribute value subst and > an > >>>element... for example: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Which could then be used in config elements later in the file... > >>> > >>>And to finally solve the two lib problem... just more than one > classpath > >>>(if that isn't the case already): > >>> > >>> > >>> > >>> > >>>This would prefer libs from inside jboss.server.home.dir/lib before > >>>jboss.home.dir/lib > >>> > >>>--jason > >>> > >>> > >>>___ > >>>Jboss-development mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > >>> > >>> > > > > > > > >___ > >Jboss-development mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp. > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
oh no, complexity creeping back in???
no sub partitions, please, I still don't get what they do.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha
|Labourey
|Sent: Friday, March 01, 2002 4:36 AM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
|
|
| User: slaboure
| Date: 02/03/01 04:35:30
|
| Modified:src/main/org/jboss/ha/framework/server HAPartitionImpl.java
| Log:
| Unbind in NonSerializableFactory was not performed at service shutdown
|
| Revision ChangesPath
| 1.17 +6 -2
|jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
|
| Index: HAPartitionImpl.java
| ===
| RCS file:
|/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPar
|titionImpl.java,v
| retrieving revision 1.16
| retrieving revision 1.17
| diff -u -r1.16 -r1.17
| --- HAPartitionImpl.java 17 Feb 2002 03:34:27 - 1.16
| +++ HAPartitionImpl.java 1 Mar 2002 12:35:29 - 1.17
| @@ -33,7 +33,7 @@
|*
|* @author mailto:[EMAIL PROTECTED]";>Sacha
|Labourey.
|* @author mailto:[EMAIL PROTECTED]";>Bill Burke.
| - * @version $Revision: 1.16 $
| + * @version $Revision: 1.17 $
|*
|* Revisions:
|*/
| @@ -179,13 +179,17 @@
|log.error("operation failed", e);
| }
|
| + String boundName = "/HAPartition/" + partitionName;
| +
| InitialContext ctx = new InitialContext();
| try {
| - ctx.unbind("/HAPartition/" + partitionName);
| +
| + ctx.unbind(boundName);
| }
| finally {
|ctx.close();
| }
| + NonSerializableFactory.unbind (boundName);
|
| log.info("Partition " + partitionName + " closed.");
| }
|
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
No ;) No sub-partitions ;) cluster <=> partition != sub-partition Partitions have always be in. What you don't get are *sub*-partitions. But this CVS log doesn't concern sub-partition at all. sky is blue. > -Message d'origine- > De : marc fleury [mailto:[EMAIL PROTECTED]] > Envoyé : vendredi, 1 mars 2002 19:27 > À : Sacha Labourey; [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] CVS update: > jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java > > > oh no, complexity creeping back in??? > > no sub partitions, please, I still don't get what they do. > > marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] EAR deployment
When deploying an ear I am getting 2002-03-01 09:39:05,228 ERROR [org.jboss.management.j2ee.J2EEApplication] Could not create JSR-77 J2EEApplication: cadexTest.ear javax.management.InstanceAlreadyExistsException: jboss.management.single:J2EEDomain=Manager,J2EEServer=Single,name=cadexTest.ear,type=J2EEApplication Now in EARDeployer.java in the start,init and destroy methods it looks like the J2EEApplication.create should be commented out but they are prefixed with //. I took out these three bits of code and it still deployed my ear so I think this code should be commented out. Now on to why my class in the war file is not getting reloaded. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Property access in *service.xml and relative paths
it would be kinda nice if the url's in the service.xml file were relative to the service.xml file. Do I make sense?? so if the service.xml files is: /jboss/server/default/deploy/jbossmq-service.xml To load all the jboss/lib jars : To load all the jars in the server's lib dirctory: /jboss/server/default/lib Regards, Hiram >From: Jason Dillon <[EMAIL PROTECTED]> >To: David Jencks <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: [JBoss-dev] Property access in *service.xml and relative paths >Date: Thu, 28 Feb 2002 19:51:32 -0800 > >I sent mail on this before I commited the layout change. It has todo >with which directory/url do we use to qualify relative paths. It also >has todo with allow a global and per-server config library directory. > >--jason > > >David Jencks wrote: > >>On 2002.02.28 22:35:27 -0500 Jason Dillon wrote: >> >>>I was thinking that a solution to the problem that MD now has due to the >>>layout changes that I made WRT relatives paths could be solved by >>>forcing users to be explicit about which path they which to use (ie. not >>>allowing relative paths). >>> >> >>What are these problems? I haven't noticed any. Using >>can >>cause problems, but it is almost always better to just leave the tag out. >> >>david jencks >> >> >>>To make this work we need to expose some system property access inside >>>of the *service.xml files... probably as an attribute value subst and an >>>element... for example: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>Which could then be used in config elements later in the file... >>> >>>And to finally solve the two lib problem... just more than one classpath >>>(if that isn't the case already): >>> >>> >>> >>> >>>This would prefer libs from inside jboss.server.home.dir/lib before >>>jboss.home.dir/lib >>> >>>--jason >>> >>> >>>___ >>>Jboss-development mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >>> > > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] org.jboss.deployment.scanner.DeploymentScanner
If you want to do something else that is useful jason... |I just realized how simple it would be to do all of the same |functionality that DDS does and retain any URL capabilites in the same |component... I was so into the local/directory only thing that I did |not see it. | |I will add URLDeploymentScanner tomorrow... scanning URLs is not simple, getting the last modified on a URL is trivial. However before we get there, we need to make sure that the deployers work for url based deployments. Do you want to try to make the real URL based deployment work? I made it work in 3.0 pre-alpha but since then "earth bound filesystem" dirs creep back in. That would be a first step. |> I was also not planning on letting DeploymentInfo seep into this |> layer... but after thinking and attempting to implement this in a that is good, don't change that, I don't know what you think it is a problem (and don't bother answering in 3 volumes, it is a minor point). |> different way, re-using this turned out to be the easiest and |> simpelest way to get this finished. I hope that this can be sorted |> out later, as right now it is not idea. The DS retains a set of DI |> objects which is only needs to know the lastModified for, and then |> MainDeployer also manages a list/has of these. |> |> I think that this could be fixed up with a combonation of David's xslt |> ideas + the Deployment/DeploymentManager bits I was talking about when |> I mentiond DeploymentScanner in the first place. don't |> For DDS, since it is file specific I removed the small bits of code |> which got the last modified time from an opened connection. The |> reason I did this was to keep the DDS simple by making it only have to |> worry about files and that is it. DDS WAS already URL/File but really we should abstract deployment location, wasn't there something in netbeans that abstracted files? But first making it work with URL based AT ALL is the step. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet todo...
You should be able to do the following:
/**
* blah
*/
public void myMethod()
{
/** @todo put something here */
}
Ken
- Original Message -
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: "Jason Dillon" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Thursday, February 28, 2002 10:26 PM
Subject: Re: [JBoss-dev] XDoclet todo...
> > This is really for the xdoclet list, but I am too lazy to find the
> > address for that (plus lots of them listen here too).
> >
> > Is there any easy way to allow xdoclet to search for tags inside of
> > methods too? For example, I find it much easier to put the TODO, where
> > the code should go, but I would like to keep using @todo.
> >
> > /**
> > * blah
> > */
> > public void myMethod()
> > {
> >/// @todo put something here
> > }
>
> Not at the moment, because XDoclet's tree come's from Sun's javadoc
engine.
>
> perhaps this could be added when the xjavadoc module is in use (the same
one that is going to allow in-vm generaetion :)
>
> cheers
> dim
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin jboss_init_redhat.sh
User: kimptoc
Date: 02/03/01 06:38:40
Modified:src/bin jboss_init_redhat.sh
Log:
test the location is a file not directory - DOH
Revision ChangesPath
1.7 +5 -0 jboss/src/bin/jboss_init_redhat.sh
Index: jboss_init_redhat.sh
===
RCS file: /cvsroot/jboss/jboss/src/bin/jboss_init_redhat.sh,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jboss_init_redhat.sh 1 Mar 2002 09:53:58 - 1.6
+++ jboss_init_redhat.sh 1 Mar 2002 14:38:39 - 1.7
@@ -35,6 +35,11 @@
JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh"}
if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then
+ # ensure the file exists
+ touch $JBOSS_CONSOLE
+fi
+
+if [ -n "$JBOSS_CONSOLE" -a ! -f "$JBOSS_CONSOLE" ]; then
echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE"
echo "WARNING: ignoring it and using /dev/null"
JBOSS_CONSOLE="/dev/null"
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] modularity vs simplicity
Hello, Currently, the client directory contains client-side jars needed to work with JBoss. While it is very modular to have one jar per "function" (clustering, security, ...) (and it is also easier to build as each module is responsible for building its own set of client-side JARs), in many cases, we end-up launching client side applications with a huuugge classpath containing at least 5 JBoss jars. Why not *also* build a "jbossall-client.jar" (or something like this) that would contain all client JARs generally needed? This would still allow fine-grained tuning for experts but also bring simplicity for quick-setup. Cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/hasessionstate/server HASessionStateImpl.java
User: slaboure
Date: 02/03/01 04:35:31
Modified:src/main/org/jboss/ha/hasessionstate/server
HASessionStateImpl.java
Log:
Unbind in NonSerializableFactory was not performed at service shutdown
Revision ChangesPath
1.7 +3 -2
jbossmx/src/main/org/jboss/ha/hasessionstate/server/HASessionStateImpl.java
Index: HASessionStateImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/hasessionstate/server/HASessionStateImpl.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- HASessionStateImpl.java 17 Feb 2002 03:34:27 - 1.6
+++ HASessionStateImpl.java 1 Mar 2002 12:35:31 - 1.7
@@ -53,7 +53,7 @@
* @see HASessionState
* @author [EMAIL PROTECTED]
* @author Bill Burke
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*
* Revisions:
* 2002/01/09: billb
@@ -169,8 +169,9 @@
{
try
{
- Context ctx = new InitialContext ();
+ Context ctx = new InitialContext ();
ctx.unbind (this._sessionStateName);
+ NonSerializableFactory.unbind (this._sessionStateName);
}
catch (Exception ignored)
{}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server HAPartitionImpl.java
User: slaboure
Date: 02/03/01 04:35:30
Modified:src/main/org/jboss/ha/framework/server HAPartitionImpl.java
Log:
Unbind in NonSerializableFactory was not performed at service shutdown
Revision ChangesPath
1.17 +6 -2
jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java
Index: HAPartitionImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/HAPartitionImpl.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- HAPartitionImpl.java 17 Feb 2002 03:34:27 - 1.16
+++ HAPartitionImpl.java 1 Mar 2002 12:35:29 - 1.17
@@ -33,7 +33,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
* @author mailto:[EMAIL PROTECTED]";>Bill Burke.
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*
* Revisions:
*/
@@ -179,13 +179,17 @@
log.error("operation failed", e);
}
+ String boundName = "/HAPartition/" + partitionName;
+
InitialContext ctx = new InitialContext();
try {
- ctx.unbind("/HAPartition/" + partitionName);
+
+ ctx.unbind(boundName);
}
finally {
ctx.close();
}
+ NonSerializableFactory.unbind (boundName);
log.info("Partition " + partitionName + " closed.");
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server ClusterPartition.java
User: slaboure Date: 02/03/01 04:36:24 Modified:src/main/org/jboss/ha/framework/server ClusterPartition.java Log: Set JavaGroups properties generally suggested by Bela Ban (pbcast protocols) Revision ChangesPath 1.15 +17 -3 jbossmx/src/main/org/jboss/ha/framework/server/ClusterPartition.java Index: ClusterPartition.java === RCS file: /cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/ClusterPartition.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- ClusterPartition.java 17 Feb 2002 03:34:27 - 1.14 +++ ClusterPartition.java 1 Mar 2002 12:36:24 - 1.15 @@ -25,7 +25,7 @@ * * @author mailto:[EMAIL PROTECTED]";>Bill Burke. * @author mailto:[EMAIL PROTECTED]";>Sacha Labourey. - * @version $Revision: 1.14 $ + * @version $Revision: 1.15 $ * * Revisions: */ @@ -39,7 +39,7 @@ // Attributes protected String partitionName = org.jboss.metadata.ClusterConfigMetaData.DEFAULT_PARTITION; - protected String jgProps = + protected String jgProps = /* "UDP(mcast_addr=228.1.2.3;mcast_port=45566):" + "PING:" + "FD(timeout=5000):" + @@ -51,7 +51,21 @@ "FLUSH:" + "GMS:" + "STATE_TRANSFER:" + - "QUEUE"; + "QUEUE";*/ + "UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=64;" + + "mcast_send_buf_size=15;mcast_recv_buf_size=8):" + + "PING(timeout=2000;num_initial_members=3):" + + "MERGE2(min_interval=5000;max_interval=1):" + + "FD_SOCK:" + + "VERIFY_SUSPECT(timeout=1500):" + + "pbcast.STABLE(desired_avg_gossip=2):" + + "pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):" + + "UNICAST(timeout=5000;min_wait_time=2000):" + + "FRAG(down_thread=false;up_thread=false):" + + // "CAUSAL:" + + "pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;" + + "shun=false;print_local_addr=true):" + + "pbcast.STATE_TRANSFER"; /* protected String jgProps = "UDP:" + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/ha/framework/server DistributedReplicantManagerImpl.java
User: slaboure
Date: 02/03/01 04:11:34
Modified:src/main/org/jboss/ha/framework/server
DistributedReplicantManagerImpl.java
Log:
Severe bug: could not get node name at construtor-time.
Revision ChangesPath
1.15 +3 -2
jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java
Index: DistributedReplicantManagerImpl.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/ha/framework/server/DistributedReplicantManagerImpl.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- DistributedReplicantManagerImpl.java 27 Feb 2002 11:06:12 - 1.14
+++ DistributedReplicantManagerImpl.java 1 Mar 2002 12:11:34 - 1.15
@@ -29,7 +29,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Bill Burke.
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey.
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*
* Revisions:
* 2001/10/31: marcf
@@ -85,7 +85,6 @@
this.mbeanserver = server;
this.log = Logger.getLogger(partition.getPartitionName() +
":ReplicantManager");
- this.nodeName = this.partition.getNodeName ();
}
// Public
@@ -110,6 +109,8 @@
public void start() throws Exception
{
+ this.nodeName = this.partition.getNodeName ();
+
log.info("mergemembers");
mergeMembers();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/compliance/metadata/support Trivial.java TrivialMBean.java
User: juhalindfors
Date: 02/03/01 04:02:25
Added: src/main/test/compliance/metadata/support Trivial.java
TrivialMBean.java
Log:
Revision ChangesPath
1.1 jmx/src/main/test/compliance/metadata/support/Trivial.java
Index: Trivial.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package test.compliance.metadata.support;
public class Trivial implements TrivialMBean
{
private String something = null;
private boolean anAttribute = true;
public void setSomething(String thing)
{
this.something = thing;
}
public String getSomething()
{
return something;
}
public void setSomethingInvalid(String thing)
{
this.something = thing;
}
public String getSomethingInvalid(Object invalid)
{
return something;
}
public void setSomethingInvalid2(String thing)
{
this.something = thing;
}
public void getSomethingInvalid2()
{
//return this.something;
}
public void doOperation(String arg)
{
}
}
1.1 jmx/src/main/test/compliance/metadata/support/TrivialMBean.java
Index: TrivialMBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package test.compliance.metadata.support;
public interface TrivialMBean
{
void setSomething(String thing);
String getSomething();
void setSomethingInvalid(String thing);
String getSomethingInvalid(Object invalid);
void setSomethingInvalid2(String thing);
void getSomethingInvalid2();
void doOperation(String arg);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/compliance/metadata MetaDataSUITE.java
User: juhalindfors Date: 02/03/01 04:01:42 Modified:src/main/test/compliance/metadata MetaDataSUITE.java Log: Revision ChangesPath 1.3 +2 -1 jmx/src/main/test/compliance/metadata/MetaDataSUITE.java Index: MetaDataSUITE.java === RCS file: /cvsroot/jboss/jmx/src/main/test/compliance/metadata/MetaDataSUITE.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- MetaDataSUITE.java24 Feb 2002 14:18:26 - 1.2 +++ MetaDataSUITE.java1 Mar 2002 12:01:42 - 1.3 @@ -14,7 +14,7 @@ * Test cases for JMX metadata classes. * * @author mailto:[EMAIL PROTECTED]";>Juha Lindfors. - * @version $Revision: 1.2 $ + * @version $Revision: 1.3 $ */ public class MetaDataSUITE extends TestSuite @@ -31,6 +31,7 @@ suite.addTest(new TestSuite(MBeanFeatureInfoTEST.class)); suite.addTest(new TestSuite(MBeanOperationInfoTEST.class)); + suite.addTest(new TestSuite(MBeanAttributeInfoTEST.class)); return suite; } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/compliance/metadata/support - New directory
User: juhalindfors Date: 02/03/01 04:01:01 jmx/src/main/test/compliance/metadata/support - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/test/compliance/metadata MBeanAttributeInfoTEST.java
User: juhalindfors
Date: 02/03/01 04:05:37
Added: src/main/test/compliance/metadata
MBeanAttributeInfoTEST.java
Log:
Revision ChangesPath
1.1
jmx/src/main/test/compliance/metadata/MBeanAttributeInfoTEST.java
Index: MBeanAttributeInfoTEST.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package test.compliance.metadata;
import junit.framework.TestCase;
import junit.framework.AssertionFailedError;
import java.lang.reflect.Method;
import javax.management.MBeanAttributeInfo;
import javax.management.IntrospectionException;
import test.compliance.metadata.support.Trivial;
/**
* Tests MBeanAttributeInfo.
*
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors.
* @version $Revision: 1.1 $
*/
public class MBeanAttributeInfoTEST extends TestCase
{
public MBeanAttributeInfoTEST(String s)
{
super(s);
}
/**
* Tests MBeanAttributeInfo(String name, String descr, Method getter, Method
setter) constructor.
*/
public void testConstructorWithAccessorMethods()
{
try
{
Class c = Trivial.class;
Method getter = c.getMethod("getSomething", new Class[0]);
Method setter = c.getMethod("setSomething", new Class[] { String.class });
MBeanAttributeInfo info = new MBeanAttributeInfo("Something", "a
description", getter, setter);
assertTrue(info.getDescription().equals("a description"));
assertTrue(info.getName().equals("Something"));
assertTrue(info.getType().equals("java.lang.String"));
assertTrue(info.isReadable() == true);
assertTrue(info.isWritable() == true);
assertTrue(info.isIs() == false);
}
catch (AssertionFailedError e)
{
throw e;
}
catch (Throwable t)
{
t.printStackTrace();
fail("Unexpected error: " + t.toString());
}
}
/**
* Tests MBeanAttributeInfo(String name, String descr, Method getter, Method
setter) with misplaced accessor methods.
*/
public void testConstructorWithMisplacedAccessorMethods()
{
try
{
Class c = Trivial.class;
Method getter = c.getMethod("getSomething", new Class[0]);
Method setter = c.getMethod("setSomething", new Class[] { String.class });
MBeanAttributeInfo info = new MBeanAttributeInfo("Something", "a
description", setter, getter);
// shouldn't reach here
fail("Introspection exception should have been thrown.");
}
catch (IntrospectionException e)
{
// this is expected
}
catch (AssertionFailedError e)
{
throw e;
}
catch (Throwable t)
{
t.printStackTrace();
fail("Unexpected error: " + t.toString());
}
}
/**
* Tests MBeanAttributeInfo(String name, String descr, Method getter, Method
setter) with invalid getter method.
*/
public void testConstructorWithInvalidGetterMethod()
{
try
{
Class c = Trivial.class;
Method getter = c.getMethod("getSomethingInvalid", new Class[] {
Object.class });
Method setter = c.getMethod("setSomethingInvalid", new Class[] {
String.class });
MBeanAttributeInfo info = new MBeanAttributeInfo("Something", "a
description", getter, setter);
// shouldn't reach here
fail("Introspection exception should have been thrown.");
}
catch (IntrospectionException e)
{
// this is expected
}
catch (AssertionFailedError e)
{
throw e;
}
catch (Throwable t)
{
t.printStackTrace();
fail("Unexpected error: " + t.toString());
}
}
/**
* Tests MBeanAttributeInfo(String name, String descr, Method getter, Method
setter) with invalid getter method (void return type).
*/
public void testConstructorWithInvalidGetterMethod2()
{
try
{
Class c = Trivial.class;
Method getter = c.getMethod("getSomethingInvalid2", new Class[] { } );
Method setter = c.getMethod("setSomethingInvalid2", new Class[] {
String.class });
MBeanAttributeInfo info = new MBeanAttributeInfo("Something", "a
description", getter, setter);
// shouldn't reach here
fail("Introspection exception should have been thrown.");
}
catch (IntrospectionException e)
{
/
[JBoss-dev] [ jboss-Bugs-523861 ] Intermittent Missing Security Context
Bugs item #523861, was opened at 2002-02-28 15:04
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=523861&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: John Baker (bongo_john)
Assigned to: Nobody/Anonymous (nobody)
Summary: Intermittent Missing Security Context
Initial Comment:
jdk1.3.1_02 / Win2000 / JBoss2.4.2 with Tomcat 3.2.3
This is unfortunately hard to reproduce but thought I
should let you know. I also have found a workaround
which may be useful for others. I have been
experiencing problems with connecting to a stateless
session bean using the ClientLoginModule along side
the JDBCLoginModule.
// stack trace from first ejb call to
getCallerPrincipal
[ERROR,Default] java.lang.IllegalStateException: No
security context set
[ERROR,Default] at
org.jboss.ejb.EnterpriseContext$EJBContextImpl.getCal
lerPrincipal(EnterpriseContext.java:258)
[ERROR,Default]
[ERROR,Default] at
com.katalyzt.toolbox.model.ejb.TModelSessionBean.getC
allerId(TModelSessionBean.java:72)
[ERROR,Default]
[ERROR,Default] at
com.katalyzt.toolbox.model.ejb.TModelSessionBean.getU
ser(TModelSessionBean.java:58)
[ERROR,Default]
[ERROR,Default] at
com.katalyzt.toolbox.model.ejb.TModelSessionBean.ejbC
reate(TModelSessionBean.java:35)
I'm very relieved that after a bit more investigation
I have found a workaround by altering some of my code
to not use getCallerPrincipal() in ejbCreate(). It
seems that intermittently the security context in not
yet available at this point in the life cycle. I
suspect that some synchronization issue is afoot. I
believe the specs allow this call in ejbCreate().
Correct me if I'm wrong on that. It doesn't ever
occurr when this is used outside of ejbCreate().
An interesting thing is that this must of been
actually going on for the last six months but I had
covered it up with a workaround for a bug in a
different app server! The getCallerPrincipal() was
until recently wrapped in a try catch that gave the
user id as "Guest" if the call failed. This was
allowing a temporary identity which would get switched
to the real one on the next call! This code was
removed a few weeks ago but as the problem is
intermittent I only noticed it this week when it
started happening a lot!!
It is extremely unpredicatable and don't really know
how to reproduce it as restarting jboss sometimes
makes it dissappear.
Hope this helps and you have a better insight into why
this might happen. It may be that something is
incorrectly configured but I really just alter
slightly your default configuration mainly for DB
access.
--
>Comment By: John Baker (bongo_john)
Date: 2002-03-01 11:58
Message:
Logged In: YES
user_id=346085
// Code that produces this (without this doesn't occur)
public void ejbCreate() throws CreateException
{
// Test jboss
sessionContext.getCallerPrincipal().getName();
}
// EJB XML
TModelSession
com.katalyzt.toolbox.model.ejb.TModelSessionHome
com.katalyzt.toolbox.model.ejb.TModelSession
com.katalyzt.toolbox.model.ejb.TModelSessionBean
Stateless
Container
jdbc/KatalyztDB
javax.sql.DataSource
Container
ToolboxUser
TModelSession
*
TModelSession
*
Required
// JBoss XML
java:/jaas/katalyzt
TModelSession
katalyzt/toolbox/model/TModelSessionHome
jdbc/KatalyztDB
java:/KatalyztDB
// The stack trace
[ERROR,TModelSession] TRANSACTION ROLLBACK EXCEPTION:
javax.transaction.TransactionRolledbackException: null
Embedded Exception
No security context set; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
No security context set
javax.ejb.EJBException: null
Embedded Exception
No security context set
at
org.jboss.ejb.StatelessSessionEnterpriseContext.
(StatelessSessi
onEnterpriseContext.java:61)
at
org.jboss.ejb.plugins.StatelessSessionInstancePool.create
(StatelessSe
ssionInstancePool.java:62)
at org.jboss.ejb.plugins.AbstractInstancePool.add
(AbstractInstancePool.j
ava:153)
at
org.jboss.ejb.plugins.AbstractInstancePool.internalGet
(AbstractInstan
cePool.java:216)
at org.jboss.ejb.plugins.AbstractInstancePool.get
(AbstractInstancePool.j
ava:191)
at
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.in
voke(Stat
elessSessionInstanceInterceptor.java:74)
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext
(TxInterceptorCMT.ja
va:138)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions
(TxIntercep
torCMT.java:347)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:1
00)
at org.jboss.ejb.plugins.SecurityInter
[JBoss-dev] CVS update: jmx/src/main/javax/management MBeanAttributeInfo.java MBeanOperationInfo.java
User: juhalindfors
Date: 02/03/01 03:57:34
Modified:src/main/javax/management MBeanAttributeInfo.java
MBeanOperationInfo.java
Log:
javadocs + cleanup
Revision ChangesPath
1.4 +96 -11jmx/src/main/javax/management/MBeanAttributeInfo.java
Index: MBeanAttributeInfo.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/MBeanAttributeInfo.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MBeanAttributeInfo.java 10 Dec 2001 17:21:13 - 1.3
+++ MBeanAttributeInfo.java 1 Mar 2002 11:57:34 - 1.4
@@ -7,6 +7,7 @@
package javax.management;
import java.lang.reflect.Method;
+import java.io.Serializable;
/**
* Represents a management attribute in an MBeans' management interface.
@@ -14,45 +15,98 @@
* @see javax.management.MBeanInfo
*
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
*/
public class MBeanAttributeInfo extends MBeanFeatureInfo
- implements java.io.Serializable, Cloneable
+ implements Serializable, Cloneable
{
// Attributes
- protected String type = null;
- protected boolean isReadable = false;
- protected boolean isWritable = false;
- protected boolean isIs = false;
+
+ /**
+* Attribute type string. This is a fully qualified class name of the type.
+*/
+ private String type= null;
+
+ /**
+* Is attribute readable.
+*/
+ private boolean isReadable = false;
+
+ /**
+* Is attribute writable.
+*/
+ private boolean isWritable = false;
+
+ /**
+* Is attribute using the boolean isAttributeName naming convention.
+*/
+ private boolean isIs = false;
+
// Constructors --
+
+ /**
+* Creates an MBean attribute info object.
+*
+* @param name name of the attribute
+* @param type the fully qualified class name of the attribute's type
+* @param description human readable description string of the attribute
+* @param isReadable if attribute is readable
+* @param isWritable if attribute is writable
+* @param isIs if attribute is using the boolean isAttributeName
naming convention for its getter method
+*/
public MBeanAttributeInfo(String name, String type, String description,
boolean isReadable, boolean isWritable, boolean isIs)
{
super(name, description);
+
this.type = type;
this.isReadable = isReadable;
this.isWritable = isWritable;
this.isIs = isIs;
}
+ /**
+* Creates an MBean attribute info object using the given accessor methods.
+*
+* @param nameName of the attribute.
+* @param description Human readable description string of the attribute's
type.
+* @param getter The attribute's read accessor. May be null if
the attribute is write-only.
+* @param setter The attribute's write accessor. May be null if
the attribute is read-only.
+*
+* @throws IntrospectionException if the accessor methods are not valid for the
attribute
+*/
public MBeanAttributeInfo(String name, String description, Method getter, Method
setter)
- throws IntrospectionException
+ throws IntrospectionException
{
super(name, description);
if (getter != null)
{
+ // getter must always be no args method, return type cannot be void
+ if (getter.getParameterTypes().length != 0)
+throw new IntrospectionException("Expecting getter method to be of the
form 'AttributeType getAttributeName()': found getter with " +
getter.getParameterTypes().length + " parameters.");
+ if (getter.getReturnType() == Void.TYPE)
+throw new IntrospectionException("Expecting getter method to be of the
form 'AttributeType getAttributeName()': found getter with void return type.");
+
this.isReadable = true;
+
if (getter.getName().startsWith("is"))
this.isIs = true;
+
this.type = getter.getReturnType().getName();
}
if (setter != null)
{
+ // setter must have one argument, no less, no more. Return type must be
void.
+ if (setter.getParameterTypes().length != 1)
+throw new IntrospectionException("Expecting the setter method to be of
the form 'void setAttributeName(AttributeType value)': found setter with " +
setter.getParameterTypes().length + " parameters.");
+ if (
Re: [JBoss-dev] Automated JBoss Testsuite Results
Hi, --- Scott M Stark <[EMAIL PROTECTED]> wrote: > RedHat 7.2 with Sun JDK 1.3.1_02 is what is working for me: > Thanks for that - I've just installed that on the server too - so we will get 5 messages per day. I think the problem is solved - the latest jboss re-org had moved the location of the log directory and I was trying to pipe the console into an invalid directory - which seems to cause the server some problems - although I can't really believe this is the main cause. I also increased the time I allow for the server to warm up - it was 2mins - but my test runs show it taking 1min 40secs or so - which is getting close - so it now allows 5 mins for the server to warm up. Making this change alone was not enough to fix the problem - but the console logging seems to have helped - I am still running the tests. There are currently some connectivity issues with the test servers hosting company - but not enough to stop me working on it - so I don't think that should cause any problems either. Chris = Need somewhere to Live in London? - Then go to http://freeflats.com __ Do You Yahoo!? Yahoo! Greetings - Send FREE e-cards for every occasion! http://greetings.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/bin jboss_init_redhat.sh
User: kimptoc
Date: 02/03/01 01:53:58
Modified:src/bin jboss_init_redhat.sh
Log:
added some validation to the console location - seems to cause problems if its
invalid
Revision ChangesPath
1.6 +6 -0 jboss/src/bin/jboss_init_redhat.sh
Index: jboss_init_redhat.sh
===
RCS file: /cvsroot/jboss/jboss/src/bin/jboss_init_redhat.sh,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jboss_init_redhat.sh 5 Jan 2002 05:16:22 - 1.5
+++ jboss_init_redhat.sh 1 Mar 2002 09:53:58 - 1.6
@@ -34,6 +34,12 @@
#define the script to use to start jboss
JBOSSSH=${JBOSSSH:-"$JBOSS_HOME/bin/run.sh"}
+if [ -n "$JBOSS_CONSOLE" -a ! -d "$JBOSS_CONSOLE" ]; then
+ echo "WARNING: location for saving console log invalid: $JBOSS_CONSOLE"
+ echo "WARNING: ignoring it and using /dev/null"
+ JBOSS_CONSOLE="/dev/null"
+fi
+
#define what will be done with the console log
JBOSS_CONSOLE=${JBOSS_CONSOLE:-"/dev/null"}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] njar protocol is not working with security manager
Someone mentioned that 1.4 will allow for runtime config of security policy... why not defer tight policy integration until we have switched to it by default? Could also add njar to the system loader... It seems very strange to me that we now have huge names under tmp/deploy (which may not fully get removed... or do we scan down to tmp/deploy and delete parent directories when a deployment goes away) to get a security policy to work. It just seems very strange... --jason Scott M Stark wrote: >The njar url cannot be used in a security policy file as a codebase >because the njar protocol handler is not available when the >security system initializes: > >policy: Adding policy entry: >policy: signedBy null >policy: codeBase >njar:file:D:/usr/local/src/cvsroot/Main/jboss-all/build/outpu >t/jboss-3.0.0beta2/server/default/tmp/deploy/D/usr/local/src/cvsroot/Main/jb >oss- >all/build/output/jboss-3.0.0beta2/server/default/deploy/- >java.security.Policy: error adding Entry >sun.security.provider.PolicyParser$GrantEntry@2498b5 >java.net.MalformedURLException: unknown protocol: njar > >To work with a security manager the custom protocols must be available >at startup using the java.protocol.handler.pkgs property. > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > > > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Multipule configurations, expected usage...
> > >The final idea floating around is that of multiple configurations. I am >thinking that there are many deploy directories in the MainDeployer now (it >is capable of scanning many directories not just the /deploy one) and we >should take advantage of this. Maybe we could have >/conf/default/-service.xml >/conf/medium/-service.xml >/conf/nineyards/-service.xml > What is the point of providing multipule configurations? What are the expected usage of them? Do we expect users to use one of the provided configurations with out changing them? I mean, are we trying to provide a set of configurations which will be useable with no configuration in the users enviornment? I would hope not. We are talking about the configuration structure which is generated by the build system for use in development, testing and for release. The development role is way to complex to provide configurations for each use, so lets forget that one. For testing, we want to provide a config (or configs) which will cover all aspects of the system... which is a fat task and should be done externally by the JBoss/Testsuite module. That leaves us to the configuration structure for a release. What do we expect users todo with a release distribution? Do we expect them to use those configs asis in a production environment? I would hope not. We want to provide new users who are not famillar with JBoss or app servers with a painless way to get positive results that the 10 megs they just downloaded and uncompressed wasn't a waste of there time. We want a user to get the server started with a single command and no configuration and have that user go to the admin console and have their first look at a functional JBoss server. Ok, so that takes care of a large percentage of users... and we probably want to limit what does into this config. Next there are the more technical guys (and gals) which want to play around with the more advanced features of the server. We can expect that they will have the depth to read some docs first and perform some optional configuration. Then we are back in the same boat as above, a one command, jboss starts and they have positive feed back that it works. Lastly, you have the folks that want to play with the misc fluffy goodness which needs some serious code written and application specific hook up. We want to provide them with some example files and some simple howto docs on making those more complicated or configuration intensive components work. So, from my perspectifve, the configs which ship are purly educational. I would expect anyone who is going to be serving up a serious production application to tune the configuration as needed. Could be the default config that is tuned, could be the advanced, or could be hand rolled. I think we are kidding ourselves if we expect anything more. Which brings me back to the above more than one deploy directory, which is now quite easily added by adding another DeploymentScanner, or simply by adding another directory (soon to be url) list in the default one. What would that buy us? Given the different usage which I expect, I don't see that it buys anything... in fact it just complicates the default confgurations. It also means that if a user wants to change the config they have to edit a file, instead of usign the --config parameter on the command line. The above scheme looks more tailord to reducing file duplication, which I admit is something to keep in mind when working with a production setup with lots of server nodes... but that isn't what these configs are for. We should only be providing configs for the three types of users with a release... but make sure that the servers configuration systems will not keep it from functioning in a more diverse environment. Now, it could be that I just don't understand the full details of multipule deploy dirs... wouldn't be the first time I didn't understand something you were talking about =P --jason PS. One of my first pains with JBoss (~2.0) was trying to get it to run in the environment which fit my operational needs. This turned out to be no easy task, since the system was so tied to its release structure to run. I eventually gave up trying to force JBoss into my layout and wrote some ant magic to take my requirements and then generate a JBoss environment... which is rather backwards when you think about it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
