[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina EmbeddedCatalinaServiceSX.java EmbeddedCatalinaServiceSXMBean.java
User: starksm
Date: 01/11/27 23:48:09
Modified:catalina/src/main/org/jboss/web/catalina Tag: Branch_2_4
EmbeddedCatalinaServiceSX.java
EmbeddedCatalinaServiceSXMBean.java
Log:
Add support for setting the type of the primary connector. Currently
http or warp connectors are supported.
Revision ChangesPath
No revision
No revision
1.2.2.4 +74 -33
contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java
Index: EmbeddedCatalinaServiceSX.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java,v
retrieving revision 1.2.2.3
retrieving revision 1.2.2.4
diff -u -r1.2.2.3 -r1.2.2.4
--- EmbeddedCatalinaServiceSX.java2001/11/20 09:54:18 1.2.2.3
+++ EmbeddedCatalinaServiceSX.java2001/11/28 07:48:09 1.2.2.4
@@ -19,6 +19,7 @@
import java.util.HashMap;
import java.util.Iterator;
import javax.naming.InitialContext;
+import javax.naming.NamingException;
import javax.servlet.ServletContext;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
@@ -53,6 +54,9 @@
import org.apache.catalina.Valve;
import org.apache.catalina.authenticator.AuthenticatorBase;
import org.apache.catalina.connector.http.HttpConnector;
+import org.apache.catalina.connector.warp.WarpConnector;
+import org.apache.catalina.connector.warp.WarpHost;
+import org.apache.catalina.connector.warp.WarpEngine;
import org.apache.catalina.core.StandardContext;
import org.apache.catalina.loader.WebappClassLoader;
import org.apache.catalina.startup.Embedded;
@@ -65,7 +69,7 @@
@see org.apache.catalina.startup.Embedded
@author [EMAIL PROTECTED]
- @version $Revision: 1.2.2.3 $
+ @version $Revision: 1.2.2.4 $
*/
public class EmbeddedCatalinaServiceSX extends AbstractWebContainer implements
EmbeddedCatalinaServiceSXMBean
{
@@ -76,8 +80,6 @@
private Embedded catalina;
/** The catalina host container */
private Host catalinaHost;
- /** The name of the Engine implementation class */
- private String engineClassName;
/** The catalina debug level */
private int debugLevel;
/** The port the web server listens on */
@@ -95,6 +97,8 @@
private int maxProcessors = 20;
/** The JNDI name of the SecurityDomain implementation binding */
private String securityDomain;
+ /** The type of connector that Tomcat will run (HTTP or WARP) */
+ private String connectorType = "http";
/** Any extended configuration information specified via a config
element in the mbean definition.
*/
@@ -133,19 +137,21 @@
bindAddress = InetAddress.getByName(host);
}
- public String getEngineClass()
+ public String getConnectorType()
{
- return engineClassName;
+ return this.connectorType;
}
- public void setEngineClass(String className) throws ClassNotFoundException
+
+ public void setConnectorType(String type)
{
- this.engineClassName = className;
- if( engineClassName != null )
+ type = type.toLowerCase();
+ if( type.equals("http") == false && type.equals("warp") == false )
{
- // Check that the class is accessible
- ClassLoader loader = Thread.currentThread().getContextClassLoader();
- loader.loadClass(engineClassName);
+ String msg= "Invalid connector type: "+connectorType
++ " must be one of, http warp";
+ throw new IllegalArgumentException(msg);
}
+ this.connectorType = type;
}
public int getMinProcessors()
@@ -297,7 +303,7 @@
}
/** Create and configure a org.apache.catalina.startup.Embedded
-instance. Currently we do not use the server.xml file as we obtain all
+instance. We do not use the server.xml file as we obtain all
of the required customization from our mbean properties.
*/
private void initCatalina(ClassLoader parent) throws Exception
@@ -308,33 +314,39 @@
catalina.setDebug(debugLevel);
catalina.setUseNaming(false);
+ // Setup the primary engine and connector
+ if( connectorType.equals("http") )
+ initHttpConnector(parent, jbossLog, jbossRealm);
+ else if( connectorType.equals("warp") )
+ initWarpConnector(parent, jbossLog, jbossRealm);
+ else
+ throw new IllegalStateException("No valid connectorType");
+
+ // Apply any extended configuration
+ ConfigHandler handler = new ConfigHandler();
+ handler.applyHostConfig(extendedConfig, catalina, debugLevel > 0);
+ }
+
+ private void initHttpConnector(ClassLoader parent, Logg
[JBoss-dev] CVS update: contrib/catalina/src/build build.xml
User: starksm Date: 01/11/27 23:48:09 Modified:catalina/src/build Tag: Branch_2_4 build.xml Log: Add support for setting the type of the primary connector. Currently http or warp connectors are supported. Revision ChangesPath No revision No revision 1.4.2.3 +16 -1 contrib/catalina/src/build/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/catalina/src/build/build.xml,v retrieving revision 1.4.2.2 retrieving revision 1.4.2.3 diff -u -r1.4.2.2 -r1.4.2.3 --- build.xml 2001/11/12 19:29:44 1.4.2.2 +++ build.xml 2001/11/28 07:48:09 1.4.2.3 @@ -1,5 +1,5 @@ - + @@ -87,8 +100,10 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
David Jencks wrote: > So this requires an explicit undeploy of the old jar: it cannot work via an > autodeployer watching for changed timestamps, because you have to undeploy > the file first before you can change it. Correct, I was mainly thinking about the locking of the copied file, which is a pain right now (it doesn't get cleaned up). > You sure this is better than > copying? Copying would still be used, but at least the copy can have the same name, and always be removed on undeploy. With explicit deployment (described in previous reply to Marc) there would be no locking. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > I understand what you proposed what I don't understand is the above, see > below :) Ah, sorry, now I understand. We're talking about slightly different things. > Question: can you overwrite the jar if the vm holds a open connection to it > and thus a lock to it in windows (file in usage)? No. > If no which is my assumption for this discussion then you don't know when > ANT is going to replace that file from JBoss, or when the user wants to drag > and drop, it is an asynchronous operation that happens without your > knowledge (won't happen in this case) I was thinking about the same case as now, where there is one original copy (in /deploy) and one copy being actually used. The original copy would never be locked, but currently the copy being used is. *That* is what this solution would fix. You'd still need two copies. For the other case, you'd simply not use auto deployment. Introduce an Ant target that does "JBoss Deploy" and which does undeploy-copy-deploy directly to the server. Then you can work with the original file without problems. Personally I'd prefer this explicit way of doing deploy, since auto deployment seems a little funky right now (we get dual deployments quite often). > |6. At this point there are no open connections to the JAR, so it can be > |replaced with a new file or removed. > > no see above, you don't know *when* someone is going to replace the file so > you can't be "open most of the time". > > Do we agree here? We were talking about different files, that was the problem. > almost, some googoo on my glasses still (or is it yours?) As above, we talked about different things. We were both "right" :-) /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/local BaseLocalContainerInvoker.java
User: starksm
Date: 01/11/27 22:23:03
Modified:src/main/org/jboss/ejb/plugins/local Tag: Branch_2_4
BaseLocalContainerInvoker.java
Log:
As noted in SF Bug#482875, the WeakHashMap usage is not actually allowing
classes to be garbage collected due to Methods retaining strong references
to their Class. Since the container invokers have a well defined life-cycle
its better to explicitly remove the cached methods hashes in the invoker
stop method.
Revision ChangesPath
No revision
No revision
1.6.2.2 +28 -17
jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java
Index: BaseLocalContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/local/BaseLocalContainerInvoker.java,v
retrieving revision 1.6.2.1
retrieving revision 1.6.2.2
diff -u -r1.6.2.1 -r1.6.2.2
--- BaseLocalContainerInvoker.java2001/11/02 08:42:36 1.6.2.1
+++ BaseLocalContainerInvoker.java2001/11/28 06:23:03 1.6.2.2
@@ -41,35 +41,32 @@
import javax.transaction.Transaction;
import javax.transaction.TransactionManager;
-import org.jboss.ejb.MethodInvocation;
-import org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation;
-
+import org.jboss.deployment.DeploymentException;
+import org.jboss.ejb.CacheKey;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvokerContainer;
import org.jboss.ejb.Interceptor;
import org.jboss.ejb.LocalContainerInvoker;
+import org.jboss.ejb.MethodInvocation;
import org.jboss.ejb.plugins.jrmp.interfaces.EJBMetaDataImpl;
-import org.jboss.ejb.CacheKey;
-
-import org.jboss.tm.TransactionPropagationContextFactory;
-
-import org.jboss.security.SecurityAssociation;
-
+import org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation;
import org.jboss.logging.Logger;
-
-import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.SessionMetaData;
+import org.jboss.security.SecurityAssociation;
+import org.jboss.tm.TransactionPropagationContextFactory;
/**
*
*
- * @author Daniel OConnor ([EMAIL PROTECTED])
+ * @author Daniel OConnor ([EMAIL PROTECTED])
+ * @author [EMAIL PROTECTED]
*/
public class BaseLocalContainerInvoker implements LocalContainerInvoker
{
+ static Logger log = Logger.getLogger(BaseLocalContainerInvoker.class);
// Attributes
protected Container container;
protected String jndiName;
@@ -103,9 +100,10 @@
}
public void init()
- throws Exception
+ throws Exception
{
- if (((ContainerInvokerContainer)container).getLocalClass() == null)
+ ContainerInvokerContainer invokerContainer = (ContainerInvokerContainer)
container;
+ if (invokerContainer.getLocalClass() == null)
return;
Context ctx = new InitialContext();
@@ -117,19 +115,19 @@
transactionManager =
((TransactionManager)ctx.lookup("java:/TransactionManager"));
// Create method mappings for container invoker
- Method[] methods =
((ContainerInvokerContainer)container).getLocalClass().getMethods();
+ Method[] methods = invokerContainer.getLocalClass().getMethods();
beanMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
beanMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
- methods =
((ContainerInvokerContainer)container).getLocalHomeClass().getMethods();
+ methods = invokerContainer.getLocalHomeClass().getMethods();
homeMethodInvokerMap = new HashMap();
for (int i = 0; i < methods.length; i++)
homeMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(methods[i])), methods[i]);
}
public void start()
- throws Exception
+ throws Exception
{
// put in the static hashmap
}
@@ -137,6 +135,19 @@
public void stop()
{
// remove from the static hashmap
+ beanMethodInvokerMap.clear();
+ homeMethodInvokerMap.clear();
+ // Remove method mappings for container invoker
+ ContainerInvokerContainer invokerContainer = (ContainerInvokerContainer)
container;
+ Method[] methods = invokerContainer.getRemoteClass().getMethods();
+ for (int i = 0; i < methods.length; i++)
+ RemoteMethodInvocation.clearHash(methods[i]);
+
+ methods = invokerContainer.getHomeClass().getMethods();
+ for (int i = 0; i < methods.length; i++)
+ RemoteMethodInvocation.clearHash(methods[i]);
+
+ log.debug("Cl
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces RemoteMethodInvocation.java
User: starksm
Date: 01/11/27 22:23:03
Modified:src/main/org/jboss/ejb/plugins/jrmp/interfaces Tag:
Branch_2_4 RemoteMethodInvocation.java
Log:
As noted in SF Bug#482875, the WeakHashMap usage is not actually allowing
classes to be garbage collected due to Methods retaining strong references
to their Class. Since the container invokers have a well defined life-cycle
its better to explicitly remove the cached methods hashes in the invoker
stop method.
Revision ChangesPath
No revision
No revision
1.13.4.1 +33 -28
jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/RemoteMethodInvocation.java
Index: RemoteMethodInvocation.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/interfaces/RemoteMethodInvocation.java,v
retrieving revision 1.13
retrieving revision 1.13.4.1
diff -u -r1.13 -r1.13.4.1
--- RemoteMethodInvocation.java 2001/05/02 03:04:14 1.13
+++ RemoteMethodInvocation.java 2001/11/28 06:23:03 1.13.4.1
@@ -15,7 +15,6 @@
import java.lang.reflect.Method;
import java.util.Collections;
import java.util.Map;
-import java.util.WeakHashMap;
import java.util.HashMap;
import java.security.Principal;
@@ -30,9 +29,10 @@
*
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Richard
Monson-Haefel.
- * @author mailto:[EMAIL PROTECTED]";>Marc Fleury.
+ * @author mailto:[EMAIL PROTECTED]";>Marc Fleury.
* @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
- * @version $Revision: 1.13 $
+ * @author mailto:[EMAIL PROTECTED]";>Scott Stark/a>.
+ * @version $Revision: 1.13.4.1 $
*/
public final class RemoteMethodInvocation
implements java.io.Externalizable
@@ -41,30 +41,31 @@
/** Serial Version Identifier. */
private static final long serialVersionUID = 6021873560918744612L;
+ // Static
+ static Map hashMap = new HashMap();
// Attributes
+ /** The method invocation target id */
Object id;
-// String className;
+ /** The method hash caclulated by getInterfaceHashes */
long hash;
-
+ /** The method invocation arguments */
Object[] args;
private Object tpc; // Transaction propagation context.
+ /** The calling thread identity */
private Principal identity;
+ /** The calling thread identity credentials */
private Object credential;
-
+ /** The map of methods set by the JRMPContainerInvoker */
transient Map methodMap;
-
- // Static
- static Map hashMap = new WeakHashMap();
-
- /**
- * Calculate method hashes. This algo is taken from RMI.
- *
- * @param intf
- * @return
- */
+ /**
+ * Calculate method hashes. This algo is taken from RMI.
+ *
+ * @param intf
+ * @return
+ */
public static Map getInterfaceHashes(Class intf)
{
// Create method hashes
@@ -145,26 +146,31 @@
* we override the hashCode
*
* The hashes are cached in a static for efficiency
- * RO: WeakHashMap needed to support undeploy
*/
public static long calculateHash(Method method)
{
- Map methodHashes = (Map)hashMap.get(method.getDeclaringClass());
+ Class methodClass = method.getDeclaringClass();
+ Map methodHashes = (Map)hashMap.get(methodClass);
if (methodHashes == null)
{
- methodHashes = getInterfaceHashes(method.getDeclaringClass());
-
- // Copy and add
- WeakHashMap newHashMap = new WeakHashMap();
- newHashMap.putAll(hashMap);
- newHashMap.put(method.getDeclaringClass(), methodHashes);
- hashMap = newHashMap;
+ methodHashes = getInterfaceHashes(methodClass);
+ hashMap.put(methodClass, methodHashes);
}
return ((Long)methodHashes.get(method)).longValue();
}
-
+
+ /** Remove the method declaring class method hash map. This is
+called by the JRMPContainerInvoker in stop to release the referenced
+classes.
+*/
+ public static void clearHash(Method method)
+ {
+ Class methodClass = method.getDeclaringClass();
+ hashMap.remove(methodClass);
+ }
+
// Constructors --
public RemoteMethodInvocation()
{
@@ -181,9 +187,8 @@
this.id = id;
this.args = args;
this.hash = calculateHash(m);
-// this.className = m.getDeclaringClass().getName();
}
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee JNDIMBean.java EJB.java EjbModule.java J2EEApplication.java J2EEResource.java J2EEServer.java JNDI.java
User: schaefera
Date: 01/11/27 22:33:38
Modified:src/main/org/jboss/management/j2ee EJB.java EjbModule.java
J2EEApplication.java J2EEResource.java
J2EEServer.java JNDI.java
Added: src/main/org/jboss/management/j2ee JNDIMBean.java
Log:
Added the first J2EE Resource (JNDI) to the JSR-77 implementation. Also
the first component implementing the StateManageable interface (not
100% implemented yet).
Revision ChangesPath
1.4 +2 -4 jboss/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- EJB.java 2001/11/28 01:15:08 1.3
+++ EJB.java 2001/11/28 06:33:37 1.4
@@ -19,7 +19,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* Revisions:
*
@@ -98,9 +98,7 @@
super( pType, pName, pEJBModule );
}
- // -
- // Properties (Getters/Setters)
- // -
+ // java.lang.Object overrides --
public String toString() {
return "EJB { " + super.toString() + " } []";
1.7 +1 -7 jboss/src/main/org/jboss/management/j2ee/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EjbModule.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- EjbModule.java2001/11/28 01:15:08 1.6
+++ EjbModule.java2001/11/28 06:33:37 1.7
@@ -29,7 +29,7 @@
* {@link javax.management.j2ee.EjbModule EjbModule}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*
* Revisions:
*
@@ -132,12 +132,6 @@
InvalidParentException
{
super( "EJBModule", pName, pApplication, pDeploymentDescriptor );
-/*
- if( pEJBs == null || pEJBs.length == 0 ) {
- throw new InvalidParameterException( "EJB list may not be null or empty" );
- }
- mEJBs = new ArrayList( Arrays.asList( pEJBs ) );
-*/
}
// Public
1.6 +1 -2 jboss/src/main/org/jboss/management/j2ee/J2EEApplication.java
Index: J2EEApplication.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/J2EEApplication.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- J2EEApplication.java 2001/11/28 01:15:08 1.5
+++ J2EEApplication.java 2001/11/28 06:33:37 1.6
@@ -24,7 +24,7 @@
* {@link javax.management.j2ee.J2EEApplication J2EEApplication}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*
* Revisions:
*
@@ -38,7 +38,6 @@
extends J2EEDeployedObject
implements J2EEApplicationMBean
{
-
// Constants -
// Attributes
1.4 +19 -12jboss/src/main/org/jboss/management/j2ee/J2EEResource.java
Index: J2EEResource.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/J2EEResource.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- J2EEResource.java 2001/11/27 06:15:26 1.3
+++ J2EEResource.java 2001/11/28 06:33:37 1.4
@@ -14,7 +14,7 @@
* {@link javax.management.j2ee.J2EEResource J2EEResource}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*
* Revisions:
*
@@ -27,14 +27,14 @@
extends J2EEManagedObject
implements javax.management.j2ee.J2EEResource
{
- // -
- // Members
- // -
-
- // -
- // Constructors
- // -
-
+ // Constants -
+
+ // Attribute
[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming NamingService.java
User: schaefera
Date: 01/11/27 22:33:38
Modified:src/main/org/jboss/naming NamingService.java
Log:
Added the first J2EE Resource (JNDI) to the JSR-77 implementation. Also
the first component implementing the StateManageable interface (not
100% implemented yet).
Revision ChangesPath
1.21 +8 -1 jboss/src/main/org/jboss/naming/NamingService.java
Index: NamingService.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/NamingService.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- NamingService.java2001/11/27 04:49:28 1.20
+++ NamingService.java2001/11/28 06:33:38 1.21
@@ -22,13 +22,14 @@
import org.jnp.server.Main;
+import org.jboss.management.j2ee.JNDI;
import org.jboss.system.ServiceMBeanSupport;
/** A JBoss service that starts the jnp JNDI server.
*
* @author mailto:[EMAIL PROTECTED]";>Rickard Öberg
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
- * @version $Revision: 1.20 $
+ * @version $Revision: 1.21 $
*
* Revisions:
* 20010622 scott.stark: Report IntialContext env for problem tracing
@@ -172,10 +173,16 @@
Context ctx = (Context)iniCtx.lookup("java:");
ctx.rebind("comp", envRef);
log.info("Naming started on port "+naming.getPort());
+
+ // Finally create the JSR-77 management representation
+ JNDI.create( getServer(), "LocalJNDI" );
}
public void stopService()
{
+ // First destroy the JSR-77 management representation
+ JNDI.destroy( getServer(), "LocalJNDI" );
+
naming.stop();
log.info("JNP server stopped");
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/sun/jsr77/lib jsr77.jar
User: schaefera Date: 01/11/27 22:33:38 Modified:sun/jsr77/lib jsr77.jar Log: Added the first J2EE Resource (JNDI) to the JSR-77 implementation. Also the first component implementing the StateManageable interface (not 100% implemented yet). Revision ChangesPath 1.6 +4 -5 thirdparty/sun/jsr77/lib/jsr77.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/tomcat/src/build build.xml
User: starksm
Date: 01/11/27 22:30:02
Modified:tomcat/src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Update to the jarkarta-tomcat-3.2.4 release
Revision ChangesPath
No revision
No revision
1.15.2.9 +19 -25contrib/tomcat/src/build/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/tomcat/src/build/build.xml,v
retrieving revision 1.15.2.8
retrieving revision 1.15.2.9
diff -u -r1.15.2.8 -r1.15.2.9
--- build.xml 2001/11/20 09:49:00 1.15.2.8
+++ build.xml 2001/11/28 06:30:02 1.15.2.9
@@ -1,5 +1,5 @@
-
+
-
+
+
@@ -22,10 +23,10 @@
-
+
-
+
@@ -35,25 +36,6 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -66,14 +48,24 @@
-
-
+
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
@@ -104,8 +96,10 @@
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: starksm
Date: 01/11/27 22:26:16
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.77.2.9 +47 -16jboss/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/src/build/Attic/build.xml,v
retrieving revision 1.77.2.8
retrieving revision 1.77.2.9
diff -u -r1.77.2.8 -r1.77.2.9
--- build.xml 2001/11/09 10:46:02 1.77.2.8
+++ build.xml 2001/11/28 06:26:16 1.77.2.9
@@ -5,19 +5,11 @@
-
-
-
-
-
-
-
-
-
-
+
+
@@ -57,7 +49,7 @@
-
+
@@ -94,6 +86,32 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Specification-Title: JBoss-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: JBoss-${version} CVSTag=${version-tag}
+Implementation-Version: ${version}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
@@ -192,18 +210,24 @@
+
+
+
+
+
+
@@ -216,9 +240,12 @@
+
+
+
@@ -228,7 +255,8 @@
-
+
+
@@ -238,9 +266,12 @@
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: starksm Date: 01/11/27 22:26:16 Modified:.Tag: Branch_2_4 build.xml Log: Add support for package version manifest headers Revision ChangesPath No revision No revision 1.33.2.2 +17 -10jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.33.2.1 retrieving revision 1.33.2.2 diff -u -r1.33.2.1 -r1.33.2.2 --- build.xml 2001/10/01 17:15:53 1.33.2.1 +++ build.xml 2001/11/28 06:26:16 1.33.2.2 @@ -15,9 +15,9 @@ release-tag="JBoss_2_4_2" To build the latest 2.4 branch chode use: release-tag="Branch_2_4" -b. tomcat323: set to the absolute path of the jakarta-tomcat-3.2.3 distribution +b. tomcat3x: set to the absolute path of the jakarta-tomcat-3.2.3 distribution This is required to build the contrib/tomcat bundle -c. tomcat40: set to the absolute path of the jakarta-tomcat-4.0 distribution +c. tomcat4x: set to the absolute path of the jakarta-tomcat-4.0 distribution This is required to build the contrib/catalina bundle 3. Execute the dist target by running Ant1.3 in the directory created @@ -27,18 +27,25 @@ directory with the JBoss/Catalina bundle. --> - + + - + - + - + + + + + + + @@ -129,7 +136,7 @@ - + @@ -142,10 +149,10 @@ - + - + @@ -159,5 +166,5 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Info.java InfoMBean.java
User: starksm
Date: 01/11/27 22:25:08
Modified:src/main/org/jboss/util Tag: Branch_2_4 Info.java
InfoMBean.java
Log:
Add support for displaying java.lang.Package information
Revision ChangesPath
No revision
No revision
1.5.4.3 +22 -2 jboss/src/main/org/jboss/util/Info.java
Index: Info.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Info.java,v
retrieving revision 1.5.4.2
retrieving revision 1.5.4.3
diff -u -r1.5.4.2 -r1.5.4.3
--- Info.java 2001/11/27 04:03:08 1.5.4.2
+++ Info.java 2001/11/28 06:25:08 1.5.4.3
@@ -20,7 +20,7 @@
*
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.5.4.2 $
+ * @version $Revision: 1.5.4.3 $
*/
public class Info
implements InfoMBean, MBeanRegistration
@@ -188,7 +188,27 @@
getThreadGroupInfo(root) ;
return rc;
}
-
+
+ /** Display the java.lang.Package info for the pkgName */
+ public String displayPackageInfo(String pkgName)
+ {
+ Package pkg = Package.getPackage(pkgName);
+ if( pkg == null )
+ return "Package:"+pkgName+" Not Found!";
+
+ StringBuffer info = new StringBuffer("Package: "+pkgName+"");
+ info.append("\n");
+ info.append("SpecificationTitle: "+pkg.getSpecificationTitle());
+ info.append("\nSpecificationVersion: "+pkg.getSpecificationVersion());
+ info.append("\nSpecificationVendor: "+pkg.getSpecificationVendor());
+ info.append("\nImplementationTitle: "+pkg.getImplementationTitle());
+ info.append("\nImplementationVersion: "+pkg.getImplementationVersion());
+ info.append("\nImplementationVendor: "+pkg.getImplementationVendor());
+ info.append("\nisSealed: "+pkg.isSealed());
+ info.append("\n");
+ return info.toString();
+ }
+
/**
* Enable or disable tracing method calls at the Runtime level.
*/
1.2.6.2 +3 -1 jboss/src/main/org/jboss/util/InfoMBean.java
Index: InfoMBean.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/InfoMBean.java,v
retrieving revision 1.2.6.1
retrieving revision 1.2.6.2
diff -u -r1.2.6.1 -r1.2.6.2
--- InfoMBean.java2001/11/27 04:03:08 1.2.6.1
+++ InfoMBean.java2001/11/28 06:25:08 1.2.6.2
@@ -11,7 +11,7 @@
*
* @see
* @author Rickard Öberg ([EMAIL PROTECTED])
- * @version $Revision: 1.2.6.1 $
+ * @version $Revision: 1.2.6.2 $
*/
public interface InfoMBean
{
@@ -20,6 +20,8 @@
String listSystemInfo();
String listThreadDump();
String runGarbageCollector();
+ /** Display the java.lang.Package info for the pkgName */
+ String displayPackageInfo(String pkgName);
void traceMethodCalls(boolean flag);
void traceInstructions(boolean flag);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss-web.dtd jboss_2_4.dtd
User: starksm Date: 01/11/27 22:25:28 Modified:src/resources/org/jboss/metadata Tag: Branch_2_4 jboss-web.dtd jboss_2_4.dtd Log: Update the dtd comments Revision ChangesPath No revision No revision 1.3.4.2 +1 -1 jboss/src/resources/org/jboss/metadata/jboss-web.dtd Index: jboss-web.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss-web.dtd,v retrieving revision 1.3.4.1 retrieving revision 1.3.4.2 diff -u -r1.3.4.1 -r1.3.4.2 --- jboss-web.dtd 2001/11/20 09:42:58 1.3.4.1 +++ jboss-web.dtd 2001/11/28 06:25:27 1.3.4.2 @@ -13,7 +13,7 @@ 1.1.2.9 +69 -86jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd Index: jboss_2_4.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd,v retrieving revision 1.1.2.8 retrieving revision 1.1.2.9 diff -u -r1.1.2.8 -r1.1.2.9 --- jboss_2_4.dtd 2001/11/09 10:43:45 1.1.2.8 +++ jboss_2_4.dtd 2001/11/28 06:25:28 1.1.2.9 @@ -7,8 +7,8 @@ "-//JBoss//DTD JBOSS 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd";> -$Id: jboss_2_4.dtd,v 1.1.2.8 2001/11/09 10:43:45 starksm Exp $ -$Revision: 1.1.2.8 $ +$Id: jboss_2_4.dtd,v 1.1.2.9 2001/11/28 06:25:28 starksm Exp $ +$Revision: 1.1.2.9 $ Overview of the architecture of jboss.xml @@ -102,7 +102,7 @@ - +--> - + - - - - - +--> - +--> - - + - +--> + - - - + - - +--> + + + @@ -788,13 +774,10 @@ - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server JRMPContainerInvoker.java
User: starksm
Date: 01/11/27 22:23:03
Modified:src/main/org/jboss/ejb/plugins/jrmp/server Tag: Branch_2_4
JRMPContainerInvoker.java
Log:
As noted in SF Bug#482875, the WeakHashMap usage is not actually allowing
classes to be garbage collected due to Methods retaining strong references
to their Class. Since the container invokers have a well defined life-cycle
its better to explicitly remove the cached methods hashes in the invoker
stop method.
Revision ChangesPath
No revision
No revision
1.37.4.6 +18 -7
jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java,v
retrieving revision 1.37.4.5
retrieving revision 1.37.4.6
diff -u -r1.37.4.5 -r1.37.4.6
--- JRMPContainerInvoker.java 2001/11/20 09:42:52 1.37.4.5
+++ JRMPContainerInvoker.java 2001/11/28 06:23:03 1.37.4.6
@@ -45,9 +45,9 @@
import org.jboss.ejb.ContainerInvokerContainer;
import org.jboss.ejb.Interceptor;
import org.jboss.ejb.ContainerInvoker;
-import org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation;
import org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy;
import org.jboss.ejb.plugins.jrmp.interfaces.HomeHandleImpl;
+import org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvocation;
import org.jboss.ejb.plugins.jrmp.interfaces.StatelessSessionProxy;
import org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionProxy;
import org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy;
@@ -77,7 +77,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Juha Lindfors
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
- * @version $Revision: 1.37.4.5 $
+ * @version $Revision: 1.37.4.6 $
*/
public class JRMPContainerInvoker
extends RemoteServer
@@ -151,7 +151,7 @@
}
public void init()
- throws Exception
+ throws Exception
{
Context ctx = new InitialContext();
@@ -178,7 +178,6 @@
try
{
-
// Get the getEJBObjectMethod
Method getEJBObjectMethod =
Class.forName("javax.ejb.Handle").getMethod("getEJBObject", new Class[0]);
@@ -190,9 +189,7 @@
log.error("getEJBObject", e);
}
-
// Create metadata
-
/**
Constructor signature is
@@ -310,12 +307,26 @@
UnicastRemoteObject.unexportObject(this, true);
- } catch (Exception e)
+ }
+ catch (Exception e)
{
// ignore.
}
GenericProxy.removeLocal(container.getBeanMetaData().getJndiName());
+
+ beanMethodInvokerMap.clear();
+ homeMethodInvokerMap.clear();
+ // Remove method mappings for container invoker
+ Method[] methods = invokerContainer.getRemoteClass().getMethods();
+ for (int i = 0; i < methods.length; i++)
+ RemoteMethodInvocation.clearHash(methods[i]);
+
+ methods = invokerContainer.getHomeClass().getMethods();
+ for (int i = 0; i < methods.length; i++)
+ RemoteMethodInvocation.clearHash(methods[i]);
+
+ log.debug("Cleared method maps");
}
public void destroy()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILClientIL.java UILClientILService.java
User: starksm
Date: 01/11/27 22:15:31
Modified:src/main/org/jboss/mq/il/uil Tag: Branch_2_4
UILClientIL.java UILClientILService.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +53 -31jbossmq/src/main/org/jboss/mq/il/uil/UILClientIL.java
Index: UILClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILClientIL.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- UILClientIL.java 2001/08/23 03:57:10 1.2.2.1
+++ UILClientIL.java 2001/11/28 06:15:31 1.2.2.2
@@ -15,9 +15,10 @@
import javax.jms.Destination;
import javax.jms.JMSException;
+
+import org.jboss.logging.Logger;
import org.jboss.mq.Connection;
import org.jboss.mq.ReceiveRequest;
-
import org.jboss.mq.SpyDestination;
import org.jboss.mq.il.ClientIL;
import org.jboss.mq.il.uil.multiplexor.SocketMultiplexor;
@@ -28,82 +29,103 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class UILClientIL implements ClientIL, java.io.Serializable {
+public class UILClientIL implements ClientIL, java.io.Serializable
+{
+ static Logger log = Logger.getLogger( UILClientIL.class );
transient SocketMultiplexor mSocket;
private transient ObjectInputStream in;
private transient ObjectOutputStream out;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
UILClientIL.class );
+
final static int m_close = 2;
final static int m_deleteTemporaryDestination = 1;
final static int m_receive = 3;
-
-
+
+
public void close()
- throws Exception {
+ throws Exception
+ {
}
-
+
public synchronized void deleteTemporaryDestination( SpyDestination dest )
- throws Exception {
+ throws Exception
+ {
checkSocket();
out.writeByte( m_deleteTemporaryDestination );
out.writeObject( dest );
waitAnswer();
}
-
+
public synchronized void receive( ReceiveRequest messages[] )
- throws Exception {
- cat.debug( "Checking socket" );
+ throws Exception
+ {
+ boolean trace = log.isTraceEnabled();
+ if( trace )
+ log.trace( "Checking socket" );
checkSocket();
- cat.debug( "Writing request" );
+ if( trace )
+ log.trace( "Writing request" );
out.writeByte( m_receive );
out.writeInt( messages.length );
- for ( int i = 0; i < messages.length; ++i ) {
+ for ( int i = 0; i < messages.length; ++i )
+ {
messages[i].writeExternal( out );
}
- cat.debug( "Waiting for awnser" );
+ if( trace )
+ log.trace( "Waiting for awnser" );
waitAnswer();
- cat.debug( "Done" );
+ if( trace )
+ log.trace( "Done" );
}
-
+
protected void checkSocket()
- throws Exception {
- if ( out == null ) {
+ throws Exception
+ {
+ if ( out == null )
+ {
createConnection();
}
}
-
+
protected void createConnection()
- throws RemoteException {
- try {
+ throws RemoteException
+ {
+ try
+ {
in = new ObjectInputStream( new BufferedInputStream(
mSocket.getInputStream( 2 ) ) );
out = new ObjectOutputStream( new BufferedOutputStream(
mSocket.getOutputStream( 2 ) ) );
out.flush();
- } catch ( Exception e ) {
+ }
+ catch ( Exception e )
+ {
throw new RemoteException( "Cannot connect to the
ConnectionReceiver/Server" );
}
}
-
+
protected void waitAnswer()
- throws Exception {
+ throws Exception
+ {
Exception throwException = null;
- try {
+ try
+ {
out.reset();
out.flush();
int val = in.readByte();
- switch ( val ) {
+ switch ( val )
+ {
case 1:
Exception e = ( Exception )in.readObject();
throwException = new RemoteException( "", e );
break;
}
- } catch ( IOException e ) {
+ } catch ( IOException e )
+ {
throw new RemoteException( "Cannot contact the remote object", e );
}
-
- if ( throwException != null ) {
+
+ if ( thro
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins TxInterceptorCMT.java
User: starksm
Date: 01/11/27 22:19:29
Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4
TxInterceptorCMT.java
Log:
Use the trace log level to provide detailed progress
Revision ChangesPath
No revision
No revision
1.10.4.2 +665 -616 jboss/src/main/org/jboss/ejb/plugins/TxInterceptorCMT.java
Index: TxInterceptorCMT.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/TxInterceptorCMT.java,v
retrieving revision 1.10.4.1
retrieving revision 1.10.4.2
diff -u -r1.10.4.1 -r1.10.4.2
--- TxInterceptorCMT.java 2001/07/08 21:19:28 1.10.4.1
+++ TxInterceptorCMT.java 2001/11/28 06:19:29 1.10.4.2
@@ -1,616 +1,665 @@
-/*
-* JBoss, the OpenSource EJB server
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
-package org.jboss.ejb.plugins;
-
-import java.lang.reflect.Method;
-import java.rmi.NoSuchObjectException;
-import java.rmi.RemoteException;
-import java.rmi.ServerException;
-import java.util.*;
-
-import javax.transaction.Status;
-import javax.transaction.Transaction;
-import javax.transaction.TransactionManager;
-import javax.transaction.RollbackException;
-import javax.transaction.TransactionRequiredException;
-import javax.transaction.TransactionRolledbackException;
-import javax.transaction.SystemException;
-
-import javax.ejb.EJBException;
-import javax.ejb.NoSuchEntityException;
-
-import org.jboss.ejb.Container;
-import org.jboss.ejb.EnterpriseContext;
-import org.jboss.ejb.MethodInvocation;
-import org.jboss.logging.Logger;
-
-import org.jboss.metadata.MetaData;
-import org.jboss.metadata.BeanMetaData;
-import org.jboss.metadata.MethodMetaData;
-
-/**
-*
-*
-* @see
-* @author Rickard Öberg ([EMAIL PROTECTED])
-* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
-* @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
-* @author mailto:[EMAIL PROTECTED]";>Anatoly Akkerman
-* @version $Revision: 1.10.4.1 $
-*/
-public class TxInterceptorCMT
-extends AbstractInterceptor
-{
-
-// Attributes
-private TransactionManager tm;
-private HashMap methodTx = new HashMap();
-
-protected Container container;
-
-// Static
-
-// Constructors --
-
-// Public
-public void setContainer(Container container)
-{
-this.container = container;
-}
-
-public Container getContainer()
-{
-return container;
-}
-
-// Interceptor implementation --
-public void init()
-throws Exception
-{
-// Store TM reference locally
-tm = (TransactionManager) getContainer().getTransactionManager();
-
-// Find out method->tx-type mappings from meta-info
-// EnterpriseBean eb = getContainer.getMetaData();
-// eb.getBeanContext()
-
-}
-
-public Object invokeHome(MethodInvocation mi)
-throws Exception
-{
-return runWithTransactions(false, mi);
-}
-
-/**
-* This method does invocation interpositioning of tx management
-*
-* @param id
-* @param m
-* @param args
-* @return
-* @exception Exception
-*/
-public Object invoke(MethodInvocation mi) throws Exception {
-return runWithTransactions(true, mi);
-}
-
-private void printMethod(Method m, byte type) {
-String name;
-switch(type) {
-case MetaData.TX_MANDATORY:
-name = "TX_MANDATORY";
-break;
-case MetaData.TX_NEVER:
-name = "TX_NEVER";
-break;
-case MetaData.TX_NOT_SUPPORTED:
-name = "TX_NOT_SUPPORTED";
-break;
-case MetaData.TX_REQUIRED:
-name = "TX_REQUIRED";
-break;
-case MetaData.TX_REQUIRES_NEW:
-name = "TX_REQUIRES_NEW";
-break;
-case MetaData.TX_SUPPORTS:
-name = "TX_SUPPORTS";
-break;
-default:
-name = "TX_UNKNOWN";
-}
-//DEBUGLogger.debug(name+" for "+m.getName());
-}
-
-private Object invokeNext(boolean remoteInvocation, MethodInvocation mi) throws
Exception {
- try
- {
- if (remoteInvocation) {
- return getNext().invoke(mi);
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
User: starksm
Date: 01/11/27 22:18:11
Modified:src/main/org/jboss Tag: Branch_2_4 Main.java
Log:
Use a trival subclass of MLet that returns an empty URL[] from getURLs to
force the use of the rmi codebase as the annotated codebase.
Remove the embedded version string in favor of the Package.getSpecificationTitle
value
Revision ChangesPath
No revision
No revision
1.35.2.15 +30 -5 jboss/src/main/org/jboss/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
retrieving revision 1.35.2.14
retrieving revision 1.35.2.15
diff -u -r1.35.2.14 -r1.35.2.15
--- Main.java 2001/11/11 08:15:58 1.35.2.14
+++ Main.java 2001/11/28 06:18:11 1.35.2.15
@@ -27,13 +27,12 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.35.2.14 $
+ * @version $Revision: 1.35.2.15 $
*/
public class Main
{
// Constants -
- String versionIdentifier = "2.4.4";
// Attributes
// Static
@@ -167,7 +166,8 @@
}
// Create MLet
- MLet mlet = new MLet(urls);
+ MLet mlet = new NullURLsMLet(urls);
+
server.registerMBean(mlet, new ObjectName(server.getDefaultDomain(),
"service", "MLet"));
// Set MLet as classloader for this app
@@ -230,11 +230,36 @@
}
// Done
+ Package mainPkg = Package.getPackage("org.jboss");
long stopTime = System.currentTimeMillis();
long lapsedTime = stopTime - startTime;
long minutes = lapsedTime / 6;
long seconds = (lapsedTime - 6 * minutes) / 1000;
- long milliseconds = lapsedTime - 6 * minutes - 1000 * seconds;
- System.out.println("JBoss "+versionIdentifier+" Started in
"+minutes+"m:"+seconds+"s."+milliseconds);
+ long milliseconds = lapsedTime - 6 * minutes - 1000 * seconds;
+ String version = mainPkg.getSpecificationTitle();
+ System.out.println(version+" Started in
"+minutes+"m:"+seconds+"s."+milliseconds);
+ }
+
+ /**
+*/
+ static class NullURLsMLet extends MLet
+ {
+ URL[] empty = {};
+ public NullURLsMLet()
+ {
+ }
+ public NullURLsMLet(URL[] urls)
+ {
+ super(urls);
+ }
+
+ public URL[] getURLs()
+ {
+ return empty;
+ }
+ public URL[] getLocalURLs()
+ {
+ return super.getURLs();
+ }
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server BasicQueue.java ClientConsumer.java JMSDestination.java JMSServer.java
User: starksm
Date: 01/11/27 22:15:32
Modified:src/main/org/jboss/mq/server Tag: Branch_2_4 BasicQueue.java
ClientConsumer.java JMSDestination.java
JMSServer.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.4.2.3 +207 -128 jbossmq/src/main/org/jboss/mq/server/BasicQueue.java
Index: BasicQueue.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java,v
retrieving revision 1.4.2.2
retrieving revision 1.4.2.3
diff -u -r1.4.2.2 -r1.4.2.3
--- BasicQueue.java 2001/10/22 20:38:51 1.4.2.2
+++ BasicQueue.java 2001/11/28 06:15:32 1.4.2.3
@@ -18,6 +18,7 @@
import javax.jms.Destination;
import javax.jms.JMSException;
+import org.jboss.logging.Logger;
import org.jboss.mq.*;
import org.jboss.mq.pm.PersistenceManager;
import org.jboss.mq.selectors.Selector;
@@ -30,10 +31,12 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4.2.2 $
+ * @version$Revision: 1.4.2.3 $
*/
//abstract public class BasicQueue implements Runnable {
-public class BasicQueue {
+public class BasicQueue
+{
+ static Logger log = Logger.getLogger( BasicQueue.class );
//List of messages waiting to be dispatched
SortedSetmessages = new TreeSet();
//The JMSServer object
@@ -43,123 +46,157 @@
//List of messages that should be acked or else returned to thier
//owning exclusive queues.
HashMap unacknowledgedMessages = new HashMap();
-
+
HashMap removedSubscribers = new HashMap();
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
BasicQueue.class );
-
+
// Constructor ---
public BasicQueue( JMSServer server )
- throws JMSException {
+ throws JMSException
+ {
this.server = server;
}
-
- public void clientConsumerStopped( ClientConsumer clientConsumer ) {
+
+ public void clientConsumerStopped( ClientConsumer clientConsumer )
+ {
//remove all waiting subs for this clientConsumer and send to its blocked
list.
- synchronized ( receivers ) {
- for ( Iterator it = receivers.iterator(); it.hasNext(); ) {
+ synchronized ( receivers )
+ {
+ for ( Iterator it = receivers.iterator(); it.hasNext(); )
+ {
Subscription sub = ( Subscription )it.next();
-if ( sub.clientConsumer.equals( clientConsumer ) ) {
+if ( sub.clientConsumer.equals( clientConsumer ) )
+{
clientConsumer.addBlockedSubscription( sub );
it.remove();
}
}
}
}
-
+
//Used to put a message that was added previously to the queue, back in the queue
- public void restoreMessage( SpyMessage mes ) {
+ public void restoreMessage( SpyMessage mes )
+ {
internalAddMessage( mes );
}
-
-
+
+
public SpyMessage[] browse( String selector )
- throws JMSException {
-
- if ( selector == null ) {
+ throws JMSException
+ {
+
+ if ( selector == null )
+ {
SpyMessage list[];
- synchronized ( messages ) {
+ synchronized ( messages )
+ {
list = new SpyMessage[messages.size()];
list = ( SpyMessage[] )messages.toArray( list );
}
return list;
- } else {
+ }
+ else
+ {
Selector s = new Selector( selector );
LinkedList selection = new LinkedList();
-
- synchronized ( messages ) {
+
+ synchronized ( messages )
+ {
Iterator i = messages.iterator();
-while ( i.hasNext() ) {
+while ( i.hasNext() )
+{
SpyMessage m = ( SpyMessage )i.next();
- if ( s.test( m ) ) {
+ if ( s.test( m ) )
+ {
selection.add( m );
}
}
}
-
+
SpyMessage list[];
list = new SpyMessage[selection.size()];
list = ( SpyMessage[] )selection.toArray( list );
return list;
}
}
-
- public void addReceiver( Subscription sub ) {
- synchronized ( messages ) {
- if ( messages.size() != 0 ) {
-for ( Iterator
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors Selector.java
User: starksm
Date: 01/11/27 22:15:32
Modified:src/main/org/jboss/mq/selectors Tag: Branch_2_4
Selector.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.3.2.2 +84 -49jbossmq/src/main/org/jboss/mq/selectors/Selector.java
Index: Selector.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Selector.java,v
retrieving revision 1.3.2.1
retrieving revision 1.3.2.2
diff -u -r1.3.2.1 -r1.3.2.2
--- Selector.java 2001/08/23 03:57:12 1.3.2.1
+++ Selector.java 2001/11/28 06:15:32 1.3.2.2
@@ -12,6 +12,7 @@
import javax.jms.JMSException;
+import org.jboss.logging.Logger;
import org.jboss.mq.SpyMessage;
/**
@@ -20,111 +21,145 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Juha Lindfors ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3.2.1 $
+ * @version$Revision: 1.3.2.2 $
*/
-public class Selector {
+public class Selector
+{
+ static Logger log = Logger.getLogger( Selector.class );
+
public HashMap identifiers;
// HashMap of Identifiers
public Objectresult;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
Selector.class );
-
+
public Selector( String sel )
- throws JMSException {
+ throws JMSException
+ {
parser bob = new parser();
identifiers = new HashMap();
-
- try {
+
+ try
+ {
result = bob.parse( sel, identifiers );
- } catch ( Exception e ) {
+ } catch ( Exception e )
+ {
InvalidSelectorException exception = new InvalidSelectorException( "The
selector is invalid." );
exception.setLinkedException( e );
throw exception;
}
-
+
//Log.notice(result.toString());
}
-
+
public boolean test( SpyMessage mes )
- throws JMSException {
-
- try {
-
+ throws JMSException
+ {
+
+ try
+ {
+
//Set the identifiers values
Iterator i = identifiers.values().iterator();
-
- while ( i.hasNext() ) {
+
+ while ( i.hasNext() )
+ {
Identifier id = ( Identifier )i.next();
-
+
Object find = mes.getObjectProperty( id.name );
-
-if ( find == null ) {
+
+if ( find == null )
+{
find = getHeaderFieldReferences( mes, id.name );
}
-
-if ( find == null ) {
- cat.debug( "Warning : missing property " + id.name );
+
+if ( find == null )
+{
+ log.debug( "Warning : missing property " + id.name );
id.value = null;
-} else {
+} else
+{
Class type = find.getClass();
if ( type.equals( Boolean.class ) || type.equals( String.class )
- || type.equals( Double.class ) || type.equals( Float.class )
- || type.equals( Integer.class ) || type.equals( Long.class )
- || type.equals( Short.class ) || type.equals( Byte.class ) ) {
+ || type.equals( Double.class ) || type.equals( Float.class )
+ || type.equals( Integer.class ) || type.equals( Long.class )
+ || type.equals( Short.class ) || type.equals( Byte.class ) )
+ {
id.value = find;
- } else {
+ }
+ else
+ {
throw new Exception( "Bad property type !" );
}
//Log.notice("SEL:"+id.name+" =>"+id.value);
}
}
-
+
//Compute the result of this operator
Object res;
-
- if ( result.getClass().equals( Identifier.class ) ) {
+
+ if ( result.getClass().equals( Identifier.class ) )
+ {
res = ( ( Identifier )result ).value;
- } else if ( result.getClass().equals( Operator.class ) ) {
+ } else if ( result.getClass().equals( Operator.class ) )
+ {
res = ( ( Operator )result ).apply();
- } else {
+ } else
+ {
res = result;
}
-
- if ( res == null ) {
+
+ if ( res == null )
+ {
return false;
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILClientIL.java OILClientILService.java OILServerILService.java
User: starksm
Date: 01/11/27 22:15:31
Modified:src/main/org/jboss/mq/il/oil Tag: Branch_2_4
OILClientIL.java OILClientILService.java
OILServerILService.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +56 -34jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java
Index: OILClientIL.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILClientIL.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- OILClientIL.java 2001/08/23 03:57:10 1.2.2.1
+++ OILClientIL.java 2001/11/28 06:15:31 1.2.2.2
@@ -17,9 +17,10 @@
import javax.jms.Destination;
import javax.jms.JMSException;
+
+import org.jboss.logging.Logger;
import org.jboss.mq.Connection;
import org.jboss.mq.ReceiveRequest;
-
import org.jboss.mq.SpyDestination;
import org.jboss.mq.il.ClientIL;
@@ -29,94 +30,115 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class OILClientIL implements ClientIL, java.io.Serializable {
-
+public class OILClientIL implements ClientIL, java.io.Serializable
+{
+ private static Logger log = Logger.getLogger( OILClientIL.class );
private InetAddress addr;
private transient ObjectInputStream in;
private transient ObjectOutputStream out;
private int port;
private transient Socket socket;
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
OILClientIL.class );
final static int m_close = 2;
final static int m_deleteTemporaryDestination = 1;
final static int m_receive = 3;
-
- OILClientIL( InetAddress addr, int port ) {
+
+ OILClientIL( InetAddress addr, int port )
+ {
this.addr = addr;
this.port = port;
}
-
+
public void close()
- throws Exception {
+ throws Exception
+ {
checkSocket();
out.writeByte( m_close );
waitAnswer();
}
-
+
public synchronized void deleteTemporaryDestination( SpyDestination dest )
- throws Exception {
+ throws Exception
+ {
checkSocket();
out.writeByte( m_deleteTemporaryDestination );
out.writeObject( dest );
waitAnswer();
}
-
+
public synchronized void receive( ReceiveRequest messages[] )
- throws Exception {
- cat.debug( "Checking socket" );
+ throws Exception
+ {
+ boolean trace = log.isTraceEnabled();
+ if( trace )
+ log.trace( "Checking socket" );
checkSocket();
- cat.debug( "Writing request" );
+ if( trace )
+ log.trace( "Writing request" );
out.writeByte( m_receive );
out.writeInt( messages.length );
- for ( int i = 0; i < messages.length; ++i ) {
+ for ( int i = 0; i < messages.length; ++i )
+ {
messages[i].writeExternal( out );
}
- cat.debug( "Waiting for awnser" );
+ if( trace )
+ log.trace( "Waiting for awnser" );
waitAnswer();
- cat.debug( "Done" );
+ if( trace )
+ log.trace( "Done" );
}
-
+
protected void checkSocket()
- throws Exception {
- if ( socket == null ) {
+ throws Exception
+ {
+ if ( socket == null )
+ {
createConnection();
}
}
-
+
protected void createConnection()
- throws RemoteException {
- try {
- cat.info( "ConnectionReceiverOILClient is connecting to: " +
addr.getHostAddress() + ":" + port );
+ throws RemoteException
+ {
+ try
+ {
+ log.debug( "ConnectionReceiverOILClient is connecting to: " +
addr.getHostAddress() + ":" + port );
socket = new Socket( addr, port );
out = new ObjectOutputStream( new BufferedOutputStream(
socket.getOutputStream() ) );
out.flush();
in = new ObjectInputStream( new BufferedInputStream(
socket.getInputStream() ) );
- } catch ( Exception e ) {
- cat.debug( e );
+ }
+ catch ( Exception e )
+ {
+ log.debug( e );
throw new RemoteException( "Cannot connect to the
ConnectionReceiver/Server" );
}
}
-
+
protected void waitAnswer()
- throws Exception {
+ throws Exception
+ {
Exception throwException = null;
-
[JBoss-dev] CVS update: jnp/src/build build.xml
User: starksm
Date: 01/11/27 22:16:35
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.5.2.2 +22 -4 jnp/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jnp/src/build/Attic/build.xml,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- build.xml 2001/09/07 23:17:44 1.5.2.1
+++ build.xml 2001/11/28 06:16:35 1.5.2.2
@@ -5,7 +5,7 @@
-
+
@@ -43,6 +43,18 @@
+
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
@@ -72,9 +84,12 @@
+
+
+
@@ -85,13 +100,16 @@
/>
+
+
+
-
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/referenceable SpyConnectionFactoryObjectFactory.java SpyDestinationObjectFactory.java
User: starksm
Date: 01/11/27 22:15:32
Modified:src/main/org/jboss/mq/referenceable Tag: Branch_2_4
SpyConnectionFactoryObjectFactory.java
SpyDestinationObjectFactory.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +24 -18
jbossmq/src/main/org/jboss/mq/referenceable/SpyConnectionFactoryObjectFactory.java
Index: SpyConnectionFactoryObjectFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/referenceable/SpyConnectionFactoryObjectFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyConnectionFactoryObjectFactory.java2001/08/23 03:57:12 1.2.2.1
+++ SpyConnectionFactoryObjectFactory.java2001/11/28 06:15:31 1.2.2.2
@@ -8,6 +8,7 @@
import javax.naming.spi.ObjectFactory;
+import org.jboss.logging.Logger;
import org.jboss.mq.GenericConnectionFactory;
/**
@@ -17,13 +18,12 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class SpyConnectionFactoryObjectFactory implements
javax.naming.spi.ObjectFactory {
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
SpyConnectionFactoryObjectFactory.class );
-
-
+public class SpyConnectionFactoryObjectFactory implements
javax.naming.spi.ObjectFactory
+{
+ private static Logger log = Logger.getLogger(
SpyConnectionFactoryObjectFactory.class );
+
/**
* getObjectInstance method.
*
@@ -34,23 +34,29 @@
* @return The ObjectInstance value
* @exception java.lang.Exception Description of Exception
*/
- public java.lang.Object getObjectInstance( java.lang.Object reference,
javax.naming.Name name, javax.naming.Context contex, java.util.Hashtable properties )
- throws java.lang.Exception {
-
- cat.debug( "SpyConnectionFactoryObjectFactory->getObjectInstance()" );
- try {
-
+ public java.lang.Object getObjectInstance(Object reference, javax.naming.Name
name, javax.naming.Context contex, java.util.Hashtable properties )
+ throws Exception
+ {
+ if( log.isTraceEnabled() )
+ log.trace( "SpyConnectionFactoryObjectFactory->getObjectInstance()" );
+ try
+ {
javax.naming.Reference ref = ( javax.naming.Reference )reference;
GenericConnectionFactory dcf = ( GenericConnectionFactory )
- ObjectRefAddr.extractObjectRefFrom( ref, "DCF" );
-
- if ( ref.getClassName().equals( "org.jboss.mq.SpyConnectionFactory" ) ) {
+ ObjectRefAddr.extractObjectRefFrom( ref, "DCF" );
+
+ if ( ref.getClassName().equals( "org.jboss.mq.SpyConnectionFactory" ) )
+ {
return new org.jboss.mq.SpyConnectionFactory( dcf );
- } else if ( ref.getClassName().equals(
"org.jboss.mq.SpyXAConnectionFactory" ) ) {
+ }
+ else if ( ref.getClassName().equals( "org.jboss.mq.SpyXAConnectionFactory"
) )
+ {
return new org.jboss.mq.SpyXAConnectionFactory( dcf );
}
- } catch ( Throwable ignore ) {
- ignore.printStackTrace();
+ }
+ catch ( Throwable ignore )
+ {
+ log.debug("Unexpected error", ignore);
// This method should not throw an exception since
// It would prevent another ObjectFactory from attempting
// to create an instance of the object.
1.2.2.2 +33 -20
jbossmq/src/main/org/jboss/mq/referenceable/SpyDestinationObjectFactory.java
Index: SpyDestinationObjectFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/referenceable/SpyDestinationObjectFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- SpyDestinationObjectFactory.java 2001/08/23 03:57:12 1.2.2.1
+++ SpyDestinationObjectFactory.java 2001/11/28 06:15:31 1.2.2.2
@@ -8,25 +8,29 @@
import javax.naming.spi.ObjectFactory;
+import org.jboss.logging.Logger;
+
/**
* This class is used to create instances of of: SpyTopic SpyQueue classes from
* a javax.naming.Reference instance.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
-public class SpyDestinationObjectFactory implements javax.
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/jms ClusterTopicConnectionFactory.java
User: starksm
Date: 01/11/27 22:15:31
Modified:src/main/org/jboss/mq/cluster/jms Tag: Branch_2_4
ClusterTopicConnectionFactory.java
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.2 +1 -3
jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicConnectionFactory.java
Index: ClusterTopicConnectionFactory.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicConnectionFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- ClusterTopicConnectionFactory.java2001/08/23 03:57:09 1.2.2.1
+++ ClusterTopicConnectionFactory.java2001/11/28 06:15:30 1.2.2.2
@@ -20,13 +20,11 @@
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.2.2.1 $
+ * @version$Revision: 1.2.2.2 $
*/
public class ClusterTopicConnectionFactory implements java.io.Serializable,
javax.jms.TopicConnectionFactory {
private XElement serverXElement;
-
- static org.apache.log4j.Category cat = org.apache.log4j.Category.getInstance(
ClusterTopicConnection.class );
public ClusterTopicConnectionFactory()
throws Exception {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/build build.xml
User: starksm
Date: 01/11/27 22:15:27
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Complete switch to org.jboss.logging.Logger and use trace to reduce default
logging
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.8.2.3 +15 -0 jbossmq/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbossmq/src/build/Attic/build.xml,v
retrieving revision 1.8.2.2
retrieving revision 1.8.2.3
diff -u -r1.8.2.2 -r1.8.2.3
--- build.xml 2001/09/08 05:41:33 1.8.2.2
+++ build.xml 2001/11/28 06:15:27 1.8.2.3
@@ -67,6 +67,18 @@
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
@@ -104,6 +116,7 @@
+
@@ -111,11 +124,13 @@
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee/src/build build.xml
User: starksm
Date: 01/11/27 22:14:18
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.8.2.2 +16 -2 jboss-j2ee/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss-j2ee/src/build/Attic/build.xml,v
retrieving revision 1.8.2.1
retrieving revision 1.8.2.2
diff -u -r1.8.2.1 -r1.8.2.2
--- build.xml 2001/09/10 16:36:31 1.8.2.1
+++ build.xml 2001/11/28 06:14:18 1.8.2.2
@@ -11,7 +11,7 @@
-
+
@@ -51,6 +51,18 @@
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
@@ -78,16 +90,18 @@
-
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/build build.xml
User: starksm
Date: 01/11/27 22:11:24
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.4.2.6 +14 -0 jbosscx/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosscx/src/build/Attic/build.xml,v
retrieving revision 1.4.2.5
retrieving revision 1.4.2.6
diff -u -r1.4.2.5 -r1.4.2.6
--- build.xml 2001/11/20 09:23:18 1.4.2.5
+++ build.xml 2001/11/28 06:11:24 1.4.2.6
@@ -61,6 +61,18 @@
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
@@ -80,8 +92,10 @@
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool/src/build build.xml
User: starksm
Date: 01/11/27 22:11:08
Modified:src/build Tag: Branch_2_4 build.xml
Log:
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.2.5 +18 -1 jbosspool/src/build/Attic/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosspool/src/build/Attic/build.xml,v
retrieving revision 1.2.2.4
retrieving revision 1.2.2.5
diff -u -r1.2.2.4 -r1.2.2.5
--- build.xml 2001/10/21 11:01:27 1.2.2.4
+++ build.xml 2001/11/28 06:11:08 1.2.2.5
@@ -55,6 +55,18 @@
+
+Specification-Title: ${Name}-${version}
+Specification-Version: ${version}
+Specification-Vendor: JBoss Group, LLC
+Implementation-Title: ${Name}-${release} CVSTag=${release-tag}
+Implementation-Version: ${release}.${build.time}
+Implementation-Vendor: JBoss Group, LLC
+
+
+
+
@@ -82,8 +94,10 @@
+
@@ -93,7 +107,9 @@
-
+
@@ -104,6 +120,7 @@
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/srp SRPRemoteServer.java
User: starksm
Date: 01/11/27 22:10:46
Modified:src/main/org/jboss/security/srp Tag: Branch_2_4
SRPRemoteServer.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.1.4.2 +1 -4 jbosssx/src/main/org/jboss/security/srp/SRPRemoteServer.java
Index: SRPRemoteServer.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/srp/SRPRemoteServer.java,v
retrieving revision 1.1.4.1
retrieving revision 1.1.4.2
diff -u -r1.1.4.1 -r1.1.4.2
--- SRPRemoteServer.java 2001/11/09 10:19:28 1.1.4.1
+++ SRPRemoteServer.java 2001/11/28 06:10:46 1.1.4.2
@@ -16,9 +16,6 @@
import java.util.HashMap;
import java.util.Map;
-import org.apache.log4j.Category;
-
-import org.jboss.logging.log4j.TracePriority;
import org.jboss.security.Logger;
import org.jboss.security.Util;
import org.jboss.security.srp.SRPServerInterface.SRPParameters;
@@ -27,7 +24,7 @@
/** An implementation of the RMI SRPRemoteServerInterface interface.
@author [EMAIL PROTECTED]
-@version $Revision: 1.1.4.1 $
+@version $Revision: 1.1.4.2 $
*/
public class SRPRemoteServer extends UnicastRemoteObject implements
SRPRemoteServerInterface
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java
User: starksm
Date: 01/11/27 22:10:46
Modified:src/main/org/jboss/security/plugins Tag: Branch_2_4
JaasSecurityManager.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.7.2.9 +10 -12
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.7.2.8
retrieving revision 1.7.2.9
diff -u -r1.7.2.8 -r1.7.2.9
--- JaasSecurityManager.java 2001/11/09 10:24:51 1.7.2.8
+++ JaasSecurityManager.java 2001/11/28 06:10:46 1.7.2.9
@@ -29,9 +29,7 @@
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
-import org.apache.log4j.Category;
-
-import org.jboss.logging.log4j.TracePriority;
+import org.jboss.logging.Logger;
import org.jboss.security.AppPolicy;
import org.jboss.security.AuthenticationInfo;
import org.jboss.security.RealmMapping;
@@ -55,7 +53,7 @@
@author Oleg Nitz
@author [EMAIL PROTECTED]
- @version $Revision: 1.7.2.8 $
+ @version $Revision: 1.7.2.9 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
@@ -90,7 +88,7 @@
private SecurityAssociationHandler handler = new SecurityAssociationHandler();
/** The log4j category for the security manager domain
*/
- protected Category log;
+ protected Logger log;
/** Get the currently authenticated Subject in securityDomain.
@return The Subject for securityDomain if one exists, false otherwise.
@@ -143,8 +141,8 @@
public JaasSecurityManager(String securityDomain)
{
this.securityDomain = securityDomain;
- String categoryName = getClass().getName()+"#"+securityDomain;
- this.log = Category.getInstance(categoryName);
+ String categoryName = getClass().getName()+'.'+securityDomain;
+ this.log = Logger.getLogger(categoryName);
try
{ // Try to get the SecurityPolicy from the JAAS Policy class
securityPolicy = (SecurityPolicy) Policy.getPolicy();
@@ -374,7 +372,7 @@
catch(LoginException e)
{
// Don't log anonymous user failures unless trace level logging is on
- if( principal != null && principal.getName() != null ||
log.isEnabledFor(TracePriority.TRACE) )
+ if( principal != null && principal.getName() != null ||
log.isTraceEnabled() )
log.debug("Login failure", e);
}
@@ -401,8 +399,8 @@
*/
private boolean validateCache(DomainInfo info, Object credential)
{
- if( log.isEnabledFor(TracePriority.TRACE) )
- log.log(TracePriority.TRACE, "validateCache, info="+info);
+ if( log.isTraceEnabled() )
+ log.trace("validateCache, info="+info);
Object subjectCredential = info.credential;
boolean isValid = false;
@@ -461,8 +459,8 @@
info.subject = subject;
info.credential = credential;
- if( log.isEnabledFor(TracePriority.TRACE) )
- log.log(TracePriority.TRACE, "updateCache, subject="+subject);
+ if( log.isTraceEnabled() )
+ log.trace("updateCache, subject="+subject);
/* If we don't have a cache policy create a default timed cache
that has an 1800 sec lifetime, is thread-safe, and a resolution
of 60 seconds.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/ssl DomainServerSocketFactory.java RMISSLClientSocketFactory.java
User: starksm
Date: 01/11/27 22:10:46
Modified:src/main/org/jboss/security/ssl Tag: Branch_2_4
DomainServerSocketFactory.java
RMISSLClientSocketFactory.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.1.2.3 +3 -4
jbosssx/src/main/org/jboss/security/ssl/Attic/DomainServerSocketFactory.java
Index: DomainServerSocketFactory.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/ssl/Attic/DomainServerSocketFactory.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- DomainServerSocketFactory.java2001/11/09 10:18:14 1.1.2.2
+++ DomainServerSocketFactory.java2001/11/28 06:10:46 1.1.2.3
@@ -19,8 +19,7 @@
import com.sun.net.ssl.TrustManager;
import com.sun.net.ssl.TrustManagerFactory;
-import org.apache.log4j.Category;
-
+import org.jboss.logging.Logger;
import org.jboss.security.SecurityDomain;
/** An implementation of ServerSocketFactory that creates SSL server sockets
@@ -33,11 +32,11 @@
@see org.jboss.security.SecurityDomain
@author [EMAIL PROTECTED]
-@version $Revision: 1.1.2.2 $
+@version $Revision: 1.1.2.3 $
*/
public class DomainServerSocketFactory extends ServerSocketFactory
{
- private static Category log =
Category.getInstance(DomainServerSocketFactory.class);
+ private static Logger log = Logger.getLogger(DomainServerSocketFactory.class);
private transient SecurityDomain securityDomain;
private transient InetAddress bindAddress;
1.2.2.2 +4 -4
jbosssx/src/main/org/jboss/security/ssl/RMISSLClientSocketFactory.java
Index: RMISSLClientSocketFactory.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/ssl/RMISSLClientSocketFactory.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- RMISSLClientSocketFactory.java2001/11/09 10:18:14 1.2.2.1
+++ RMISSLClientSocketFactory.java2001/11/28 06:10:46 1.2.2.2
@@ -16,13 +16,13 @@
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.SSLSocket;
-import org.apache.log4j.Category;
+import org.jboss.logging.Logger;
/** An implementation of RMIClientSocketFactory that uses the JSSE
default SSLSocketFactory to create a client SSLSocket.
*
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.2.2.1 $
+ * @version $Revision: 1.2.2.2 $
*/
public class RMISSLClientSocketFactory implements HandshakeCompletedListener,
RMIClientSocketFactory, Serializable
@@ -60,8 +60,8 @@
public void handshakeCompleted(HandshakeCompletedEvent handshakeCompletedEvent)
{
- Category log = Category.getInstance(RMISSLClientSocketFactory.class);
- if( log.isDebugEnabled() )
+ Logger log = Logger.getLogger(RMISSLClientSocketFactory.class);
+ if( log.isTraceEnabled() )
{
String cipher = handshakeCompletedEvent.getCipherSuite();
SSLSession session = handshakeCompletedEvent.getSession();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/auth/spi DatabaseServerLoginModule.java UsernamePasswordLoginModule.java
User: starksm
Date: 01/11/27 22:10:45
Modified:src/main/org/jboss/security/auth/spi Tag: Branch_2_4
DatabaseServerLoginModule.java
UsernamePasswordLoginModule.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.2.4.3 +11 -3
jbosssx/src/main/org/jboss/security/auth/spi/DatabaseServerLoginModule.java
Index: DatabaseServerLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/DatabaseServerLoginModule.java,v
retrieving revision 1.2.4.2
retrieving revision 1.2.4.3
diff -u -r1.2.4.2 -r1.2.4.3
--- DatabaseServerLoginModule.java2001/10/19 23:50:08 1.2.4.2
+++ DatabaseServerLoginModule.java2001/11/28 06:10:45 1.2.4.3
@@ -43,7 +43,7 @@
@author Oleg Nitz
@author [EMAIL PROTECTED]
- @version $Revision: 1.2.4.2 $
+ @version $Revision: 1.2.4.3 $
*/
public class DatabaseServerLoginModule extends UsernamePasswordLoginModule
{
@@ -157,8 +157,16 @@
ps.setString(1, username);
ResultSet rs = ps.executeQuery();
if( rs.next() == false )
-throw new FailedLoginException("No matching username found in Roles");
-
+ {
+if( getUnauthenticatedIdentity() == null )
+ throw new FailedLoginException("No matching username found in
Roles");
+/* We are running with an unauthenticatedIdentity so create an
+ empty Roles set and return.
+*/
+Group[] roleSets = { new SimpleGroup("Roles") };
+return roleSets;
+ }
+
do
{
String name = rs.getString(1);
1.3.4.4 +8 -1
jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java
Index: UsernamePasswordLoginModule.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/auth/spi/UsernamePasswordLoginModule.java,v
retrieving revision 1.3.4.3
retrieving revision 1.3.4.4
diff -u -r1.3.4.3 -r1.3.4.4
--- UsernamePasswordLoginModule.java 2001/10/19 23:50:08 1.3.4.3
+++ UsernamePasswordLoginModule.java 2001/11/28 06:10:45 1.3.4.4
@@ -38,7 +38,7 @@
@see #getUsersRoles()
@author [EMAIL PROTECTED]
- @version $Revision: 1.3.4.3 $
+ @version $Revision: 1.3.4.4 $
*/
public abstract class UsernamePasswordLoginModule extends AbstractServerLoginModule
{
@@ -61,7 +61,10 @@
// Check for unauthenticatedIdentity option.
String name = (String) options.get("unauthenticatedIdentity");
if( name != null )
+ {
unauthenticatedIdentity = new SimplePrincipal(name);
+ super.log.trace("Saw unauthenticatedIdentity="+name);
+ }
}
/**
@@ -95,7 +98,11 @@
String username = info[0];
String password = info[1];
if( username == null && password == null )
+ {
identity = unauthenticatedIdentity;
+ super.log.trace("Authenticating as unauthenticatedIdentity="+identity);
+ }
+
if( identity == null )
{
identity = new SimplePrincipal(username);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security Logger.java
User: starksm
Date: 01/11/27 22:10:45
Modified:src/main/org/jboss/security Tag: Branch_2_4 Logger.java
Log:
Complete switch to org.jboss.logging.Logger
Add support for package version manifest headers
Revision ChangesPath
No revision
No revision
1.1.2.2 +3 -2 jbosssx/src/main/org/jboss/security/Attic/Logger.java
Index: Logger.java
===
RCS file: /cvsroot/jboss/jbosssx/src/main/org/jboss/security/Attic/Logger.java,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- Logger.java 2001/10/19 23:48:23 1.1.2.1
+++ Logger.java 2001/11/28 06:10:45 1.1.2.2
@@ -8,13 +8,14 @@
classes using the thread context class loader.
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.1.2.1 $
+ * @version $Revision: 1.1.2.2 $
*/
public class Logger
{
/** */
private static final String CATEGORY_CLASS = "org.apache.log4j.Category";
private static final String PRIORITY_CLASS = "org.apache.log4j.Priority";
+ private static final String TRACE_PRIORITY_CLASS =
"org.jboss.logging.TracePriority";
private static final int GET_INSTANCE = 0;
private static final int IS_ENABLED_FOR_PRIORITY = 1;
private static final int LOG_PRIORITY_MSG = 2;
@@ -221,7 +222,7 @@
log4jPriorities[n] = toPriority.invoke(null, args);
}
// Load the custom trace Priority class
- Class trace = loader.loadClass("org.jboss.logging.log4j.TracePriority");
+ Class trace = loader.loadClass(TRACE_PRIORITY_CLASS);
toPriorityTypes = new Class[] {String.class, priorityClass};
toPriority = trace.getDeclaredMethod("toPriority", toPriorityTypes);
log4jPriorities[0] = toPriority.invoke(null, new Object[]{"TRACE",
log4jPriorities[1]});
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/build build.xml
User: starksm Date: 01/11/27 22:10:45 Modified:src/build Tag: Branch_2_4 build.xml Log: Complete switch to org.jboss.logging.Logger Add support for package version manifest headers Revision ChangesPath No revision No revision 1.11.2.5 +23 -7 jbosssx/src/build/Attic/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/src/build/Attic/build.xml,v retrieving revision 1.11.2.4 retrieving revision 1.11.2.5 diff -u -r1.11.2.4 -r1.11.2.5 --- build.xml 2001/11/09 10:30:14 1.11.2.4 +++ build.xml 2001/11/28 06:10:45 1.11.2.5 @@ -1,6 +1,6 @@ @@ -104,9 +116,11 @@ + - - + + @@ -137,10 +151,11 @@ - - + + @@ -162,11 +177,12 @@ - - + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/pictures altowebLogo.gif download.gif sam.gif service.gif viagra4.gif
User: mnf999 Date: 01/11/27 21:17:42 Added: src/docs/pictures altowebLogo.gif download.gif sam.gif service.gif viagra4.gif Log: new banners, new training, new partners Revision ChangesPath 1.1 newsite/src/docs/pictures/altowebLogo.gif <> 1.1 newsite/src/docs/pictures/download.gif <> 1.1 newsite/src/docs/pictures/sam.gif <> 1.1 newsite/src/docs/pictures/service.gif <> 1.1 newsite/src/docs/pictures/viagra4.gif <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs binary.jsp head.jsp index.jsp navigation.jsp
User: mnf999
Date: 01/11/27 21:17:37
Modified:src/docs binary.jsp head.jsp index.jsp navigation.jsp
Log:
new banners, new training, new partners
Revision ChangesPath
1.15 +43 -17newsite/src/docs/binary.jsp
Index: binary.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/binary.jsp,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- binary.jsp2001/11/21 21:13:48 1.14
+++ binary.jsp2001/11/28 05:17:32 1.15
@@ -41,64 +41,90 @@
Download now:
-JBoss 2.4
-
+JBOSS 3.0
-
- Packages Size Date
+ Packages
+ Size
+ Date
http://prdownloads.sourceforge.net/jboss/jboss-3.0.0alpha.zip";>JBoss-3.0.0.zip
alpha
-9951882
+9.9M
November 21, 2001
-
+
+
+JBOSS 2.4
+
+
+
+
+ Packages
+ Size
+ Date
+
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.zip";>JBoss-2.4.3.zip
-6125514
+6.1M
October 3, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3.tgz";>JBoss-2.4.3.tgz Src
Archive
-19010983
+19M
October 3, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3_Tomcat-3.2.3.zip";>JBoss-2.4.3_Tomcat-3.2.3.zip
-9404161
+9.4M
October 3, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.3_Jetty-3.1.3-1.zip";>JBoss-2.4.3_Jetty-3.1.3-1.zip
-10512966
+10.5M
October 30, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1.zip";>JBoss-2.4.1.zip
-8379911
-Setempter 10, 2001
+8.3M
+September 10, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1a_Tomcat-3.2.3.zip";>JBoss-2.4.1a_Tomcat-3.2.3.zip
-9018426
-Setempter 14, 2001
+9M
+September 14, 2001
http://prdownloads.sourceforge.net/jboss/JBoss-2.4.1_Jetty-3.1.RC9-1.zip";>JBoss-2.4.1_Jetty-3.1.RC9-1.zip
-12773406
+12.7M
September 15, 2001
-Change Log for version 2.4.x.
+Change Log
for version 2.4.x.
+
+ PARTNER SOFTWARE FOR JBOSS 2.4.x
+AltoWeb™ Instant J2EE and Web Services. Evaluation software bundled
+with JBoss 2.4.3 and Tomcat 3.2.3.
+
+ Packages
+ Size
+ Date
+
+http://www.altoweb.com/b/jbossDl.html";>altoweb-2.5-jboss243-nojvm.win.zip
+31.8M
+November 12,2001
+
+
+
-JBoss 2.2.2
+
+ 2.2.2
1.10 +1 -2 newsite/src/docs/head.jsp
Index: head.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/head.jsp,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- head.jsp 2001/11/21 03:21:08 1.9
+++ head.jsp 2001/11/28 05:17:34 1.10
@@ -26,8 +26,7 @@
-
-
+
1.32 +3 -3 newsite/src/docs/index.jsp
Index: index.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/index.jsp,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- index.jsp 2001/11/21 03:21:08 1.31
+++ index.jsp 2001/11/28 05:17:34 1.32
@@ -54,13 +54,13 @@
-TRAINING FROM THE GURUS: BOSTON JAN 21-25, SYDNEY FEB 11-15
+TRAINING FROM THE GURUS: BOSTON JAN 21-25, SYDNEY FEB 11-15, LONDON
MAR 11-15
Spend your money on "source knowledge" not proprietary licenses.
Training is a requirement for those wishing to participate in The JBoss Certified
Affiliate Program,
for 3rd party JBoss consulting and support providers. The next JBoss Group
trainings
- will be held in Boston and Down Under in Sydney.
- Don't miss out on our unique road show.
+ will be held in Boston, Down Under in Sydney and in Londond again.
+ Don't miss out on our unique Q1 2002 road show.
Read more.
1.17 +7 -0 newsite/src/docs/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/navigation.jsp,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- navigation.jsp2001/11/21 21:47:32 1.16
+++ navigation.jsp2001/11/28 05:17:35 1.17
@@ -2,6 +2,13 @@
<% if (request.getParameter("printable") == null)
[JBoss-dev] CVS update: newsite/src/docs/common picabanner.jsp doco.jsp
User: mnf999
Date: 01/11/27 21:17:42
Modified:src/docs/common doco.jsp
Added: src/docs/common picabanner.jsp
Log:
new banners, new training, new partners
Revision ChangesPath
1.8 +26 -7 newsite/src/docs/common/doco.jsp
Index: doco.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/common/doco.jsp,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- doco.jsp 2001/11/07 19:55:37 1.7
+++ doco.jsp 2001/11/28 05:17:41 1.8
@@ -1,13 +1,33 @@
BUY THE DOCUMENTATION
-
+
+
+
+
+
+
In order to support the development of JBoss and ensure that the documentation
remains up to date we offer printable version of the documentation for purchase.
The manual contains all the documentation a user needs to install,
configure and run JBoss. It also includes a quick start section and helps you to
make your first steps
with JBoss. As a promotion we include the working draft of the forthcoming JBoss
book to be
- published by SAMS publishing. http://www.flashline.com/components/view.jsp?prodid=4252";>Buy now.
+ published by SAMS publishing. This book is a complete rewrite of the documentation
by Scott Stark.http://www.flashline.com/components/view.jsp?prodid=4252";>Buy now.
+
+
+JBOSSCMP 2.0 PERSISTENCE ENGINE DOCUMENTATION
+
+JBOSS 3.0 comes with a full blown JBOSSCMP persistence engine.
This is a fully
+EJB 2.0 compliant persistence engine. The engine is Open Source and free (part of
the free JBOSS core),
+the documentation costs $5. This is the official documentation, for the CMP 2.0
engine in JBoss.
+JBossCMP includes many new features, such as eager/lazy loading of fields,
read-only fields, Container
+Managed Relationships, ejbSelect methods, and ejb-ql support. The manual
introduces you to each
+feature in detail and its configuration, and guides you through the process of
specifying the database mapping
+of container managed fields, relationships and queries. Example code is included
throughout the text.
+This is you chance to purchase the official documentation package written by the
feature's developer,
+Dain Sundstrom. This material is not available in the free documentation or the
$9.99 base documentation.
+http://www.flashline.com/Components/View.jsp?prodid=4312";>Buy
Now.
+
BROWSE THE MANUAL
A free volunteer maintained manual was developed in the
early stages of JBoss. A more complete and updated version
@@ -22,10 +42,10 @@
CVS.
http://search.freefind.com/find.html"; METHOD="GET">
-Search the
- manual only
- entire JBoss site
-
+Search the
+ manual only
+ entire JBoss site
+
for a keyword:
@@ -48,5 +68,4 @@
Running ECperf on JBoss
Migrating to JBoss 2.2
- Activating CMP 2.x support
1.1 newsite/src/docs/common/picabanner.jsp
Index: picabanner.jsp
===
<%!
String[] banner = {
"sam.gif",
"service.gif",
"download.gif",
"viagra4.gif",
"banner-x.gif",
"banner-x.gif",
"banner-x.gif"
};
java.util.Random random = new java.util.Random();
%>
<% int select = new Float(random.nextFloat()*banner.length).intValue(); %>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 2.4.4 performance issue resolved, MarshalledObject again
I finally tracked down the issue that was causing the performance regression in the pending 2.4.4 release. It was another case of the MarshalledObject generating huge serialized forms due to the encoded object's class loader classpath. The change that triggered this was the removal of the jboss-client.jar from the run.jar classpath. This caused the ejb handles to see the server classpath as their annotated classpath and resulted in 9k serialized form sizes. I didn't want to go back to needing additional classes in the classpath so I used a trival subclass of MLet as the server main classloader that returned an empty URL[] from the getURLs() method. This restored the RMI server codebase value as the annotated codebase of the ejb handles and the serialized size dropped to < 1k. The moral is known minimize your MarshalledObject input's class loader classpath. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: website-forums/src/web/forums footer.jsp header.jsp
User: mnf999
Date: 01/11/27 21:18:39
Modified:src/web/forums footer.jsp header.jsp
Log:
new header and footer for forums, banners
Revision ChangesPath
1.5 +8 -0 website-forums/src/web/forums/footer.jsp
Index: footer.jsp
===
RCS file: /cvsroot/jboss/website-forums/src/web/forums/footer.jsp,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- footer.jsp2001/10/06 06:56:02 1.4
+++ footer.jsp2001/11/28 05:18:39 1.5
@@ -1,4 +1,12 @@
+
+
+
+
+
+
+
+
1.7 +10 -7 website-forums/src/web/forums/header.jsp
Index: header.jsp
===
RCS file: /cvsroot/jboss/website-forums/src/web/forums/header.jsp,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- header.jsp2001/10/11 15:01:13 1.6
+++ header.jsp2001/11/28 05:18:39 1.7
@@ -1,8 +1,8 @@
<%
/**
* $RCSfile: header.jsp,v $
- * $Revision: 1.6 $
- * $Date: 2001/10/11 15:01:13 $
+ * $Revision: 1.7 $
+ * $Date: 2001/11/28 05:18:39 $
*/
%>
@@ -41,13 +41,16 @@
vlink="<%= JiveGlobals.getJiveProperty("skin.default.vLinkColor") %>"
alink="<%= JiveGlobals.getJiveProperty("skin.default.aLinkColor") %>">
+
-
-
-
-
-
+
+
+
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/jbossgroup cocobase.jsp partners.jsp training.jsp
User: mnf999 Date: 01/11/27 21:17:42 Modified:src/docs/jbossgroup partners.jsp training.jsp Added: src/docs/jbossgroup cocobase.jsp Log: new banners, new training, new partners Revision ChangesPath 1.3 +74 -43newsite/src/docs/jbossgroup/partners.jsp Index: partners.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/jbossgroup/partners.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- partners.jsp 2001/10/12 23:01:29 1.2 +++ partners.jsp 2001/11/28 05:17:42 1.3 @@ -31,11 +31,67 @@ high-quality, JBoss-compatible products, remember that, through their partnership with JBoss Group, all the companies featured here help finance the free JBoss effort and these product sales help JBoss remain strong, competitive and ahead of the curve. + +APPLICATION PLATFORMS +ALTOWEB +http://www.altoweb.com/b/jboss.html";> + +The AltoWeb® Application Platform, run on JBoss™ application server, provides a reusable, + component-based architecture and rapid application development solution that streamlines + the development, deployment, monitoring, and management of e-Business applications. The AltoWeb + Application Platform on JBoss maximizes your productivity when you need to deliver an increasing + number of applications faster than ever before, with fewer resources, and at a lower + cost. The AltoWeb Application Platform on JBoss helps you develop, deploy, and change your + e-Business applications in the fastest possible way. +http://www.altoweb.com/b/jboss.html";>Read More +http://www.altoweb.com/b/jbossBuy.html";>Buy Now. + +HOSTING + +RACKSPACE: MANAGED JBOSS HOSTING NOW AVAILABLE + + +http://www.rackspace.com/?supbig=jboss1";> + + +Rackspace Managed Hosting is a pioneer and leader in the fastest growing segment of Internet hosting. +Rackspace rents dedicated web servers that anyone can afford. No colocation or shared servers, +only whole servers. Using hardware chosen for web hosting, Rackspace builds custom web servers to host +Internet sites of any size or type. +Standard choices are; Windows/IIS or Linux/Apache, Pentium or UltraSparc, RAM, size and type of hard +drives, and estimated bandwidth. Additional services include; firewalls, load balancing, clustering, backup, advanced monitoring, site analysis, streaming media, email and ecommerce software, and more. +Rackspace will build your server and place it in a world-class datacenter with the other 4000 plus +servers they manage. They promise to have it online for you within 24 hours. You get root access +to your server and remotely install any software and content you want. You manage the applications +and content, and Rackspace guarantees the operation of every server and datacenter component. +Contracts can be as short as 30-days. +And the best part, every component supplied by Rackspace comes with 24x7 "Fanatical" customer service that's ranked #1 in the hosting industry. +It couldn't be any easier or more cost effective. +mailto:[EMAIL PROTECTED]?subject=Rackspace";>Buy Now. + +IDE INTEGRATION + +TOGETHERSOFT DEPLOYER FOR JBOSS. + +The JBoss˜ Deployer Plugin for Together ControlCenter˜ 5.0.2 and 5.5 provides +EJB Jar, WAR and EAR generation for the JBoss 2.2/2.4 server. The generated files include the JBoss +specific XML descriptor files (jboss.xml, jboss-web.xml and jaws.xml). The plugin also provides +server management features to start/stop the JBoss server and undeploy modules. JBoss can be +launched in debug and the EJBs deployed; the Servlets/JSPs can be deployed and Tomcat launched in +debug. Then the debugger can be used to step through any or all of the JSPs, Servlets and EJBs +(and JBoss code if you so wish!). All this can be done without leaving the +Together®environment. +Read more +http://www.flashline.com/components/view.jsp?prodid=4042&affiliateid=260343";>Buy Now + +Together is a registered trademark of TogetherSoft Corporation +Together ControlCenter is a trademark of TogetherSoft Corporation + PERSISTENCE ENGINES COCOBASE -http://www.thoughtinc.com/jboss/index.html";> +http://www.thoughtinc.com/jboss/index.html";> CocoBase Enterprise O/R is the leading O/R mapping tool, optimized for EJB and Java, is tightly integrated with the JBoss Application Server. CocoBase maps database tables, @@ -48,9 +104,23 @@ Together Control Center). Using Cocobase Enterprise O/R with JBoss can cut the cost of development, deployment and maintenance of Java applications up to 85%. - +Read More http://www.thoughtinc.com/jboss/index.html";>Buy Now. +JBOSSCMP 2.0 PERSISTENCE ENGINE DOCUMENTATION +JBOSS 3.0 comes with a full blown JBOSSCMP persistence engine. T
[JBoss-dev] CVS update: newsite/src/docs/developers head.jsp index.jsp navigation.jsp
User: mnf999
Date: 01/11/27 21:17:42
Modified:src/docs/developers head.jsp index.jsp navigation.jsp
Log:
new banners, new training, new partners
Revision ChangesPath
1.7 +3 -2 newsite/src/docs/developers/head.jsp
Index: head.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/head.jsp,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- head.jsp 2001/11/21 03:21:09 1.6
+++ head.jsp 2001/11/28 05:17:42 1.7
@@ -27,8 +27,9 @@
-
-
+
+
+
1.11 +4 -4 newsite/src/docs/developers/index.jsp
Index: index.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/index.jsp,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- index.jsp 2001/11/21 03:21:09 1.10
+++ index.jsp 2001/11/28 05:17:42 1.11
@@ -59,14 +59,14 @@
the whole team.
-
-TRAINING: BOSTON JAN 21-25, SYDNEY FEB 11-15
+
+TRAINING FROM THE GURUS: BOSTON JAN 21-25, SYDNEY FEB 11-15, LONDON
MAR 11-15
Spend your money on "source knowledge" not proprietary licenses.
Training is a requirement for those wishing to participate in The JBoss Certified
Affiliate Program,
for 3rd party JBoss consulting and support providers. The next JBoss Group
trainings
- will be held in Boston and Down Under in Sydney.
- Don't miss out on our unique road show.
+ will be held in Boston, Down Under in Sydney and in Londond again.
+ Don't miss out on our unique Q1 2002 road show.
Read more.
1.14 +11 -1 newsite/src/docs/developers/navigation.jsp
Index: navigation.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/navigation.jsp,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- navigation.jsp2001/11/21 21:47:33 1.13
+++ navigation.jsp2001/11/28 05:17:42 1.14
@@ -2,10 +2,20 @@
<% if (request.getParameter("printable") == null) { %>
+
+
+
+
+
+
+
+
[Home]
[Top]
-
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Using java.lang.Package to get more info about a build
I would like to switch from the hard-coded version information embedded in
classes to use the standard java package version manifest headers that
are accessed using the java.lang.Package class. I have added support for
this to the 2.4.4 build I'm working on. It uses a target in the build.xml to
generate the approriate manifest headers. For example, to build the run.mf
manifest the following is done:
...
Specification-Title: JBoss-${version}
Specification-Version: ${version}
Specification-Vendor: JBoss Group, LLC
Implementation-Title: JBoss-${version} CVSTag=${version-tag}
Implementation-Version: ${version}.${build.time}
Implementation-Vendor: JBoss Group, LLC
...
The encoded information is then available for use at runtime. I have updated
the Info MBean to display the Package info, and for example, the current
2.4.4 build I'm testing shows the following info for the "org.jboss"
package:
Package: org.jboss
SpecificationTitle: JBoss-2.4.4
SpecificationVersion: 2.4.4
SpecificationVendor: JBoss Group, LLC
ImplementationTitle: JBoss-2.4.4 CVSTag=Rel_2_4_4_16
ImplementationVersion: 2.4.4.2001-11-27 20:59:04 PST
ImplementationVendor: JBoss Group, LLC
isSealed: false
I would like to update main to use a similar approach, but it would probably
be better to create either a custom manifest task or jar task to allow the
modules to use the manifest creation logic.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util Info.java InfoMBean.java
User: starksm
Date: 01/11/27 20:52:48
Modified:src/main/org/jboss/util Info.java InfoMBean.java
Log:
Add displayPackageInfo operation to display the lava.lang.Package
object info for a package name.
Revision ChangesPath
1.15 +53 -17jboss/src/main/org/jboss/util/Info.java
Index: Info.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/Info.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Info.java 2001/08/03 17:15:57 1.14
+++ Info.java 2001/11/28 04:52:48 1.15
@@ -21,7 +21,7 @@
* @author mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino.
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class Info
implements InfoMBean, MBeanRegistration
@@ -58,10 +58,12 @@
System.getProperty("os.arch"));
// dump out the entire system properties if debug is enabled
- if (log.isDebugEnabled()) {
+ if (log.isDebugEnabled())
+ {
log.debug("+++ Full System Properties Dump");
Enumeration names= System.getProperties().propertyNames();
- while (names.hasMoreElements()) {
+ while (names.hasMoreElements())
+ {
String pname= (String) names.nextElement();
log.debug(pname + ": " + System.getProperty(pname));
}
@@ -69,22 +71,27 @@
// MF TODO: say everything that needs to be said here:
// copyright, included libs and TM, contributor and (C) jboss org 2000
- return new ObjectName(OBJECT_NAME);
+ name = name == null ? new ObjectName(OBJECT_NAME) : name;
+ return name;
}
- public void postRegister(Boolean registrationDone) {
+ public void postRegister(Boolean registrationDone)
+ {
// empty
}
- public void preDeregister() throws Exception {
+ public void preDeregister() throws Exception
+ {
// empty
}
- public void postDeregister() {
+ public void postDeregister()
+ {
// empty
}
- public String getThreadGroupInfo(ThreadGroup group) {
+ public String getThreadGroupInfo(ThreadGroup group)
+ {
StringBuffer rc= new StringBuffer();
rc.append("");
@@ -96,7 +103,8 @@
rc.append("");
Thread threads[]= new Thread[group.activeCount()];
group.enumerate(threads, false);
- for (int i= 0; i < threads.length && threads[i] != null; i++) {
+ for (int i= 0; i < threads.length && threads[i] != null; i++)
+ {
rc.append("");
rc.append("Thread: " + threads[i].getName());
rc.append(" : ");
@@ -107,14 +115,16 @@
ThreadGroup groups[]= new ThreadGroup[group.activeGroupCount()];
group.enumerate(groups, false);
- for (int i= 0; i < groups.length && groups[i] != null; i++) {
+ for (int i= 0; i < groups.length && groups[i] != null; i++)
+ {
rc.append(getThreadGroupInfo(groups[i]));
}
rc.append("");
return rc.toString();
}
- public String runGarbageCollector() {
+ public String runGarbageCollector()
+ {
StringBuffer buff = new StringBuffer();
buff.append("Before");
buff.append(listMemoryUsage());
@@ -127,7 +137,8 @@
return buff.toString();
}
- public String listMemoryUsage() {
+ public String listMemoryUsage()
+ {
String rc= "Total Memory: " +
(Runtime.getRuntime().totalMemory()) +
" " + "Free Memory: " +
@@ -135,7 +146,8 @@
return rc;
}
- public String listSystemInfo() {
+ public String listSystemInfo()
+ {
// Dump out basic info as INFO priority msgs
StringBuffer rc= new StringBuffer();
rc.append("");
@@ -160,10 +172,12 @@
return rc.toString();
}
- public String listThreadDump() {
+ public String listThreadDump()
+ {
// Get the root thread group
ThreadGroup root= Thread.currentThread().getThreadGroup();
- while (root.getParent() != null) {
+ while (root.getParent() != null)
+ {
root = root.getParent();
}
@@ -181,17 +195,39 @@
return rc;
}
+ /** Display the java.lang.Package info for the pkgName */
+ public String displayPackageInfo(String pkgName)
+ {
+ Package pkg = Package.getPackage(pkgName);
+ if( pkg == null )
+ return "Package: "+pkgName+" Not Found!\n";
+
+ StringBuffer info = new StringBuffer("Package: "+pkgName+"\n");
+ info.append("\n");
+ info.append("SpecificationTitle: "+pkg.getSpecifica
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
he is done with the JMX book and he is baack
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Juha
|Lindfors
|Sent: Tuesday, November 27, 2001 7:27 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
|
|
| User: juhalindfors
| Date: 01/11/27 16:27:14
|
| Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
| Log:
|
|
| Revision ChangesPath
| 1.24 +9 -4
|jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
|
| Index: AbstractVerifier.java
| ===
| RCS file:
|/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractV
|erifier.java,v
| retrieving revision 1.23
| retrieving revision 1.24
| diff -u -r1.23 -r1.24
| --- AbstractVerifier.java2001/11/02 06:07:48 1.23
| +++ AbstractVerifier.java2001/11/28 00:27:14 1.24
| @@ -19,7 +19,7 @@
|* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
|02111-1307 USA
|*
|* This package and its source code is available at www.jboss.org
| - * $Id: AbstractVerifier.java,v 1.23 2001/11/02 06:07:48 schaefera Exp $
| + * $Id: AbstractVerifier.java,v 1.24 2001/11/28 00:27:14
|juhalindfors Exp $
|*/
|
| // standard imports
| @@ -70,7 +70,7 @@
|*
|*
|*
| - * @version $Revision: 1.23 $
| + * @version $Revision: 1.24 $
|* @since JDK 1.3
|*/
| public abstract class AbstractVerifier implements VerificationStrategy {
| @@ -979,8 +979,13 @@
| if (Error.class.isAssignableFrom(type))
| return false;
|
| -if (RuntimeException.class.isAssignableFrom(type))
| -return false;
| +// 28.3.4.4 (6) java.rmi.RemoteException and its subclasses,
|and unchecked
| +// exception classes, are assumed to be mapped to
|the implicit
| +// CORBA system exception, and are therefore not
|explicitly
| +// declared in OMG IDL.
| +//
| +//if (RuntimeException.class.isAssignableFrom(type))
| +//return false;
|
| if (!isRMIIDLValueType(type))
| return false;
|
|
|
|
|___
|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: jbossmq/src/main/org/jboss/mq/pm/file MessageLog.java PersistenceManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/pm/file MessageLog.java
PersistenceManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.8 +4 -1 jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MessageLog.java 2001/11/14 01:53:40 1.7
+++ MessageLog.java 2001/11/28 00:55:29 1.8
@@ -29,7 +29,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class MessageLog {
@@ -83,6 +83,9 @@
try {
File[] files = queueName.listFiles();
for ( int i = 0; i < files.length; i++ ) {
+// If it's a subdirectory, it's a different queue, PM will restore that
also, so ignore it here
+if (files[i].isDirectory())
+ continue;
String fileName = files[i].getName();
int extIndex = fileName.indexOf( "." );
if ( extIndex < 0 ) {
1.11 +37 -4 jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- PersistenceManager.java 2001/11/14 04:23:27 1.10
+++ PersistenceManager.java 2001/11/28 00:55:29 1.11
@@ -15,12 +15,14 @@
import java.io.File;
+import java.io.FileFilter;
import java.io.IOException;
import java.net.URL;
import java.util.Collection;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
+import java.util.ArrayList;
import java.util.Map;
import java.util.TreeSet;
import javax.jms.JMSException;
@@ -43,7 +45,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.10 $
+ * @version$Revision: 1.11 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -159,6 +161,37 @@
}
/**
+* The getDirTree function takes a directory and
+* looks for all subdirectories below it (recursively)
+*
+* Note: Recursive function, REALLY deep queues WILL cause stack fault
+* Note: Possible bug if someone implements an unused queue cleanup
+*and it attempts to remove the parent dir of a deep queue
+*without verifying that it's really just a parent dir
+*
+* @param parent The directory to look in
+*
+* @return The deep list of subdirectories
+*/
+ private final File[] getDirTree(File parent)
+ {
+ final ArrayList dirs = new ArrayList(); //must be final
+ parent.listFiles(new FileFilter()
+ {
+ public final boolean accept(File file)
+ {
+if (file.isDirectory())
+{
+ dirs.add(file); //add to list of all dirs
+ file.listFiles(this);
+}
+return false; //avoid File.listFiles doing extra work
+ }
+ });
+ return (File[])dirs.toArray(new File[dirs.size()]);
+ }
+
+ /**
* The restoreTransactions method is called when the
* PersistenceManager service is started. It reads all transaction log
* files, and pre-restores all messages that are committed and not read.
@@ -170,7 +203,8 @@
private void restoreTransactions() throws javax.jms.JMSException
{
TreeSet txs = new TreeSet();
- File[] transactFiles = dataDirFile.listFiles();
+ File[] transactFiles = getDirTree(dataDirFile);
+ int queueNameOffset = dataDirFile.toString().length()+1;
if(transactFiles != null)
{
for (int i = 0; i < transactFiles.length; i++)
@@ -179,8 +213,7 @@
if( transactFiles[i].isDirectory() )
{
String dirName = transactFiles[i].toString();
- int start = transactFiles[i].getParent().length()+1;
- String key = dirName.substring(start);
+ String key = dirName.substring(queueNameOffset);
[JBoss-dev] CVS update: contrib/tomcat/src/etc/conf/tomcat server.xml.patch
User: starksm Date: 01/11/27 19:53:39 Modified:tomcat/src/etc/conf/tomcat Tag: Branch_2_4 server.xml.patch Log: Update for tomcat-3.2.4 Revision ChangesPath No revision No revision 1.4.2.1 +27 -31contrib/tomcat/src/etc/conf/tomcat/server.xml.patch Index: server.xml.patch === RCS file: /cvsroot/jboss/contrib/tomcat/src/etc/conf/tomcat/server.xml.patch,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- server.xml.patch 2001/06/22 05:49:08 1.4 +++ server.xml.patch 2001/11/28 03:53:39 1.4.2.1 @@ -1,47 +1,43 @@ -*** server.xml Tue Dec 12 13:36:20 2000 server.jboss.xml Thu May 24 09:52:03 2001 +*** server.xml Tue Nov 27 19:52:39 2001 +--- server.jboss.xml Tue Nov 27 19:56:41 2001 *** *** 120,135 + + +! -! + - 120,140 +--- 120,136 + - -+ -! -! -! +! +Insures proper thread context class loader is in effect for servlet execution + + + -+ - *** -*** 176,215 +*** 183,222 className="org.apache.tomcat.request.AccessInterceptor" debug="0" /> @@ -78,18 +74,18 @@ ! userCredCol="user_pass" !userRoleTable="user_roles" ! roleNameCol="role_name" /> -! --> + --> -! -! +! ++ https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: thirdparty/mortbay LICENSE.html
User: jules_gosnell Date: 01/11/27 17:23:00 Added: mortbay LICENSE.html Log: Jetty's license Revision ChangesPath 1.1 thirdparty/mortbay/LICENSE.html Index: LICENSE.html === Jetty License Jetty License $Revision: 1.1 $ Preamble: The intent of this document is to state the conditions under which the Jetty Package may be copied, such that the Copyright Holder maintains some semblance of control over the development of the package, while giving the users of the package the right to use, distribute and make reasonable modifications to the Package in accordance with the goals and ideals of the Open Source concept as described at http://www.opensource.org";>http://www.opensource.org. It is the intent of this license to allow commercial usage of the Jetty package, so long as the source code is distributed or suitable visible credit given or other arrangements made with the copyright holders. Definitions: "Jetty" refers to the collection of Java classes that are distributed as a HTTP server with servlet capabilities and associated utilities. "Package" refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification. "Standard Version" refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder. "Copyright Holder" is whoever is named in the copyright or copyrights for the package. Mort Bay Consulting Pty. Ltd. (Australia) is the "Copyright Holder" for the Jetty package. "You" is you, if you're thinking about copying or distributing this Package. "Reasonable copying fee" is whatever you can justify on the basis of media cost, duplication charges, time of people involved, and so on. (You will not be required to justify it to the Copyright Holder, but only to the computing community at large as a market that must bear the fee.) "Freely Available" means that no fee is charged for the item itself, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it. 0. The Jetty Package is Copyright (c) 1998 Mort Bay Consulting Pty. Ltd. (Australia) and others. Individual files in this package may contain additional copyright notices. The javax.servlet packages are copyright Sun Microsystems Inc. 1. The Standard Version of the Jetty package is available from http://www.mortbay.com>http://www.mortbay.com. 2. You may make and distribute verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you include this license and all of the original copyright notices and associated disclaimers. 3. You may make and distribute verbatim copies of the compiled form of the Standard Version of this Package without restriction, provided that you include this license. 4. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version. 5. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following: a) Place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major archive site such as ftp.uu.net, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package. b) Use the modified Package only within your corporation or organization. c) Rename any non-standard classes so the names do not conflict with standard classes, which must also be provided, and provide a separate manual page for each non-standard class that clearly documents how it differs from the Standard Version. d) Make other arrangements with the Copyright Holder. 6. You may distribute modifications or subsets of this Package in source code or compiled form, provided that you do at least ONE of the following: a) Distribute this license and all original copyright messages, together with instructions (in the about dialog, manual page or equivalent) on where to get the complete Standard Version. b) Accompany the dist
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server QueueManager.java TopicManager.java
User: dbudworth
Date: 01/11/27 16:55:29
Modified:src/main/org/jboss/mq/server QueueManager.java
TopicManager.java
Log:
Added support for deep topic and queue names
Passes run-basic-testsuite, so if something is broken the test needs updating.
TopicManager/QueueManager, uses org.jboss.naming.Util to auto-create subcontexts
PersistenceManager/MessageLog updated to support deep subdirectories in
db/jbossmq/file
Revision ChangesPath
1.6 +4 -2 jbossmq/src/main/org/jboss/mq/server/QueueManager.java
Index: QueueManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/QueueManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- QueueManager.java 2001/11/10 21:38:05 1.5
+++ QueueManager.java 2001/11/28 00:55:29 1.6
@@ -21,13 +21,15 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
+import org.jboss.naming.Util;
+
/**
* This class is a message queue which is stored (hashed by Destination) on the
* JMS provider
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class QueueManager extends ServiceMBeanSupport implements QueueManagerMBean
{
@@ -120,7 +122,7 @@
{
subctx = ctx.createSubcontext("queue");
}
- subctx.rebind(queueName, queue);
+ Util.rebind(subctx,queueName,queue);
}
1.6 +3 -3 jbossmq/src/main/org/jboss/mq/server/TopicManager.java
Index: TopicManager.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/TopicManager.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- TopicManager.java 2001/11/10 21:38:05 1.5
+++ TopicManager.java 2001/11/28 00:55:29 1.6
@@ -22,6 +22,7 @@
import org.jboss.mq.*;
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.mq.DurableSubcriptionID;//Typo!!!
+import org.jboss.naming.Util;
/**
* This class is a message queue which is stored (hashed by Destination) on the
@@ -29,7 +30,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class TopicManager
extends ServiceMBeanSupport
@@ -124,8 +125,7 @@
{
subctx = ctx.createSubcontext("topic");
}
- subctx.rebind(topicName, topic);
-
+ Util.rebind(subctx,topicName,topic);
}
protected void stopService()
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource ConnectionFactoryLoader.java
User: d_jencks
Date: 01/11/27 17:36:08
Modified:src/main/org/jboss/resource ConnectionFactoryLoader.java
Log:
Made jndi binding work on nested subcontexts
Revision ChangesPath
1.16 +5 -21 jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java
Index: ConnectionFactoryLoader.java
===
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/ConnectionFactoryLoader.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- ConnectionFactoryLoader.java 2001/11/26 06:35:12 1.15
+++ ConnectionFactoryLoader.java 2001/11/28 01:36:08 1.16
@@ -45,6 +45,7 @@
import org.jboss.logging.Logger;
import org.jboss.logging.log4j.CategoryWriter;
+import org.jboss.naming.Util;
import org.jboss.resource.security.PrincipalMapping;
import org.jboss.system.ServiceMBeanSupport;
@@ -61,7 +62,7 @@
* @author Toby Allsopp
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @seeRARDeployer
- * @version$Revision: 1.15 $
+ * @version$Revision: 1.16 $
*
* Revisions:
*
@@ -443,12 +444,8 @@
// Private ---
/**
-* Does the actual work of configuring a connection factory. Because this is
-* invoked from a notification handler, it makes no sense to propagate
-* exceptions, so we handle all checked exceptions in the body of this
-* method.
-*
-* @param metaData Description of Parameter
+* Does the actual work of configuring a connection factory.
+* This could now throw exceptions since it is no longer called from a
notification.
*/
private void loadConnectionFactory()
{
@@ -515,8 +512,6 @@
try
{
parseProperties(mcfProps, mcfProperties);
- //mcfProps.load(
- //new ByteArrayInputStream(mcfProperties.getBytes("ISO-8859-1")));
}
catch (IOException ioe)
{
@@ -651,17 +646,6 @@
// Find the connection manager factory
ConnectionManagerFactory cmf;
- /*try
- {
- cmf = (ConnectionManagerFactory)ctx.lookup("java:/" + cmfName);
- }
- catch (Exception e)
- {
- log.error("Unable to find connection manager factory at 'java:/" +
- cmfName + "'", e);
- return;
- }
- */
try
{
cmf = (ConnectionManagerFactory)server.getAttribute(cmfLoaderName,
"ConnectionManagerFactory");
@@ -735,7 +719,7 @@
null));
try
{
- ctx.bind(bindName, cf);
+ Util.bind(ctx, bindName, cf);
log.info("Bound connection factory for resource adapter '" +
resourceAdapterName + "' to JNDI name '" + bindName + "'");
}
___
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 JBossWebApplicationContext.java Jetty.java JettyService.java
User: jules_gosnell
Date: 01/11/27 17:22:25
Modified:jetty/src/main/org/jboss/jetty
JBossWebApplicationContext.java Jetty.java
JettyService.java
Log:
messing around with DebugMBean stuff
trying to get jetty.xml read out of jetty-plugin.sar
...
Revision ChangesPath
1.4 +17 -18
contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java
Index: JBossWebApplicationContext.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JBossWebApplicationContext.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JBossWebApplicationContext.java 2001/11/25 14:52:48 1.3
+++ JBossWebApplicationContext.java 2001/11/28 01:22:25 1.4
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JBossWebApplicationContext.java,v 1.3 2001/11/25 14:52:48 jules_gosnell Exp
$
+// $Id: JBossWebApplicationContext.java,v 1.4 2001/11/28 01:22:25 jules_gosnell Exp
$
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -135,7 +135,6 @@
}
}
-
/**
* return the first JBossSXSecurityHandler, inserting one at the
* beginning of the list, if no other can be found.
@@ -173,31 +172,31 @@
super.initWebXmlElement(element, node);
}
-// public boolean
-// handle(org.mortbay.http.HttpRequest request, org.mortbay.http.HttpResponse
response)
-// throws org.mortbay.http.HttpException, java.io.IOException
-// {
-// Thread.currentThread().setContextClassLoader(getClassLoader());
-// return super.handle(request, response);
-// }
+ // public boolean
+ // handle(org.mortbay.http.HttpRequest request, org.mortbay.http.HttpResponse
response)
+ // throws org.mortbay.http.HttpException, java.io.IOException
+ // {
+ // Thread.currentThread().setContextClassLoader(getClassLoader());
+ // return super.handle(request, response);
+ // }
// hack our class loader to be Java2 compliant - i.e. always
// delegate upwards before looking locally. This will be changed to
// a non-compliant strategy later when JBoss' new ClassLoader is
// ready.
- protected void initClassLoader()
- throws java.net.MalformedURLException, java.io.IOException
- {
- super.initClassLoader();
+ protected void initClassLoader()
+throws java.net.MalformedURLException, java.io.IOException
+{
+ super.initClassLoader();
- ClassLoader _loader=getClassLoader();
- if (_loader instanceof org.mortbay.http.ContextLoader)
+ ClassLoader _loader=getClassLoader();
+ if (_loader instanceof org.mortbay.http.ContextLoader)
((org.mortbay.http.ContextLoader)_loader).setJava2Compliant(true);
- }
+}
- // copy our superclass' version of this, but ensure that servlet
- // api and jasper jars are appended to it...
+ // copy our superclass' version of this, but ensure that servlet
+ // api and jasper jars are appended to it...
public String getFileClassPath()
throws IllegalStateException
1.22 +5 -1 contrib/jetty/src/main/org/jboss/jetty/Jetty.java
Index: Jetty.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/Jetty.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Jetty.java2001/11/26 03:24:53 1.21
+++ Jetty.java2001/11/28 01:22:25 1.22
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: Jetty.java,v 1.21 2001/11/26 03:24:53 starksm Exp $
+// $Id: Jetty.java,v 1.22 2001/11/28 01:22:25 jules_gosnell Exp $
// A Jetty HttpServer with the interface expected by JBoss'
// J2EEDeployer...
@@ -119,9 +119,13 @@
if (configUrl==null)
return;
+_log.info("CONFIG IS: "+configUrl);
+_log.info("CONFIG IS: "+findResourceInJar(configUrl));
+
try
{
_log.info("loading config: "+configUrl);
+ // configure(findResourceInJar(configUrl).toString());
configure(configUrl);
_log.info("loaded config: "+configUrl);
_configuration=configUrl;
1.32 +18 -3 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.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JettyService.java 2001/11/26 23:39:22 1.31
+++ JettyService.java 2001/11/28 01:22:25 1.32
@@ -5,7 +5,7 @@
* See terms of l
[JBoss-dev] CVS update: contrib/jetty TODO build.xml
User: jules_gosnell Date: 01/11/27 17:22:24 Modified:jettyTODO build.xml Log: messing around with DebugMBean stuff trying to get jetty.xml read out of jetty-plugin.sar ... Revision ChangesPath 1.6 +3 -1 contrib/jetty/TODO Index: TODO === RCS file: /cvsroot/jboss/contrib/jetty/TODO,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- TODO 2001/11/25 15:09:44 1.5 +++ TODO 2001/11/28 01:22:24 1.6 @@ -1,7 +1,9 @@ - +Get Jetty to load config from SAR +properly MBeanify Get Jetty Debug MBean running connect EAR CLASSPATH up to Jasper Do we have a problem with JNDI bindings not working ? Get testsuite working/integrate with scoped classloaders. Persistant/Distributed Sessions + 1.12 +6 -1 contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- build.xml 2001/11/21 23:13:00 1.11 +++ build.xml 2001/11/28 01:22:24 1.12 @@ -374,6 +374,9 @@ + + + @@ -413,15 +416,17 @@ /> + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: jules_gosnell Date: 01/11/27 17:22:25 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: messing around with DebugMBean stuff trying to get jetty.xml read out of jetty-plugin.sar ... Revision ChangesPath 1.5 +6 -1 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jboss-service.xml 2001/11/26 23:39:22 1.4 +++ jboss-service.xml 2001/11/28 01:22:25 1.5 @@ -22,14 +22,19 @@ dummy + ../conf/default/jetty.xml ../conf/default/webdefault.xml true true + + name="Jetty:Jetty=Debug2"> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee EJB.java EjbModule.java J2EEApplication.java
User: schaefera
Date: 01/11/27 17:15:08
Modified:src/main/org/jboss/management/j2ee EJB.java EjbModule.java
J2EEApplication.java
Log:
Remove some System.out.println() and print stack traces and replaced
by logging.
Revision ChangesPath
1.3 +6 -3 jboss/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EJB.java 2001/11/28 00:40:32 1.2
+++ EJB.java 2001/11/28 01:15:08 1.3
@@ -10,6 +10,7 @@
import javax.management.MBeanServer;
import javax.management.ObjectName;
+import org.jboss.logging.Logger;
import org.jboss.metadata.BeanMetaData;
import org.jboss.metadata.SessionMetaData;
@@ -18,7 +19,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*
* Revisions:
*
@@ -45,6 +46,7 @@
};
public static ObjectName create( MBeanServer pServer, String pEjbModule,
BeanMetaData pBeanMeta ) {
+ Logger lLog = Logger.getLogger( EJB.class );
try {
int lType =
pBeanMeta.isSession() ?
@@ -65,18 +67,19 @@
).getObjectName();
}
catch( Exception e ) {
-// e.printStackTrace();
+ lLog.error( "Could not create JSR-77 EJB: " + pBeanMeta.getJndiName(), e );
return null;
}
}
public static void destroy( MBeanServer pServer, String pEJBName ) {
+ Logger lLog = Logger.getLogger( EJB.class );
try {
// Now remove the EJB
pServer.unregisterMBean( new ObjectName( pEJBName ) );
}
catch( Exception e ) {
-// e.printStackTrace();
+ lLog.error( "Could not destory JSR-77 EJB: " + pEJBName, e );
}
}
1.6 +12 -16jboss/src/main/org/jboss/management/j2ee/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EjbModule.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EjbModule.java2001/11/28 00:40:32 1.5
+++ EjbModule.java2001/11/28 01:15:08 1.6
@@ -22,12 +22,14 @@
import java.security.InvalidParameterException;
+import org.jboss.logging.Logger;
+
/**
* Root class of the JBoss JSR-77 implementation of
* {@link javax.management.j2ee.EjbModule EjbModule}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*
* Revisions:
*
@@ -51,6 +53,7 @@
// Static
public static ObjectName create( MBeanServer pServer, String pApplicationName,
String pName, URL pURL ) {
+ Logger lLog = Logger.getLogger( EjbModule.class );
String lDD = null;
ObjectName lApplication = null;
try {
@@ -60,7 +63,7 @@
).iterator().next();
String lServerName = lServer.getKeyPropertyList().get( "type" ) + "=" +
lServer.getKeyPropertyList().get( "name" );
- System.out.println( "EjbModule.create(), server name: " + lServerName );
+ lLog.debug( "EjbModule.create(), server name: " + lServerName );
lApplication = (ObjectName) pServer.queryNames(
new ObjectName( J2EEManagedObject.getDomainName() +
":type=J2EEApplication" +
",name=" + pApplicationName + "," + lServerName + ",*"
@@ -71,11 +74,13 @@
lDD = J2EEDeployedObject.getDeploymentDescriptor( pURL,
J2EEDeployedObject.EJB );
}
catch( Exception e ) {
- e.printStackTrace();
+ lLog.error( "Could not create JSR-77 EjbModule: " + pApplicationName, e );
+ return null;
}
try {
// Now create the J2EEApplication
- System.out.println( "Create EJB-Module, name: " + pName +
+ lLog.debug(
+"Create EJB-Module, name: " + pName +
", application: " + lApplication +
", dd: " + lDD
);
@@ -95,28 +100,19 @@
).getObjectName();
}
catch( Exception e ) {
- e.printStackTrace();
+ lLog.error( "Could not create JSR-77 EjbModule: " + pApplicationName, e );
return null;
}
}
public static void destroy( MBeanServer pServer, String pModuleName ) {
+ Logger lLog = Logger.getLogger( EjbModule.class );
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb ContainerFactory.java
User: schaefera
Date: 01/11/27 17:15:08
Modified:src/main/org/jboss/ejb ContainerFactory.java
Log:
Remove some System.out.println() and print stack traces and replaced
by logging.
Revision ChangesPath
1.102 +1 -2 jboss/src/main/org/jboss/ejb/ContainerFactory.java
Index: ContainerFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/ContainerFactory.java,v
retrieving revision 1.101
retrieving revision 1.102
diff -u -r1.101 -r1.102
--- ContainerFactory.java 2001/11/28 00:40:31 1.101
+++ ContainerFactory.java 2001/11/28 01:15:08 1.102
@@ -70,7 +70,7 @@
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
-* @version $Revision: 1.101 $
+* @version $Revision: 1.102 $
*/
public class ContainerFactory
extends ServiceMBeanSupport
@@ -399,7 +399,6 @@
getServer(),
pParentId,
lName,
-// pAppId,
url
);
if( lModule != null ) {
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/management/j2ee EJB.java EjbModule.java
User: schaefera
Date: 01/11/27 16:40:32
Modified:src/main/org/jboss/management/j2ee EJB.java EjbModule.java
Log:
Fix for a problem with a NPE.
Revision ChangesPath
1.2 +3 -3 jboss/src/main/org/jboss/management/j2ee/EJB.java
Index: EJB.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EJB.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EJB.java 2001/11/27 06:15:26 1.1
+++ EJB.java 2001/11/28 00:40:32 1.2
@@ -18,7 +18,7 @@
* {@link javax.management.j2ee.EJB EJB}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* Revisions:
*
@@ -65,7 +65,7 @@
).getObjectName();
}
catch( Exception e ) {
- e.printStackTrace();
+// e.printStackTrace();
return null;
}
}
@@ -76,7 +76,7 @@
pServer.unregisterMBean( new ObjectName( pEJBName ) );
}
catch( Exception e ) {
- e.printStackTrace();
+// e.printStackTrace();
}
}
1.5 +5 -1 jboss/src/main/org/jboss/management/j2ee/EjbModule.java
Index: EjbModule.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/management/j2ee/EjbModule.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EjbModule.java2001/11/27 06:15:26 1.4
+++ EjbModule.java2001/11/28 00:40:32 1.5
@@ -27,7 +27,7 @@
* {@link javax.management.j2ee.EjbModule EjbModule}.
*
* @author mailto:[EMAIL PROTECTED]";>Andreas Schaefer.
- * @version $Revision: 1.4 $
+ * @version $Revision: 1.5 $
*
* Revisions:
*
@@ -75,6 +75,10 @@
}
try {
// Now create the J2EEApplication
+ System.out.println( "Create EJB-Module, name: " + pName +
+", application: " + lApplication +
+", dd: " + lDD
+ );
return pServer.createMBean(
"org.jboss.management.j2ee.EjbModule",
null,
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb ContainerFactory.java
User: schaefera
Date: 01/11/27 16:40:31
Modified:src/main/org/jboss/ejb ContainerFactory.java
Log:
Fix for a problem with a NPE.
Revision ChangesPath
1.101 +15 -6 jboss/src/main/org/jboss/ejb/ContainerFactory.java
Index: ContainerFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/ContainerFactory.java,v
retrieving revision 1.100
retrieving revision 1.101
diff -u -r1.100 -r1.101
--- ContainerFactory.java 2001/11/27 06:15:26 1.100
+++ ContainerFactory.java 2001/11/28 00:40:31 1.101
@@ -70,7 +70,7 @@
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
-* @version $Revision: 1.100 $
+* @version $Revision: 1.101 $
*/
public class ContainerFactory
extends ServiceMBeanSupport
@@ -391,13 +391,20 @@
throws NamingException, Exception
{
// Create JSR-77 EJB-Module
- String lModule = EjbModule.create(
+ int i = app.getName().lastIndexOf( "/" );
+ String lName = app.getName().substring(
+ i >= 0 ? i + 1 : 0
+ );
+ ObjectName lModule = EjbModule.create(
getServer(),
pParentId,
- pAppId,
+ lName,
+// pAppId,
url
- ).toString();
- app.setModuleName( lModule );
+ );
+ if( lModule != null ) {
+ app.setModuleName( lModule.toString() );
+ }
// Create a file loader with which to load the files
XmlFileLoader efm = new XmlFileLoader(validateDTDs);
@@ -495,7 +502,9 @@
// Remove deployment
deployments.remove( url );
// Remove JSR-77 Module
- EjbModule.destroy( getServer(), app.getModuleName() );
+ if( app.getModuleName() != null ) {
+EjbModule.destroy( getServer(), app.getModuleName() );
+ }
// Done
log.info( "Undeployed application: " + app.getName() );
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: on the use of final
There are like five hundred rules on that page. What is it specifically
flagging as a bad practice? I am actually interested.
-dain
> -Original Message-
> From: Weir, John [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 27, 2001 5:43 PM
> To: Jboss-Development@Lists. Sourceforge. Net
> Subject: RE: [JBoss-dev] Re: on the use of final
>
>
> We use JTest from parasoft for static analysis. It usually
> flags up these
> sort of errors. The reasoning behind their rules can be found at:
>
> http://www.parasoft.com/products/jtest/manuals/v4_1/r_index.ht
> m#1001102 -
> Scan to correct section
>
> John
> -Original Message-
> From: Jason Dillon [mailto:[EMAIL PROTECTED]]
> Sent: 23 November 2001 20:32
> To: marc fleury
> Cc: Jboss-Development@Lists. Sourceforge. Net
> Subject: [JBoss-dev] Re: on the use of final
>
>
> > My question though is "is it worth it?" what are the
> advantages of using
> > final as opposed to not using final and not worrying about
> the mutability
> of
> > it?
> >
> > speed gain?
>
> Depends on where final is used. For final as a method
> attribute modifier
> there is no speed increase, it is just an engineering tool to
> prevent the
> value from being modified. It is common to use final for
> constructors. For
>
> example:
>
>class MyClass
>{
> int foo;
>
> MyClass(int foo) {
> foo = foo;
> }
>}
>
> This is an error, but will compile and execute. To avoid
> this type of bug,
> mark method attributes which should not change as final:
>
>class MyClass
>{
> int foo;
>
> MyClass(final int foo) {
> foo = foo; // COMPILE ERROR
> }
>}
>
> Final on a method, could cause a speed increase, allowing the
> compiler to
> inline the method. From what I remember, the HotSpot VM
> folks at JavaOne
> said that this will have little or no effect due to new
> compiler techniques.
>
> * * *
>
> Which usage of final are you refering too?
>
> --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
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy AbstractVerifier.java
User: juhalindfors
Date: 01/11/27 16:27:14
Modified:src/main/org/jboss/verifier/strategy AbstractVerifier.java
Log:
Revision ChangesPath
1.24 +9 -4 jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java
Index: AbstractVerifier.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/AbstractVerifier.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- AbstractVerifier.java 2001/11/02 06:07:48 1.23
+++ AbstractVerifier.java 2001/11/28 00:27:14 1.24
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: AbstractVerifier.java,v 1.23 2001/11/02 06:07:48 schaefera Exp $
+ * $Id: AbstractVerifier.java,v 1.24 2001/11/28 00:27:14 juhalindfors Exp $
*/
// standard imports
@@ -70,7 +70,7 @@
*
*
*
- * @version $Revision: 1.23 $
+ * @version $Revision: 1.24 $
* @sinceJDK 1.3
*/
public abstract class AbstractVerifier implements VerificationStrategy {
@@ -979,8 +979,13 @@
if (Error.class.isAssignableFrom(type))
return false;
-if (RuntimeException.class.isAssignableFrom(type))
-return false;
+// 28.3.4.4 (6) java.rmi.RemoteException and its subclasses, and unchecked
+// exception classes, are assumed to be mapped to the implicit
+// CORBA system exception, and are therefore not explicitly
+// declared in OMG IDL.
+//
+//if (RuntimeException.class.isAssignableFrom(type))
+//return false;
if (!isRMIIDLValueType(type))
return false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] javax.management.InstanceAlreadyExistsException...
Andy, I have just updated and built from clean. Upon running the WebIntegration testsuite, I immediately get : 23:48:58,218 INFO [Default] EjbModule.create(), server name: J2EEServer=Single 23:48:58,219 INFO [Default] File: file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/Default/jbosstest-web.ear/ejb1005.jar, descriptor: META-INF/ejb-jar.xml 23:48:58,243 INFO [Default] J2EEManagedObject.getObjectName(), name: SingleJBoss:name=jbosstest-web.ear,J2EEServer=Single,J2EEApplication=jbosstest-web.ear,type=EJBModule,J2EEManagement=Manager 23:48:58,244 INFO [Default] J2EEManagedObject.postRegister(), parent: SingleJBoss:J2EEServer=Single,name=jbosstest-web.ear,type=J2EEApplication,J2EEManagement=Manager 23:48:58,261 ERROR [Default] javax.management.InstanceAlreadyExistsException: SingleJBoss:name=jbosstest-web.ear,J2EEServer=Single,J2EEApplication=jbosstest-web.ear,type=EJBModule,J2EEManagement=Manager 23:48:58,261 ERROR [Default] at com.sun.management.jmx.RepositorySupport.addMBean(RepositorySupport.java:134) 23:48:58,264 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.internal_addObject(MBeanServerImpl.java:2352) 23:48:58,264 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.createMBean(MBeanServerImpl.java:641) 23:48:58,264 ERROR [Default] at org.jboss.management.j2ee.EjbModule.create(EjbModule.java:78) 23:48:58,264 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:394) 23:48:58,265 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:368) 23:48:58,265 ERROR [Default] at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:299) 23:48:58,265 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,265 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 23:48:58,265 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 23:48:58,265 ERROR [Default] at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:516) 23:48:58,266 ERROR [Default] at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:490) 23:48:58,266 ERROR [Default] at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:222) 23:48:58,266 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,266 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) 23:48:58,266 ERROR [Default] at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) 23:48:58,266 ERROR [Default] at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:283) 23:48:58,267 ERROR [Default] at java.lang.reflect.Method.invoke(Native Method) 23:48:58,267 ERROR [Default] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 23:48:58,267 ERROR [Default] at sun.rmi.transport.Transport$1.run(Transport.java:152) 23:48:58,267 ERROR [Default] at java.security.AccessController.doPrivileged(Native Method) 23:48:58,267 ERROR [Default] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 23:48:58,267 ERROR [Default] at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) 23:48:58,267 ERROR [Default] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:706) 23:48:58,268 ERROR [Default] at java.lang.Thread.run(Thread.java:484) 23:48:58,285 ERROR [ContainerFactory] Could not deploy file:/mnt/pteranodon/home/jules/cvs/JBoss/3.0/build/output/jboss-3.0.0alpha/deploy/Default/jbosstest-web.ear Sorry ! Jules Andreas Schaefer wrote: > Hi > > Yes, this is my mistake. I toke the wrong name, instead the name of > the JAR file the name of the EAR application. Will fix it now. > > Andy > > - Original Message - > From: "Julian Gosnell" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 27, 2001 2:12 AM > Subject: [JBoss-dev] javax.management.InstanceAlreadyExistsException... > > > On running the WebIntegration test on a freshly built > > Server (cvs updated about 12 hours ago) I get a : > > > > javax.management.InstanceAlreadyExistsException: > > SingleJBoss:name=jbosstest-web.ear, J2EEServer=Single, > > J2EEApplication=jbosstest-web.ear, type=EJBModule, > > J2EEManagement=Manager, > > from JMX. > > > > The last JBoss stackframe was : > > > > org.jboss.management.j2ee.EJBModule.create() - > > EJBModule.java - line 78. > > > > I would send the whole stack - but I'm not on my > > development box, > > > > Apologies if this has already been sorted. > > > > > > Jules > > > > > > __ > > Do You Yahoo!? > > Everything you'll ever need on one web page from News and Sport to Email > and Music Charts > > http://uk.my.yahoo.com > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > >
RE: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Anatoly Akkerman |Sent: Tuesday, November 27, 2001 4:37 PM |To: David Jencks |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl |to get just one dd? | | |> |> Can Castor merge nested attributes from all the files into one |object? For |> instance, there are elements under ejb-jar/enterprise-beans/entity and |> jboss-cmp/enterprise-beans/entity that should all end up in |> result-dd/enterprise-beans/entity. | |Not that I know of. Doing XSLT, would, probably be the best way for such |processing. Castor can only instantiate a new object tree that represents |a given XML file. It cannot 'update' an existing tree from this |'incremental' unmarshalling. In general it is an impossible task. Think |about it. Castor (or any other software) would have to know which pieces |match where. Say, in the case of ejb descriptors, it would not be enough |to match and from ejb-jar.xml with |from jboss.xml. You would have to match _names_ and whatever else to make |sure you are updating descriptor object for the right entity bean. This |already is _semantic_ interpretation of what stands behind the data in the |XML file. You can only write a custom combiner that would take 3 object |trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a |combined tree, matching appripriate descriptors by hand. david, you and I should take a page from anatoly's book this is what I call "complex stuff explained in layman terms" I almost understood it all at once :) you are going to write a great phd anatoly, you are going to be a "real" doctor one day, David, in my office, right this minute ;-) marcf | |Actually, I don't know if XSLT will to that for you, it also does not know |anything about the semantics of the XML files you are combining. It seems |to me, this must be a custom combining solution. | |Anatoly. | |> |> Just having copies of all 3 docs in the super-jboss is probably |easier with |> including an xml entity;-) |> |> david jencks |> | | | | |___ |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] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 6:33 PM |To: marc fleury |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi Geeks | |We are maybe still discussing the wrong issue. I had a |look at the ZipFile and JarFile classes and they don't |allow you to open an archive inside an archive. true, more of that packaging madness, THE STANDARD PACKAGING OF J2EE IS A BROWN SMELLY CYLINDER. Anyway we got to eat it... |Therefore for most of the files except the JAR file |(EAR, WAR, RAR and SAR) we have to inflate the |archive anyhow. |Now with the old trick of various directories or numbering |the files we can go around the lock. that is correct. |When Rickard can implement a lock-free URLCL then |we don't have to create subclasses and can reuse the |files (right now I can grow and grow until the server is |bounced) and that would be valueable. yes and the trick will also enable to not have to renumber the jar and wars so we can have a more fine grained deployment with the actual names and you get to keep (andreas) your JSR77 requirements of keeping track. good call andy, our bad marcf | |Andy | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
That is correct and my objection, however andreas pointed out that I was arguing an irrelevant point anyhow, I will forward his email marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Jencks |Sent: Tuesday, November 27, 2001 6:44 PM |To: Rickard Oberg |Cc: marc fleury; Andreas Schaefer; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: |> marc fleury wrote: |> |> > ok one of us doesn't get it, if you are "open most of the time" how do |> you |> > release the lock in the filesystem for anyone to overwrite the file ? |> I |> > could be missing it :) |> |> |> 1. URLCL wants to access "custom://somejar.jar" |> 2. It uses CustomURLHandler to get a connection to somejar.jar. This |> connection is put in cache and is never let go of. |> 3. The connection retrieved from CustomURLHandler is not a real |> connection, but merely a wrapper to a file connection. Similar to how a |> connection pool provides implementations of Connection that are only |> wrappers for real connections that can be managed by the pool. |> 4. Operations on the connection are passed on to the file connection. |> 5. When redeploy of a JAR is to be done, the wrapper is told to close |> its underlying connection |> 6. At this point there are no open connections to the JAR, so it can be |> replaced with a new file or removed. |> 7. At some point the connection wrapper is called, either by the old |> URLCL or a new one using the same connection. The file connection is |> then re-acquired, only now to the new file. |> |> See? | |So this requires an explicit undeploy of the old jar: it cannot work via an |autodeployer watching for changed timestamps, because you have to undeploy |the file first before you can change it. You sure this is better than |copying? | |david jencks |> |> /Rickard |> |> |> -- |> Rickard Öberg |> |> |> |> ___ |> 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Nevermind, problem fixed. I just changed how it finds the directories on restoreTransactions(), and made it ignore them in MessageLog.restore() I'll commit after some testing. -David On Tue, 27 Nov 2001, David Jencks wrote: > On 2001.11.27 17:21:31 -0500 David Budworth wrote: > > So, why do we pre-restore the message queues? And not just restore them > > when a queue deploys? > > > > It seems to be a waste of memory to load an entire queue 'just in case' > > it gets deployed. > > > > Is there any reason why I couldn't just move the code from > > restoreTransactions() (which is called only by startService()) to > > restoreDestination() which currently seems to just take the messages out > > of the cache created by restoreTransactions(). > > Maybe you can make it work. I didn't see any way to, and I couldn't figure > out any way to test it either. So I tried to change it as little as > possible. You will definitely have to keep track of the recovered > transaction info until all queues are restored: detecting this may me > another trick. I thought it was way simpler to process it all at once when > the pm started. Why is this causing you problems? I don't see the > connection to the namespace issues. > > david jencks > > > > -david > > > > On Tue, 27 Nov 2001, David Jencks wrote: > > > > > On 2001.11.27 15:55:06 -0500 David Budworth wrote: > > > > Does anyone know if it's actually legal for JMS topics/queues to have > > > > structure? > > > > > > > > I was making the change for binding subcontexts automatically (using > > > > org.jboss.naming.Util). And it deploys fine. > > > > > > > > But, if I kill jboss and restart it (without my sar that defines the > > > > queue in deploy), it throws exceptions because it finds a directory > > in > > > > the db/messaging/QUEUE.mycompany/myqueue > > > > > > > > The queue was "mycompany/myqueue", which was created correctly as > > > > db/messaging/QUEUE.mycompany/myqueue/ > > > > > > > > I can only assume that the queue restoration only looks one level > > deep. > > > > And attempts to restore a queue (even though the queue is not in any > > DD > > > > anymore) > > > > > > > > I'm just trying to understand what all should be fixed. > > > > > > > > So, questions of the day are : > > > > > > > > 1) Can a queuename have depth? > > > > 2) Should all queues be restored at jboss startup regardless of if > > they > > > > are needed anymore? > > > > 2a) Or when the MBEAN descriptor is located? > > > > > > The startup is in 2 phases. When the pm is started, it "pre-restores" > > all > > > the queues it can find, figures out which messages weren't committed > > (btw > > > I'm not convinced it handles "prepared but not committed" properly), > > and > > > makes lists of undelivered messages. Then when each queue starts, it > > > registers with the pm and gets its list of messages. For topics, if I > > > remember correctly, the queue representing the topic asks the > > StateManager > > > for all the subscriber queues and restores each one individually. > > > > > > In regards to (2), there is no way to tell if a queue is needed > > anymore. > > > The mbeans for the queues are not necessarily in the same file as the > > mbean > > > for the pm, and could be deployed hours or days later. On the other > > hand, > > > the cleanup of uncommitted messages should happen as soon as the pm is > > > started, so you don't need to keep dead data around indefinitely. > > > > > > david jencks > > > > > > > > -David > > > > > > > > > > ___ > > > 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] Re: on the use of final
We use JTest from parasoft for static analysis. It usually flags up these
sort of errors. The reasoning behind their rules can be found at:
http://www.parasoft.com/products/jtest/manuals/v4_1/r_index.htm#1001102 -
Scan to correct section
John
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: 23 November 2001 20:32
To: marc fleury
Cc: Jboss-Development@Lists. Sourceforge. Net
Subject: [JBoss-dev] Re: on the use of final
> My question though is "is it worth it?" what are the advantages of using
> final as opposed to not using final and not worrying about the mutability
of
> it?
>
> speed gain?
Depends on where final is used. For final as a method attribute modifier
there is no speed increase, it is just an engineering tool to prevent the
value from being modified. It is common to use final for constructors. For
example:
class MyClass
{
int foo;
MyClass(int foo) {
foo = foo;
}
}
This is an error, but will compile and execute. To avoid this type of bug,
mark method attributes which should not change as final:
class MyClass
{
int foo;
MyClass(final int foo) {
foo = foo; // COMPILE ERROR
}
}
Final on a method, could cause a speed increase, allowing the compiler to
inline the method. From what I remember, the HotSpot VM folks at JavaOne
said that this will have little or no effect due to new compiler techniques.
* * *
Which usage of final are you refering too?
--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] NPE when using DefaultDS
While pooking around i found and : Uncommented body of deleteObject(pooledObject) - line 71 of org/jboss/resource/connectionmanager.ManagedConnectionPoolFactory.java (it seems this is called when the pool shrinks or is shut down. some test -is shrinking the pool to [0/0/10] and as a effect the next test using the DefaultDS do not have a connection ? ... it should probably create one before trying to create a table ? ...) *** Now when running run-testsuite I have 169 tests running and 1 error 99.41% Success rate - heh ... So the xa test is failing above - We knew that - and disabeling it should render a cool 100% of the 169 tests ! ... /peter_f on 1-11-26 22.54, David Maplesden at [EMAIL PROTECTED] wrote: > I have been experiencing a NPE when calling createStatement on a connection > obtained from DefaultDS. > > java.lang.NullPointerException > at > org.jboss.resource.adapter.jdbc.local.StatementInPool.(StatementInPool > .java:35) > at > org.jboss.resource.adapter.jdbc.local.ConnectionInPool.createStatement(Conne > ctionInPool.java:606) > > This doesn't always occur and I have only noticed it in the last week or so, > previously it worked fine. > > It occurs after a previous statement throws an SQLException. In other words > if you are using the connections from DefaultDS everything is fine until one > of your SQL queries causes an SQL exception. After this point you get a NPE > every time you try to create another statement from a connection for > DefaultDS. > > I think (though I don't know for sure) that it has been caused by a change > to the Object pool code made last week sometime. > > I hope someone out there can help. > > Thanks > David. > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.298 / Virus Database: 161 - Release Date: 11/13/2001 > > > ___ > 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] Installer / Deployer Problem
On 2001.11.27 17:23:32 -0500 Rickard Oberg wrote: > marc fleury wrote: > > > ok one of us doesn't get it, if you are "open most of the time" how do > you > > release the lock in the filesystem for anyone to overwrite the file ? > I > > could be missing it :) > > > 1. URLCL wants to access "custom://somejar.jar" > 2. It uses CustomURLHandler to get a connection to somejar.jar. This > connection is put in cache and is never let go of. > 3. The connection retrieved from CustomURLHandler is not a real > connection, but merely a wrapper to a file connection. Similar to how a > connection pool provides implementations of Connection that are only > wrappers for real connections that can be managed by the pool. > 4. Operations on the connection are passed on to the file connection. > 5. When redeploy of a JAR is to be done, the wrapper is told to close > its underlying connection > 6. At this point there are no open connections to the JAR, so it can be > replaced with a new file or removed. > 7. At some point the connection wrapper is called, either by the old > URLCL or a new one using the same connection. The file connection is > then re-acquired, only now to the new file. > > See? So this requires an explicit undeploy of the old jar: it cannot work via an autodeployer watching for changed timestamps, because you have to undeploy the file first before you can change it. You sure this is better than copying? david jencks > > /Rickard > > > -- > Rickard Öberg > > > > ___ > 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] JMS issues re: stopservice, jndi names
On 2001.11.27 17:21:31 -0500 David Budworth wrote: > So, why do we pre-restore the message queues? And not just restore them > when a queue deploys? > > It seems to be a waste of memory to load an entire queue 'just in case' > it gets deployed. > > Is there any reason why I couldn't just move the code from > restoreTransactions() (which is called only by startService()) to > restoreDestination() which currently seems to just take the messages out > of the cache created by restoreTransactions(). Maybe you can make it work. I didn't see any way to, and I couldn't figure out any way to test it either. So I tried to change it as little as possible. You will definitely have to keep track of the recovered transaction info until all queues are restored: detecting this may me another trick. I thought it was way simpler to process it all at once when the pm started. Why is this causing you problems? I don't see the connection to the namespace issues. david jencks > > -david > > On Tue, 27 Nov 2001, David Jencks wrote: > > > On 2001.11.27 15:55:06 -0500 David Budworth wrote: > > > Does anyone know if it's actually legal for JMS topics/queues to have > > > structure? > > > > > > I was making the change for binding subcontexts automatically (using > > > org.jboss.naming.Util). And it deploys fine. > > > > > > But, if I kill jboss and restart it (without my sar that defines the > > > queue in deploy), it throws exceptions because it finds a directory > in > > > the db/messaging/QUEUE.mycompany/myqueue > > > > > > The queue was "mycompany/myqueue", which was created correctly as > > > db/messaging/QUEUE.mycompany/myqueue/ > > > > > > I can only assume that the queue restoration only looks one level > deep. > > > And attempts to restore a queue (even though the queue is not in any > DD > > > anymore) > > > > > > I'm just trying to understand what all should be fixed. > > > > > > So, questions of the day are : > > > > > > 1) Can a queuename have depth? > > > 2) Should all queues be restored at jboss startup regardless of if > they > > > are needed anymore? > > > 2a) Or when the MBEAN descriptor is located? > > > > The startup is in 2 phases. When the pm is started, it "pre-restores" > all > > the queues it can find, figures out which messages weren't committed > (btw > > I'm not convinced it handles "prepared but not committed" properly), > and > > makes lists of undelivered messages. Then when each queue starts, it > > registers with the pm and gets its list of messages. For topics, if I > > remember correctly, the queue representing the topic asks the > StateManager > > for all the subscriber queues and restores each one individually. > > > > In regards to (2), there is no way to tell if a queue is needed > anymore. > > The mbeans for the queues are not necessarily in the same file as the > mbean > > for the pm, and could be deployed hours or days later. On the other > hand, > > the cleanup of uncommitted messages should happen as soon as the pm is > > started, so you don't need to keep dead data around indefinitely. > > > > david jencks > > > > > > -David > > > > > > > ___ > > 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] Installer / Deployer Problem
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Rickard Oberg |Sent: Tuesday, November 27, 2001 5:24 PM |To: marc fleury |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |marc fleury wrote: | |> ok one of us doesn't get it, if you are "open most of the time" |how do you |> release the lock in the filesystem for anyone to overwrite the file ? I |> could be missing it :) | I understand what you proposed what I don't understand is the above, see below :) |1. URLCL wants to access "custom://somejar.jar" |2. It uses CustomURLHandler to get a connection to somejar.jar. This |connection is put in cache and is never let go of. |3. The connection retrieved from CustomURLHandler is not a real |connection, but merely a wrapper to a file connection. Similar to how a |connection pool provides implementations of Connection that are only |wrappers for real connections that can be managed by the pool. |4. Operations on the connection are passed on to the file connection. |5. When redeploy of a JAR is to be done, the wrapper is told to close |its underlying connection Question: can you overwrite the jar if the vm holds a open connection to it and thus a lock to it in windows (file in usage)? If no which is my assumption for this discussion then you don't know when ANT is going to replace that file from JBoss, or when the user wants to drag and drop, it is an asynchronous operation that happens without your knowledge (won't happen in this case) |6. At this point there are no open connections to the JAR, so it can be |replaced with a new file or removed. no see above, you don't know *when* someone is going to replace the file so you can't be "open most of the time". Do we agree here? |7. At some point the connection wrapper is called, either by the old |URLCL or a new one using the same connection. The file connection is |then re-acquired, only now to the new file. sure |See? almost, some googoo on my glasses still (or is it yours?) marcf | |/Rickard | | |-- |Rickard Öberg | | | |___ |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] Question regarding federated JNDI namespaces
Hello there. I am working with JBoss 3.0 and was hoping that somebody could answer a question for me regarding federated JNDI namespaces. Essentially, I am looking at using JBoss as a services framework and, if a J2EE application server is already in use (e.g., Weblogic or Websphere), sharing the JNDI namespace of the application server with JBoss via the ExternalContext MBean. I am not sure that I am using the right approach and was hoping that someone could help set me straight if I am mistaken, or direct me to where I can get answers on how to make this work. I first went into the jboss-service.xml file and, after the JNDIView MBean entry, added the following: external/beaWebLogic beaWebLogicProperties javax.naming.InitialContext For the beaWebLogicProperties file, I provided the following two entries: java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory java.naming.provider.url=t3://localhost:7001 Does JBoss allow you to create federated namespaces with only ldap or the file system, or does it allow you to share namespaces across application servers? If the answer is yes, and the above is correct, should I be doing something on the side of the application server itself that I am unaware of? Any help would be greatly appreciated. Thank you. Craig M. Parsons-Kerins LEXIGN Craig M. Parsons-Kerins Senior Software Engineer, Engineering Development 22 COTTON ROAD * NASHUA, NH * 03063 T 603.883.3800 x335 F 603.889.9259 mailto:[EMAIL PROTECTED] http://www.lexign.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] (rh)Possible consistency problem in jbosscmp-jdbc.dtd?
> I'm wondering what the intent behind the eager-load and > lazy-load-group is. > > I would think that you would want to partition the cmp-fields into one > eager-load and 0 or more lazy-load groups. Is this correct? > > If so, the current xml structure makes it pretty easy to > include fields > into many of these groups. Is this intentional? What should > happen in this > case? This is intentional. An example is easier to explain. Let's say we have a product ejb with the following lazy load groups: pricing info unit costPerUnit weight shipping info length girth weight If you access unit or costPerUnit, and it is unloaded, you get unit, costPerUnit and weight. If you first access Wight you, all of the above fields will be loaded. This allows you to have different groups with the same data. In the future I want each query to be able to have a different eager load group. I have been thinking that maybe, better to specify all groups. Then entity would have a eager-load with just a group named and the lazy-load-groups would have many names. The real reason for the change would be to add an eager-load element to the query element. Oh, eager/lazy loading of relationship foreign key fields is on my todo list. I have not decided how to structure this yet. What do you think? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 16:32:05 -0500 David Budworth wrote: > Sorry to follow up my own message, but I need another question answered. > > Note: In the previous message, I was incorrectly saying db/messaging, > it's > really db/jbossmq/file > > Is it possible to have queues named: > > companyA > companyA/myqueue1 > companyA/myqueue2 > > I'm changing (in anticipation that deep queues are valid), the file pm > for queues. It currently just get's a list of all files in > db/jbossmq/file/ > > Then attempts to restore the MessageLogs for each file in that list. > > When MessageLog attempts to restore, it just looks for a "." in the name > (ie: QUEUE.bob), and restores all messages files in that dir, if no "." > is > there it assumes the file is a message log and attempts to restore it > directly, which is why my stuff is failing, because it looks like > QUEUE.companyA/myqueue1/* > But the restoration code assumes "myqueue1" is a file, and not a subdir > (because no ".") > > It seems to me, that a much easier fix is to not restore the queue on > startup, but instead restore in when the DD is deployed. > > But I suppose there may be a need to restore a queue before it's > actually defined? > > The auto-restored queues doesn't show up in the 8082 UI (BTW what's that > called?). So I am not sure why the PM is creating an instance of > MessageLog for them at startup. > > Am I just not getting it? You need to read in all the info pertaining to a particular pm when the pm is started so you can figure out what to do with incomplete transactions. Is there some way you can improve the naming conventions to make your nested queue names work without modifying the rest of the startup code? david jencks > > -David > > > On Tue, 27 Nov 2001, David Budworth wrote: > > > Does anyone know if it's actually legal for JMS topics/queues to have > > structure? > > > > I was making the change for binding subcontexts automatically (using > > org.jboss.naming.Util). And it deploys fine. > > > > But, if I kill jboss and restart it (without my sar that defines the > > queue in deploy), it throws exceptions because it finds a directory in > > the db/messaging/QUEUE.mycompany/myqueue > > > > The queue was "mycompany/myqueue", which was created correctly as > > db/messaging/QUEUE.mycompany/myqueue/ > > > > I can only assume that the queue restoration only looks one level deep. > > And attempts to restore a queue (even though the queue is not in any DD > > anymore) > > > > I'm just trying to understand what all should be fixed. > > > > So, questions of the day are : > > > > 1) Can a queuename have depth? > > 2) Should all queues be restored at jboss startup regardless of if they > > are needed anymore? > > 2a) Or when the MBEAN descriptor is located? > > > > -David > > > > > > On Tue, 27 Nov 2001, Hiram Chirino wrote: > > > > > >From: David Jencks <[EMAIL PROTECTED]> > > > >To: [EMAIL PROTECTED] > > > >Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names > > > >Date: Mon, 26 Nov 2001 23:26:02 -0500 > > > > > > > >On 2001.11.26 22:50:55 -0500 David Budworth wrote: > > > >> Hi all, > > > >> > > > >> There are two things bugging me right now in JMS, and I just > wanted to > > > >> know if anyone is working on them, or if they need to be fixed at > all. > > > >> > > > >> The first one, is pretty obviously a 'needs-to-be-done'. You > can't > > > >> current undeploy a queue/topic. > > > >> > > > >> In my sar, I define the JMS queues that the services use, and when > I > > > >> undeploy the .sar, the log says "queue stop not yet implemented". > > > >> > > > >> The problem this causes is that once you delete the SAR, the queue > name > > > >> disappears from the 8082 UI, but, if you attempt to re-deploy the > SAR, > > > >> or just create the queue via the 8082 UI, you'll get a an error > stating > > > >> the topic/queue already exists. > > > >> > > > >> So it seems that on undeploy, the internal stuctures of JBossMQ > gets > > > >> fux0r3d (in script-kiddie speak). > > > >> > > > >> I'd be happy to work on this (since I need it). I just didn't > know if > > > >> anyone else was already doing it. Nor do I really know where to > start > > > >> on it. > > > >> > > > > > > > >I'm not the most expert... but I think the queue stop method needs > to > > > >arrange with the JMSService to stop accepting messages and possibly > with > > > >the persistence manager to make sure everything is stably saved that > should > > > >be. Make sure all open transactions are ended before shutting down! > > > > > > Sounds about right. > > > > > > >> > > > >> > > > >> The second one is just something that bothers me, which is if you > > > >> specify a queue name like: > > > >> mycompany/queuea > > > >> > > > >> You will get a name not bound exception on "mycompany". For EJBs > this > > > >> works correctly, where the subcontexts are created on the fly as > need > > > >> be. But for JMS it doesn't. > > > >> > > > >> I'd also like to
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
The JMS spec has nothing to say about JNDI namespace conventions for administered objects, so add support for this. There is an assumption of a flat namespace under queue and topic that needs to be generalized. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Budworth" <[EMAIL PROTECTED]> To: "Hiram Chirino" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 12:55 PM Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names > Does anyone know if it's actually legal for JMS topics/queues to have > structure? > > I was making the change for binding subcontexts automatically (using > org.jboss.naming.Util). And it deploys fine. > > But, if I kill jboss and restart it (without my sar that defines the > queue in deploy), it throws exceptions because it finds a directory in > the db/messaging/QUEUE.mycompany/myqueue > > The queue was "mycompany/myqueue", which was created correctly as > db/messaging/QUEUE.mycompany/myqueue/ > > I can only assume that the queue restoration only looks one level deep. > And attempts to restore a queue (even though the queue is not in any DD > anymore) > > I'm just trying to understand what all should be fixed. > > So, questions of the day are : > > 1) Can a queuename have depth? > 2) Should all queues be restored at jboss startup regardless of if they > are needed anymore? > 2a) Or when the MBEAN descriptor is located? > > -David > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
So, why do we pre-restore the message queues? And not just restore them when a queue deploys? It seems to be a waste of memory to load an entire queue 'just in case' it gets deployed. Is there any reason why I couldn't just move the code from restoreTransactions() (which is called only by startService()) to restoreDestination() which currently seems to just take the messages out of the cache created by restoreTransactions(). -david On Tue, 27 Nov 2001, David Jencks wrote: > On 2001.11.27 15:55:06 -0500 David Budworth wrote: > > Does anyone know if it's actually legal for JMS topics/queues to have > > structure? > > > > I was making the change for binding subcontexts automatically (using > > org.jboss.naming.Util). And it deploys fine. > > > > But, if I kill jboss and restart it (without my sar that defines the > > queue in deploy), it throws exceptions because it finds a directory in > > the db/messaging/QUEUE.mycompany/myqueue > > > > The queue was "mycompany/myqueue", which was created correctly as > > db/messaging/QUEUE.mycompany/myqueue/ > > > > I can only assume that the queue restoration only looks one level deep. > > And attempts to restore a queue (even though the queue is not in any DD > > anymore) > > > > I'm just trying to understand what all should be fixed. > > > > So, questions of the day are : > > > > 1) Can a queuename have depth? > > 2) Should all queues be restored at jboss startup regardless of if they > > are needed anymore? > > 2a) Or when the MBEAN descriptor is located? > > The startup is in 2 phases. When the pm is started, it "pre-restores" all > the queues it can find, figures out which messages weren't committed (btw > I'm not convinced it handles "prepared but not committed" properly), and > makes lists of undelivered messages. Then when each queue starts, it > registers with the pm and gets its list of messages. For topics, if I > remember correctly, the queue representing the topic asks the StateManager > for all the subscriber queues and restores each one individually. > > In regards to (2), there is no way to tell if a queue is needed anymore. > The mbeans for the queues are not necessarily in the same file as the mbean > for the pm, and could be deployed hours or days later. On the other hand, > the cleanup of uncommitted messages should happen as soon as the pm is > started, so you don't need to keep dead data around indefinitely. > > david jencks > > > > -David > > > > ___ > 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] Installer / Deployer Problem
marc fleury wrote: > ok one of us doesn't get it, if you are "open most of the time" how do you > release the lock in the filesystem for anyone to overwrite the file ? I > could be missing it :) 1. URLCL wants to access "custom://somejar.jar" 2. It uses CustomURLHandler to get a connection to somejar.jar. This connection is put in cache and is never let go of. 3. The connection retrieved from CustomURLHandler is not a real connection, but merely a wrapper to a file connection. Similar to how a connection pool provides implementations of Connection that are only wrappers for real connections that can be managed by the pool. 4. Operations on the connection are passed on to the file connection. 5. When redeploy of a JAR is to be done, the wrapper is told to close its underlying connection 6. At this point there are no open connections to the JAR, so it can be replaced with a new file or removed. 7. At some point the connection wrapper is called, either by the old URLCL or a new one using the same connection. The file connection is then re-acquired, only now to the new file. See? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (rh)Possible consistency problem in jbosscmp-jdbc.dtd?
I'm wondering what the intent behind the eager-load and lazy-load-group is. I would think that you would want to partition the cmp-fields into one eager-load and 0 or more lazy-load groups. Is this correct? If so, the current xml structure makes it pretty easy to include fields into many of these groups. Is this intentional? What should happen in this case? If a partition is really desired, perhaps an alternate xml structure along the lines of or would be more appropriate. cmp-fields without a lazy-load-group would be in the unique eager-load group. Any thoughts? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] QueueConnectionFactory in Rabbit Hole
I beleive you should use ConnectionFactory nowadays. > -Original Message- > From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 28 November 2001 10:38 a.m. > To: JBoss Dev > Subject: [JBoss-dev] QueueConnectionFactory in Rabbit Hole > > > Anyone know where QueueConnectionFactory lives in RH JNDI? I > can't see it in > JNDIView so I suppose it is not started by default? > > Has this mbean changed or can I just paste over 2.x code to > get it in there? > > > ___ > 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] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
On 2001.11.27 16:37:20 -0500 Anatoly Akkerman wrote: > > > > Can Castor merge nested attributes from all the files into one object? > For > > instance, there are elements under ejb-jar/enterprise-beans/entity and > > jboss-cmp/enterprise-beans/entity that should all end up in > > result-dd/enterprise-beans/entity. > > Not that I know of. Doing XSLT, would, probably be the best way for such > processing. Castor can only instantiate a new object tree that represents > a given XML file. It cannot 'update' an existing tree from this > 'incremental' unmarshalling. In general it is an impossible task. Think > about it. Castor (or any other software) would have to know which pieces > match where. Say, in the case of ejb descriptors, it would not be enough > to match and from ejb-jar.xml with > from jboss.xml. You would have to match _names_ and whatever else to make > sure you are updating descriptor object for the right entity bean. This > already is _semantic_ interpretation of what stands behind the data in > the > XML file. You can only write a custom combiner that would take 3 object > trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a > combined tree, matching appripriate descriptors by hand. > > Actually, I don't know if XSLT will to that for you, it also does not > know > anything about the semantics of the XML files you are combining. It seems > to me, this must be a custom combining solution. Well, I think I figured out all the hard parts of using xslt to combine them in this way. Since all the xml can be validated by a dtd I think it will work out fine. Castor instead of jaxb might be an option still, though. I'd prefer to use a standards based solution but if licensing makes it unavailable... david jencks > > Anatoly. > > > > > Just having copies of all 3 docs in the super-jboss is probably easier > with > > including an xml entity;-) > > > > david jencks > > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
On 2001.11.27 15:55:06 -0500 David Budworth wrote: > Does anyone know if it's actually legal for JMS topics/queues to have > structure? > > I was making the change for binding subcontexts automatically (using > org.jboss.naming.Util). And it deploys fine. > > But, if I kill jboss and restart it (without my sar that defines the > queue in deploy), it throws exceptions because it finds a directory in > the db/messaging/QUEUE.mycompany/myqueue > > The queue was "mycompany/myqueue", which was created correctly as > db/messaging/QUEUE.mycompany/myqueue/ > > I can only assume that the queue restoration only looks one level deep. > And attempts to restore a queue (even though the queue is not in any DD > anymore) > > I'm just trying to understand what all should be fixed. > > So, questions of the day are : > > 1) Can a queuename have depth? > 2) Should all queues be restored at jboss startup regardless of if they > are needed anymore? > 2a) Or when the MBEAN descriptor is located? The startup is in 2 phases. When the pm is started, it "pre-restores" all the queues it can find, figures out which messages weren't committed (btw I'm not convinced it handles "prepared but not committed" properly), and makes lists of undelivered messages. Then when each queue starts, it registers with the pm and gets its list of messages. For topics, if I remember correctly, the queue representing the topic asks the StateManager for all the subscriber queues and restores each one individually. In regards to (2), there is no way to tell if a queue is needed anymore. The mbeans for the queues are not necessarily in the same file as the mbean for the pm, and could be deployed hours or days later. On the other hand, the cleanup of uncommitted messages should happen as soon as the pm is started, so you don't need to keep dead data around indefinitely. david jencks > > -David > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
> |> You don't get it, the cl arch of 3.0 asks all the cls in case a |class is not |> there, so well beyond the "deployment" if a class is not loaded |during that |> deployment we might have problems... if everything is loaded at |deployment |> time then we will be ok. | | |No, you don't get it. Please reread my previous posts. The connection |will be open pretty much all of the time. The only time it will be |closed is during deploy time. Hence, no problem. ok one of us doesn't get it, if you are "open most of the time" how do you release the lock in the filesystem for anyone to overwrite the file ? I could be missing it :) marcf | |/R | |-- |Rickard Öberg | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] (rh) Can we combine j2ee and jboss dds with xsl toget just one dd?
> > Can Castor merge nested attributes from all the files into one object? For > instance, there are elements under ejb-jar/enterprise-beans/entity and > jboss-cmp/enterprise-beans/entity that should all end up in > result-dd/enterprise-beans/entity. Not that I know of. Doing XSLT, would, probably be the best way for such processing. Castor can only instantiate a new object tree that represents a given XML file. It cannot 'update' an existing tree from this 'incremental' unmarshalling. In general it is an impossible task. Think about it. Castor (or any other software) would have to know which pieces match where. Say, in the case of ejb descriptors, it would not be enough to match and from ejb-jar.xml with from jboss.xml. You would have to match _names_ and whatever else to make sure you are updating descriptor object for the right entity bean. This already is _semantic_ interpretation of what stands behind the data in the XML file. You can only write a custom combiner that would take 3 object trees (say, from ejb-jar.xml, jboss.xml and jaws.xml) and produce a combined tree, matching appripriate descriptors by hand. Actually, I don't know if XSLT will to that for you, it also does not know anything about the semantics of the XML files you are combining. It seems to me, this must be a custom combining solution. Anatoly. > > Just having copies of all 3 docs in the super-jboss is probably easier with > including an xml entity;-) > > david jencks > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > |The open/close only happens at deploy time, so no problem > > You don't get it, the cl arch of 3.0 asks all the cls in case a class is not > there, so well beyond the "deployment" if a class is not loaded during that > deployment we might have problems... if everything is loaded at deployment > time then we will be ok. No, you don't get it. Please reread my previous posts. The connection will be open pretty much all of the time. The only time it will be closed is during deploy time. Hence, no problem. /R -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Sorry to follow up my own message, but I need another question answered. Note: In the previous message, I was incorrectly saying db/messaging, it's really db/jbossmq/file Is it possible to have queues named: companyA companyA/myqueue1 companyA/myqueue2 I'm changing (in anticipation that deep queues are valid), the file pm for queues. It currently just get's a list of all files in db/jbossmq/file/ Then attempts to restore the MessageLogs for each file in that list. When MessageLog attempts to restore, it just looks for a "." in the name (ie: QUEUE.bob), and restores all messages files in that dir, if no "." is there it assumes the file is a message log and attempts to restore it directly, which is why my stuff is failing, because it looks like QUEUE.companyA/myqueue1/* But the restoration code assumes "myqueue1" is a file, and not a subdir (because no ".") It seems to me, that a much easier fix is to not restore the queue on startup, but instead restore in when the DD is deployed. But I suppose there may be a need to restore a queue before it's actually defined? The auto-restored queues doesn't show up in the 8082 UI (BTW what's that called?). So I am not sure why the PM is creating an instance of MessageLog for them at startup. Am I just not getting it? -David On Tue, 27 Nov 2001, David Budworth wrote: > Does anyone know if it's actually legal for JMS topics/queues to have > structure? > > I was making the change for binding subcontexts automatically (using > org.jboss.naming.Util). And it deploys fine. > > But, if I kill jboss and restart it (without my sar that defines the > queue in deploy), it throws exceptions because it finds a directory in > the db/messaging/QUEUE.mycompany/myqueue > > The queue was "mycompany/myqueue", which was created correctly as > db/messaging/QUEUE.mycompany/myqueue/ > > I can only assume that the queue restoration only looks one level deep. > And attempts to restore a queue (even though the queue is not in any DD > anymore) > > I'm just trying to understand what all should be fixed. > > So, questions of the day are : > > 1) Can a queuename have depth? > 2) Should all queues be restored at jboss startup regardless of if they > are needed anymore? > 2a) Or when the MBEAN descriptor is located? > > -David > > > On Tue, 27 Nov 2001, Hiram Chirino wrote: > > > >From: David Jencks <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names > > >Date: Mon, 26 Nov 2001 23:26:02 -0500 > > > > > >On 2001.11.26 22:50:55 -0500 David Budworth wrote: > > >> Hi all, > > >> > > >> There are two things bugging me right now in JMS, and I just wanted to > > >> know if anyone is working on them, or if they need to be fixed at all. > > >> > > >> The first one, is pretty obviously a 'needs-to-be-done'. You can't > > >> current undeploy a queue/topic. > > >> > > >> In my sar, I define the JMS queues that the services use, and when I > > >> undeploy the .sar, the log says "queue stop not yet implemented". > > >> > > >> The problem this causes is that once you delete the SAR, the queue name > > >> disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, > > >> or just create the queue via the 8082 UI, you'll get a an error stating > > >> the topic/queue already exists. > > >> > > >> So it seems that on undeploy, the internal stuctures of JBossMQ gets > > >> fux0r3d (in script-kiddie speak). > > >> > > >> I'd be happy to work on this (since I need it). I just didn't know if > > >> anyone else was already doing it. Nor do I really know where to start > > >> on it. > > >> > > > > > >I'm not the most expert... but I think the queue stop method needs to > > >arrange with the JMSService to stop accepting messages and possibly with > > >the persistence manager to make sure everything is stably saved that should > > >be. Make sure all open transactions are ended before shutting down! > > > > Sounds about right. > > > > >> > > >> > > >> The second one is just something that bothers me, which is if you > > >> specify a queue name like: > > >> mycompany/queuea > > >> > > >> You will get a name not bound exception on "mycompany". For EJBs this > > >> works correctly, where the subcontexts are created on the fly as need > > >> be. But for JMS it doesn't. > > >> > > >> I'd also like to add this, since I don't like having the JMS > > >> topics/queues in a flat namespace. > > >> > > >> I'm not sure if this is by spec though. Are you not allowed to create a > > >> heirarchy for the queue/topic names? If I create transient topics, I > > >> can do it if I pre-create the subcontexts. So I know it 'works', I'm > > >> just not sure it's legal. > > >> > > >> Also, is there some helper code somewhere in jboss to create a JNDI tree > > >> already? Or does everyone just roll there own with tokenizers or > > >> something? > > > > > >I feel like I've seen 10 or twenty implementations of this, but its > > >probably ju
RE: [JBoss-dev] Installer / Deployer Problem
|The open/close only happens at deploy time, so no problem You don't get it, the cl arch of 3.0 asks all the cls in case a class is not there, so well beyond the "deployment" if a class is not loaded during that deployment we might have problems... if everything is loaded at deployment time then we will be ok. marcf | | |> Also the file must inflated anyway and do I miss something ? | | |AFAIK the file would *not* have to be inflated. What are the reasons it |must be inflated? | |/Rickard | | |-- |Rickard Öberg | | |___ |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] (rh) Can we combine j2ee and jboss dds with xsl to get just one dd?
On 2001.11.27 15:38:07 -0500 Anatoly Akkerman wrote: > > > what if we use xslt to transform the deploymentdescriptors to > jdk1.4's > > > longterm persistence format and let the task of parsing the xml and > > > instantiating the metadata beans to the java.beans.XMLDecoder .. this > > > > would at least enhance maintainability. > > > > > > Very interesting idea. I was playing with using jaxb for xml to object > > conversion, although there may be license issues with it. Offhand, it > > looks to me as if using the jdk 1.4 persistence format (I just read > about > > it for 5 min or so) would involve some pretty heavy-duty xml > > transformations and require jdk 1.4. Jaxb appears (in very preliminary > > experiments) to be able to generate classes from the ejb 2 dtd and > > jbosscmp-jdbc dtd. > > > > sooo.. > > > > --jaxb requires using specially generated base classes but requires > minimal > > xml transformation. License may make it unavailable ( anyone else > have > > an opinion about this???) > > Probably the simplest thing to glue these things would be using Castor > with custom mapping and/or autogenerated classes. (JAXB seems to be an > effort to standardize Castor-like technologies from various players in > the > field. From what I remember Exolab (or Intalio, or whatever their current > name is) was a member of this JSR. > > Castor has a mode where you write your custom class hierarchy that would > be used to represent an XML in object tree form. Then you write a special > XML file which describes how these classes are mapped into XML entities > and attributes. Then you can simple use a Marshaller or Unmarshaller to > store/restore an object tree to/from XML. > > The other mode that Castor provides, is auto-generation of classes that > would represent any valid instance of an XML file that conforms to a > given > XML Schema from which the classes are generated. This is, in a way, a way > for the lazy guys to get around learning SAX or DOM (exactly what I > did). And this is what JAXB seems to promise at the moment. Though, JAXB > only works with dtds at the moment, while Castor can already deal with > XML > Schemas which are far more expressive than DTDs. > > In my current project I am using auto-generated classes for J2EE and > JBoss > descriptors (J2EE 1.1 and JBoss 2.2 or something like that). As a head > start I can provide XML Schemas which I've used to produce the class > hierarchies with Castor. For some custom XML descriptors that I am using > to store my project's metadata, I have written custom classes and used > mapping technique of Castor. I can share my experiences with those as > well. It is a solid technology, though, I am glad I did not have to mess > with SAX or DOM. > > This is how you would glue several files together. Say you have > ejb-jar.xml > jboss.xml > jaws.xml > > You unmarshal all 3 files and get 3 objects, say, instances of > jboss.xml.j2ee.EjbJar > jboss.xml.jbossconf.Jboss > jboss.xml.jbossconf.Jaws > > Then you create a new instance of a class (which is also marshallable by > Castor), say jboss.xml.SuperJBoss > and add the above 3 objects into that newly created objects with > appropriate set() methods. > > then marshal SuperJBoss into a file, say super-jboss.xml > > Vice versa it is similar: > > unmarshal SuperJBoss from an XML file. > Obtain subcomponents with appropriate getters, > store them individually in each one's XML file. > > Voila. (Well, sort of) > > Anatoly. Can Castor merge nested attributes from all the files into one object? For instance, there are elements under ejb-jar/enterprise-beans/entity and jboss-cmp/enterprise-beans/entity that should all end up in result-dd/enterprise-beans/entity. Just having copies of all 3 docs in the super-jboss is probably easier with including an xml entity;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JMS issues re: stopservice, jndi names
Does anyone know if it's actually legal for JMS topics/queues to have structure? I was making the change for binding subcontexts automatically (using org.jboss.naming.Util). And it deploys fine. But, if I kill jboss and restart it (without my sar that defines the queue in deploy), it throws exceptions because it finds a directory in the db/messaging/QUEUE.mycompany/myqueue The queue was "mycompany/myqueue", which was created correctly as db/messaging/QUEUE.mycompany/myqueue/ I can only assume that the queue restoration only looks one level deep. And attempts to restore a queue (even though the queue is not in any DD anymore) I'm just trying to understand what all should be fixed. So, questions of the day are : 1) Can a queuename have depth? 2) Should all queues be restored at jboss startup regardless of if they are needed anymore? 2a) Or when the MBEAN descriptor is located? -David On Tue, 27 Nov 2001, Hiram Chirino wrote: > >From: David Jencks <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Re: [JBoss-dev] JMS issues re: stopservice, jndi names > >Date: Mon, 26 Nov 2001 23:26:02 -0500 > > > >On 2001.11.26 22:50:55 -0500 David Budworth wrote: > >> Hi all, > >> > >> There are two things bugging me right now in JMS, and I just wanted to > >> know if anyone is working on them, or if they need to be fixed at all. > >> > >> The first one, is pretty obviously a 'needs-to-be-done'. You can't > >> current undeploy a queue/topic. > >> > >> In my sar, I define the JMS queues that the services use, and when I > >> undeploy the .sar, the log says "queue stop not yet implemented". > >> > >> The problem this causes is that once you delete the SAR, the queue name > >> disappears from the 8082 UI, but, if you attempt to re-deploy the SAR, > >> or just create the queue via the 8082 UI, you'll get a an error stating > >> the topic/queue already exists. > >> > >> So it seems that on undeploy, the internal stuctures of JBossMQ gets > >> fux0r3d (in script-kiddie speak). > >> > >> I'd be happy to work on this (since I need it). I just didn't know if > >> anyone else was already doing it. Nor do I really know where to start > >> on it. > >> > > > >I'm not the most expert... but I think the queue stop method needs to > >arrange with the JMSService to stop accepting messages and possibly with > >the persistence manager to make sure everything is stably saved that should > >be. Make sure all open transactions are ended before shutting down! > > Sounds about right. > > >> > >> > >> The second one is just something that bothers me, which is if you > >> specify a queue name like: > >> mycompany/queuea > >> > >> You will get a name not bound exception on "mycompany". For EJBs this > >> works correctly, where the subcontexts are created on the fly as need > >> be. But for JMS it doesn't. > >> > >> I'd also like to add this, since I don't like having the JMS > >> topics/queues in a flat namespace. > >> > >> I'm not sure if this is by spec though. Are you not allowed to create a > >> heirarchy for the queue/topic names? If I create transient topics, I > >> can do it if I pre-create the subcontexts. So I know it 'works', I'm > >> just not sure it's legal. > >> > >> Also, is there some helper code somewhere in jboss to create a JNDI tree > >> already? Or does everyone just roll there own with tokenizers or > >> something? > > > >I feel like I've seen 10 or twenty implementations of this, but its > >probably just 3 or 4;-) They are often in Deployers. Could we put one > >version in either DeployerMBeanSupport or ServiceMBeanSupport? > > > > The MBean classes don't seem to ME to be the right place for the kind of > code. Maybe a new JNDISupport in the org.jboss.util?? > > Regards, > Hiram > > >David Jencks > >> > >> -David > >> > >> ___ > >> 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
Re: [JBoss-dev] Installer / Deployer Problem
On Tue, 27 Nov 2001, Rickard [ISO-8859-1] Öberg wrote: > Andreas Schaefer wrote: > > > I don't see the point here. The copying of the file is done when it get > > deployed > > and this is a rare occurance. When you now have to open/close the connection > > to the URL then it can affect the overall performance which I think is the > > worse > > that to copy the file. > > > The open/close only happens at deploy time, so no problem > > > > Also the file must inflated anyway and do I miss something ? > > > AFAIK the file would *not* have to be inflated. What are the reasons it > must be inflated? See David Jencks previous message in this thread where he said it is needed for ears, sars and any other JAR archive which has nested JAR archives in them which have to be used by a CL. So, inflating is needed unless you dump standard j2ee packaging (which, in fact, we are discussing in a different thread, well we would need it for backward compatibility but still) or come up with a way of (getting inside a jar)* to reach another jar without inflating them. ^^regex^^^ Packaging sucks... Anatoly. > > /Rickard > > > -- > Rickard Öberg > > > ___ > 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] (rh) Can we combine j2ee and jboss dds with xsl toget just one dd?
> > what if we use xslt to transform the deploymentdescriptors to jdk1.4's > > longterm persistence format and let the task of parsing the xml and > > instantiating the metadata beans to the java.beans.XMLDecoder .. this > > would at least enhance maintainability. > > > Very interesting idea. I was playing with using jaxb for xml to object > conversion, although there may be license issues with it. Offhand, it > looks to me as if using the jdk 1.4 persistence format (I just read about > it for 5 min or so) would involve some pretty heavy-duty xml > transformations and require jdk 1.4. Jaxb appears (in very preliminary > experiments) to be able to generate classes from the ejb 2 dtd and > jbosscmp-jdbc dtd. > > sooo.. > > --jaxb requires using specially generated base classes but requires minimal > xml transformation. License may make it unavailable ( anyone else have > an opinion about this???) Probably the simplest thing to glue these things would be using Castor with custom mapping and/or autogenerated classes. (JAXB seems to be an effort to standardize Castor-like technologies from various players in the field. From what I remember Exolab (or Intalio, or whatever their current name is) was a member of this JSR. Castor has a mode where you write your custom class hierarchy that would be used to represent an XML in object tree form. Then you write a special XML file which describes how these classes are mapped into XML entities and attributes. Then you can simple use a Marshaller or Unmarshaller to store/restore an object tree to/from XML. The other mode that Castor provides, is auto-generation of classes that would represent any valid instance of an XML file that conforms to a given XML Schema from which the classes are generated. This is, in a way, a way for the lazy guys to get around learning SAX or DOM (exactly what I did). And this is what JAXB seems to promise at the moment. Though, JAXB only works with dtds at the moment, while Castor can already deal with XML Schemas which are far more expressive than DTDs. In my current project I am using auto-generated classes for J2EE and JBoss descriptors (J2EE 1.1 and JBoss 2.2 or something like that). As a head start I can provide XML Schemas which I've used to produce the class hierarchies with Castor. For some custom XML descriptors that I am using to store my project's metadata, I have written custom classes and used mapping technique of Castor. I can share my experiences with those as well. It is a solid technology, though, I am glad I did not have to mess with SAX or DOM. This is how you would glue several files together. Say you have ejb-jar.xml jboss.xml jaws.xml You unmarshal all 3 files and get 3 objects, say, instances of jboss.xml.j2ee.EjbJar jboss.xml.jbossconf.Jboss jboss.xml.jbossconf.Jaws Then you create a new instance of a class (which is also marshallable by Castor), say jboss.xml.SuperJBoss and add the above 3 objects into that newly created objects with appropriate set() methods. then marshal SuperJBoss into a file, say super-jboss.xml Vice versa it is similar: unmarshal SuperJBoss from an XML file. Obtain subcomponents with appropriate getters, store them individually in each one's XML file. Voila. (Well, sort of) Anatoly. > > --jdk 1.4 persistence can use regular classes but requires a lot of xsl, > and jdb 1.4. > > Any one have experience with both or at least an opinion? > > Thanks > david jencks > > > > > > > > > > Good idea or am I nuts? > > > > > > > .. definately I am ;-) > > > > Holger > > > > > > ___ > > 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > not that I know, the original deployer was a piece of crap anyway, fix this > if you want. > > BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require > the 1.4 VM for proper behavior of the deployer I think it would greatly > simplify the design as we wouldn't need to copy the files over. It's not fixed. Marc, do you remember when we were at J1 and talked to your french friend that said something about it being a security hole if it was fixed. Or something like that. I've been thinking about this problem though. Wouldn't it be possible to make a custom URL handler that returns a connection wrapper that we can drop under the covers. I.e. even if the URLClassLoader hangs onto it, we can still close the file under the covers. I think that would make it work, and wouldn't be *that* intrusive in the code. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Andreas Schaefer wrote: > I don't see the point here. The copying of the file is done when it get > deployed > and this is a rare occurance. When you now have to open/close the connection > to the URL then it can affect the overall performance which I think is the > worse > that to copy the file. The open/close only happens at deploy time, so no problem > Also the file must inflated anyway and do I miss something ? AFAIK the file would *not* have to be inflated. What are the reasons it must be inflated? /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > following my own mantra of "communicate simple", go right ahead and create a > URLConnection that closes the connection after some time or every time, > maybe even every time is enough. See previous email. No guessing is needed. All the connection needs is that when we explicitly say "close() goddammit" it will close the underlying connection, so that we can remove the file that it was pointing to. > The discussion I have below only affects "loading" times when new classes > are deployed and we can always measure that and deal with it. So KISS the > URL. There would be no loading time problems. See previous descriptions. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
marc fleury wrote: > |It's not fixed. Marc, do you remember when we were at J1 and talked to > |your french friend that said something about it being a security hole if > |it was fixed. Or something like that. > > Are you sure it is not fixed? as in you verified or as in you took what this > guy said at face value (name is jc collet btw), I wouldn't trust everything > he said :) you know we were friends and all but... Haven't checked, but can't imagine that it's been fixed... still, would be nice with a solution that works on 1.3 too. > |I've been thinking about this problem though. Wouldn't it be possible to > |make a custom URL handler that returns a connection wrapper that we can > |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we > |can still close the file under the covers. I think that would make it > |work, and wouldn't be *that* intrusive in the code. > > sure, that is an idea and it would simplify the code a lot. The problem I > see is that I suspect they keep the connection opened for classloading > reasons, i.e. the VM asks for loading classes at random times. Reopening the > connection seems slow (the security hole would be the capability to change > the jar we look up???). That's irrelevant. It's ok that they hold on to the connection. It's not ok that there's no way to flush that cache. What our custom URL handler would buy us is that we can close the underlying connections explicitly as needed. If there's another call on the connection we would reopen it, but during the time it is closed we can replace the underlying JAR. > I guess the way this works is you would put a time out on the URL or > something, you need to make guesses as to when the vm will be done loading > from this puppy which is never in the case of JMX and SL CL architectures. Nope, just an explicit way of closing the connections and thus disregarding how the URLClassLoader connection cache does things. > A problem will be slow classloading in the JMX/SL base (it will affect 2.4 > and 3.0) as you will ask CL to look for classes in connections that are > closed... h we are going to need smart CLs... at least with > indexing, yes... indexing of cl contents to allow for fast clusterwide > lookups h me likes... do you see these? is there a way to create a > default jar tvf (t being the important one here) and allowing for indexing > PER Cl, that would dramaticaly improve the speed of our superservers as well > as solve the above problem. blah blah blah... nonsense. Not a problem, see above. The only thing that's important is that we can *close* them when *we* want to. Other than that its fine that the URLCL hangs onto open connections. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ANN] JBoss 3.0 alpha is out
Actually the latest works fine. I didnt even get a chance to look at the src before it was fixed :) [EMAIL PROTECTED] wrote: >2. if you sync yourself with the cvs tree you will get >an upgrade to Jetty4. I am much happier with the >Security integration in this version. If the problem >lies with Jetty itself ask Greg whether the fix has >gone into Jetty4 - Greg ? You really should sync, if >you can - because lots of stuff has gone into my >integration since 3.0alpha was released. > >> >>___ >>Jboss-development mailing list >>[EMAIL PROTECTED] >> >https://lists.sourceforge.net/lists/listinfo/jboss-development > >__ >Do You Yahoo!? >Everything you'll ever need on one web page from News and Sport to Email and Music Charts >http://uk.my.yahoo.com > >___ >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] Installer / Deployer Problem
On 2001.11.27 13:34:31 -0500 marc fleury wrote: > > > |-Original Message- > |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > |Sent: Tuesday, November 27, 2001 12:57 PM > |To: marc fleury; Rickard Öberg > |Cc: [EMAIL PROTECTED] > |Subject: Re: [JBoss-dev] Installer / Deployer Problem > | > | > |Hi > | > |I don't see the point here. The copying of the file is done when it get > |deployed > |and this is a rare occurance. When you now have to open/close the > > It really slows down large deployment. Copying 2 meg is just bad. Again > packaging madness. > > |connection > |to the URL then it can affect the overall performance which I think is > the > |worse > |that to copy the file. > |Also the file must inflated anyway and do I miss something ? > > it's a point, I don't care either way. But when do you need to "inflate" > and why? refresh my memory You may not need to inflate a jar, but rar, ear, and now sar have jars inside them. Unless someone can come up with a way to get classes out of them using a jar:jar:jar:http://.!/!/!/ url we need to unpack them. If network speed is the problem here, how can it possibly be faster after deployment to use a remote url rather than a local copy? Otherwise are you sure it is file copying that is taking the time? So far I agree with Andy. david jencks > > marcf > | > |Andy > | > |- Original Message - > |From: "marc fleury" <[EMAIL PROTECTED]> > |To: "Rickard Öberg" <[EMAIL PROTECTED]> > |Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; > |<[EMAIL PROTECTED]> > |Sent: Tuesday, November 27, 2001 9:13 AM > |Subject: RE: [JBoss-dev] Installer / Deployer Problem > | > | > |> |It's not fixed. Marc, do you remember when we were at J1 and talked > to > |> |your french friend that said something about it being a security hole > if > |> |it was fixed. Or something like that. > |> > |> Are you sure it is not fixed? as in you verified or as in you took > what > |this > |> guy said at face value (name is jc collet btw), I wouldn't trust > |everything > |> he said :) you know we were friends and all but... > |> > |> |I've been thinking about this problem though. Wouldn't it be possible > to > |> |make a custom URL handler that returns a connection wrapper that we > can > |> |drop under the covers. I.e. even if the URLClassLoader hangs onto it, > we > |> |can still close the file under the covers. I think that would make it > |> |work, and wouldn't be *that* intrusive in the code. > |> > |> sure, that is an idea and it would simplify the code a lot. The > |problem I > |> see is that I suspect they keep the connection opened for classloading > |> reasons, i.e. the VM asks for loading classes at random times. > Reopening > |the > |> connection seems slow (the security hole would be the capability > |to change > |> the jar we look up???). > |> > |> I guess the way this works is you would put a time out on the URL or > |> something, you need to make guesses as to when the vm will be > |done loading > |> from this puppy which is never in the case of JMX and SL CL > |architectures. > |> > |> A problem will be slow classloading in the JMX/SL base (it will > |affect 2.4 > |> and 3.0) as you will ask CL to look for classes in connections that > are > |> closed... h we are going to need smart CLs... at least with > |> indexing, yes... indexing of cl contents to allow for fast clusterwide > |> lookups h me likes... do you see these? is there a way > |to create a > |> default jar tvf (t being the important one here) and allowing > |for indexing > |> PER Cl, that would dramaticaly improve the speed of our superservers > as > |well > |> as solve the above problem. > |> > |> but in any case until we know what it takes to open and close a > |connection > |> that would be the simplest. > |> > |> Go ahead and also try to get some number on "how much time to open one > |> connection to file/10 connections/ lookup a class randomly in the 10 > that > |> are there"... if you get that in time for the rewrite it would > |really make > |> the work simple. > |> > |> marcf > |> > |> > |> | > |> |/Rickard > |> | > |> |-- > |> |Rickard Öberg > |> | > |> > | > > > ___ > 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] Installer / Deployer Problem
|-Original Message- |From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 27, 2001 12:57 PM |To: marc fleury; Rickard Öberg |Cc: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] Installer / Deployer Problem | | |Hi | |I don't see the point here. The copying of the file is done when it get |deployed |and this is a rare occurance. When you now have to open/close the It really slows down large deployment. Copying 2 meg is just bad. Again packaging madness. |connection |to the URL then it can affect the overall performance which I think is the |worse |that to copy the file. |Also the file must inflated anyway and do I miss something ? it's a point, I don't care either way. But when do you need to "inflate" and why? refresh my memory marcf | |Andy | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: "Rickard Öberg" <[EMAIL PROTECTED]> |Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; |<[EMAIL PROTECTED]> |Sent: Tuesday, November 27, 2001 9:13 AM |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | |> |It's not fixed. Marc, do you remember when we were at J1 and talked to |> |your french friend that said something about it being a security hole if |> |it was fixed. Or something like that. |> |> Are you sure it is not fixed? as in you verified or as in you took what |this |> guy said at face value (name is jc collet btw), I wouldn't trust |everything |> he said :) you know we were friends and all but... |> |> |I've been thinking about this problem though. Wouldn't it be possible to |> |make a custom URL handler that returns a connection wrapper that we can |> |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |> |can still close the file under the covers. I think that would make it |> |work, and wouldn't be *that* intrusive in the code. |> |> sure, that is an idea and it would simplify the code a lot. The |problem I |> see is that I suspect they keep the connection opened for classloading |> reasons, i.e. the VM asks for loading classes at random times. Reopening |the |> connection seems slow (the security hole would be the capability |to change |> the jar we look up???). |> |> I guess the way this works is you would put a time out on the URL or |> something, you need to make guesses as to when the vm will be |done loading |> from this puppy which is never in the case of JMX and SL CL |architectures. |> |> A problem will be slow classloading in the JMX/SL base (it will |affect 2.4 |> and 3.0) as you will ask CL to look for classes in connections that are |> closed... h we are going to need smart CLs... at least with |> indexing, yes... indexing of cl contents to allow for fast clusterwide |> lookups h me likes... do you see these? is there a way |to create a |> default jar tvf (t being the important one here) and allowing |for indexing |> PER Cl, that would dramaticaly improve the speed of our superservers as |well |> as solve the above problem. |> |> but in any case until we know what it takes to open and close a |connection |> that would be the simplest. |> |> Go ahead and also try to get some number on "how much time to open one |> connection to file/10 connections/ lookup a class randomly in the 10 that |> are there"... if you get that in time for the rewrite it would |really make |> the work simple. |> |> marcf |> |> |> | |> |/Rickard |> | |> |-- |> |Rickard Öberg |> | |> | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Hi I don't see the point here. The copying of the file is done when it get deployed and this is a rare occurance. When you now have to open/close the connection to the URL then it can affect the overall performance which I think is the worse that to copy the file. Also the file must inflated anyway and do I miss something ? Andy - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Rickard Öberg" <[EMAIL PROTECTED]> Cc: "Andreas Schaefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 9:13 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem > |It's not fixed. Marc, do you remember when we were at J1 and talked to > |your french friend that said something about it being a security hole if > |it was fixed. Or something like that. > > Are you sure it is not fixed? as in you verified or as in you took what this > guy said at face value (name is jc collet btw), I wouldn't trust everything > he said :) you know we were friends and all but... > > |I've been thinking about this problem though. Wouldn't it be possible to > |make a custom URL handler that returns a connection wrapper that we can > |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we > |can still close the file under the covers. I think that would make it > |work, and wouldn't be *that* intrusive in the code. > > sure, that is an idea and it would simplify the code a lot. The problem I > see is that I suspect they keep the connection opened for classloading > reasons, i.e. the VM asks for loading classes at random times. Reopening the > connection seems slow (the security hole would be the capability to change > the jar we look up???). > > I guess the way this works is you would put a time out on the URL or > something, you need to make guesses as to when the vm will be done loading > from this puppy which is never in the case of JMX and SL CL architectures. > > A problem will be slow classloading in the JMX/SL base (it will affect 2.4 > and 3.0) as you will ask CL to look for classes in connections that are > closed... h we are going to need smart CLs... at least with > indexing, yes... indexing of cl contents to allow for fast clusterwide > lookups h me likes... do you see these? is there a way to create a > default jar tvf (t being the important one here) and allowing for indexing > PER Cl, that would dramaticaly improve the speed of our superservers as well > as solve the above problem. > > but in any case until we know what it takes to open and close a connection > that would be the simplest. > > Go ahead and also try to get some number on "how much time to open one > connection to file/10 connections/ lookup a class randomly in the 10 that > are there"... if you get that in time for the rewrite it would really make > the work simple. > > marcf > > > | > |/Rickard > | > |-- > |Rickard Öberg > | > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-486081 ] cluster-service.xml not in 3.0 alpha kit
Bugs item #486081, was opened at 2001-11-27 09:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=486081&group_id=22866 Category: Build System Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Alan Lewis (alanlewis) Assigned to: Jason Dillon (user57) Summary: cluster-service.xml not in 3.0 alpha kit Initial Comment: A file that is required to enable clustering, cluster-service.xml, is not included in the 3.0.0alpha kit. In order to enable clustering you have to get this file from CVS. You could technically write one yourself, but there is no information in the docs on how to do this, so it would be pretty difficult. It looks as though this file should go under conf/cluster, but this directory is empty in the kit. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=486081&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
rickard, following my own mantra of "communicate simple", go right ahead and create a URLConnection that closes the connection after some time or every time, maybe even every time is enough. That will solve our problem for sure the vm will not be holding on to connections to the file system and we will be able to hotdeploy on the original files. The discussion I have below only affects "loading" times when new classes are deployed and we can always measure that and deal with it. So KISS the URL. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Tuesday, November 27, 2001 12:14 PM |To: Rickard Öberg |Cc: Andreas Schaefer; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] Installer / Deployer Problem | | ||It's not fixed. Marc, do you remember when we were at J1 and talked to ||your french friend that said something about it being a security hole if ||it was fixed. Or something like that. | |Are you sure it is not fixed? as in you verified or as in you took |what this |guy said at face value (name is jc collet btw), I wouldn't trust everything |he said :) you know we were friends and all but... | ||I've been thinking about this problem though. Wouldn't it be possible to ||make a custom URL handler that returns a connection wrapper that we can ||drop under the covers. I.e. even if the URLClassLoader hangs onto it, we ||can still close the file under the covers. I think that would make it ||work, and wouldn't be *that* intrusive in the code. | |sure, that is an idea and it would simplify the code a lot. The problem I |see is that I suspect they keep the connection opened for classloading |reasons, i.e. the VM asks for loading classes at random times. |Reopening the |connection seems slow (the security hole would be the capability to change |the jar we look up???). | |I guess the way this works is you would put a time out on the URL or |something, you need to make guesses as to when the vm will be done loading |from this puppy which is never in the case of JMX and SL CL architectures. | |A problem will be slow classloading in the JMX/SL base (it will affect 2.4 |and 3.0) as you will ask CL to look for classes in connections that are |closed... h we are going to need smart CLs... at least with |indexing, yes... indexing of cl contents to allow for fast clusterwide |lookups h me likes... do you see these? is there a way to create a |default jar tvf (t being the important one here) and allowing for indexing |PER Cl, that would dramaticaly improve the speed of our |superservers as well |as solve the above problem. | |but in any case until we know what it takes to open and close a connection |that would be the simplest. | |Go ahead and also try to get some number on "how much time to open one |connection to file/10 connections/ lookup a class randomly in the 10 that |are there"... if you get that in time for the rewrite it would really make |the work simple. | |marcf | | || ||/Rickard || ||-- ||Rickard Öberg || | | |___ |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] Build Broken?
I should have been more specific. I only get the error when I set it ! Jules --- Hunter Hillegas <[EMAIL PROTECTED]> wrote: > Yup, JBOSS_HOME was set properly. > > I'll do a refresh and test it again this afternoon > to see if it persists... > > > From: Julian Gosnell <[EMAIL PROTECTED]> > > Date: Tue, 27 Nov 2001 11:56:22 + (GMT) > > To: Hunter Hillegas <[EMAIL PROTECTED]>, > JBoss Dev > > <[EMAIL PROTECTED]> > > Subject: Re: [JBoss-dev] Build Broken? > > > > Have you got JBOSS_HOME set ? > > > > This one has bittent me before > > > > > > Jules > > > > --- Hunter Hillegas <[EMAIL PROTECTED]> > wrote: > >> Just grabbed the latest CVS and I get this on > >> startup: > >> > >> 20:09:54,995 WARN [ServiceDeployer] SaxException > >> getting document: > >> java.io.FileNotFoundException: > >> > > > /usr/java/jboss/co6/jboss-all/server/src/resources/org/jboss/metadata/jboss- > >> service.dtd (No such file or directory) > >> at > >> > > > org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) > >> > >> > >> At this point the server shuts down... > >> > >> > >> ___ > >> Jboss-development mailing list > >> [EMAIL PROTECTED] > >> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > __ > > Do You Yahoo!? > > Everything you'll ever need on one web page from > News and Sport to Email and > > Music Charts > > http://uk.my.yahoo.com > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Installer / Deployer Problem
|It's not fixed. Marc, do you remember when we were at J1 and talked to |your french friend that said something about it being a security hole if |it was fixed. Or something like that. Are you sure it is not fixed? as in you verified or as in you took what this guy said at face value (name is jc collet btw), I wouldn't trust everything he said :) you know we were friends and all but... |I've been thinking about this problem though. Wouldn't it be possible to |make a custom URL handler that returns a connection wrapper that we can |drop under the covers. I.e. even if the URLClassLoader hangs onto it, we |can still close the file under the covers. I think that would make it |work, and wouldn't be *that* intrusive in the code. sure, that is an idea and it would simplify the code a lot. The problem I see is that I suspect they keep the connection opened for classloading reasons, i.e. the VM asks for loading classes at random times. Reopening the connection seems slow (the security hole would be the capability to change the jar we look up???). I guess the way this works is you would put a time out on the URL or something, you need to make guesses as to when the vm will be done loading from this puppy which is never in the case of JMX and SL CL architectures. A problem will be slow classloading in the JMX/SL base (it will affect 2.4 and 3.0) as you will ask CL to look for classes in connections that are closed... h we are going to need smart CLs... at least with indexing, yes... indexing of cl contents to allow for fast clusterwide lookups h me likes... do you see these? is there a way to create a default jar tvf (t being the important one here) and allowing for indexing PER Cl, that would dramaticaly improve the speed of our superservers as well as solve the above problem. but in any case until we know what it takes to open and close a connection that would be the simplest. Go ahead and also try to get some number on "how much time to open one connection to file/10 connections/ lookup a class randomly in the 10 that are there"... if you get that in time for the rewrite it would really make the work simple. marcf | |/Rickard | |-- |Rickard Öberg | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Installer / Deployer Problem
Ok, then I will also do this changes: - rearrange Deployment and Application therefore I can be used to pass information from Installer/J2eeDeployer to ContainerFactory - ContainerFactory should not be called directly therefore I will remove the convenience deploy() method accepting a String instead of an URL Andy BTW I will check if the problem is fixed in JDK1.4. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Andreas Schaefer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 8:07 AM Subject: RE: [JBoss-dev] Installer / Deployer Problem > |Hi Geeks > | > |In the Installer all deployed application are copyed and then > |inflated (right now in "/deploy/Default/"). During this inflation > |the name of the contained archives are lost. As example for > |an JAR file it will be renamed to ejb1002.jar. > | > |Unfortunately the mapping of the orginal archive name is lost > |but JSR-77 needs to know the name of the archive. > | > |QUESTION: Is this a problem to keep the orignal name of > |the archive ? > > not that I know, the original deployer was a piece of crap anyway, fix this > if you want. > > BTW is the URL caching thing FIXED in 1.4 JDK or not? if so we could require > the 1.4 VM for proper behavior of the deployer I think it would greatly > simplify the design as we wouldn't need to copy the files over. > > Also teh copying gets to be slow when the stuff is too big, > > marcf > | > |Andy > | > |x > |Andreas Schaefer > |Senior Consultant > |JBoss Group, LLC > |x > | > | > |___ > |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
