[JBoss-dev] [ jboss-Bugs-516834 ] Broken jbosscmp-jdbc doesn't stop deploy
Bugs item #516834, was opened at 2002-02-13 00:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516834&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Broken jbosscmp-jdbc doesn't stop deploy Initial Comment: RH 20020212, W2K, Oracle 8.1.7. Currently I have two versions of jbosscmp-jdbc.xml, one for the before mid-January JBoss version and one for the current version. To test another bug I deployed the jar with the old version of jbosscmp-jdbc.xml. This gives me dozens of error messages from the XmlFileReader about foreign-key-fields not being allowed and empty elements, as expected. But the deploy continues and tries to create pk constraints of enormous length (beyond Oracle's capacity), which finally stops the deployment. Georg -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516834&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-515542 ] getRemote in MBean view throws NPE
Bugs item #515542, was opened at 2002-02-10 08:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=515542&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) >Assigned to: marc fleury (mnf999) Summary: getRemote in MBean view throws NPE Initial Comment: Basic info: INFO JBoss (MX MicroKernel) 3.0.0DR1(200202092237) [RABBIT-HOLE] ... 11:40:24,734 INFO [Info] Java version: 1.3.1_02,Sun Microsystems Inc. 11:40:24,734 INFO [Info] Java VM: Java HotSpot(TM) Client VM 1.3.1_02-b02,Sun Microsystems Inc. 11:40:24,734 INFO [Info] OS-System: Windows 2000 5.0,x86 Bug: EJBs are listed in the agent view, but clicking getRemote/getHome in the Bean View gives me on the console and the debug log: 2002-02-10 17:29:42,093 ERROR [org.jboss.ejb.EntityContainer] invoke returned an exception java.lang.NullPointerException at org.jboss.ejb.Container.invoke (Container.java:563) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:990) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Unknown Source) and of course an "472 MBean failure" The MBean [jboss.j2ee:service=EJB,jndiName=ejb/entities/Entity] throws an MBeanException when calling [getRemote]: java.lang.NullPointerException on the page. A grep on the debug log shows: server.log.1:2002-02-10 16:48:50,640 DEBUG [org.jboss.proxy.ejb.ProxyFactory] Bound EntityEB to ejb/entities/Entity And I cannot get access to any home interface from the client. The call does not even reach the server. But this may be a different story. Georg -- "I'm not living for you, I'm living for me." (Garland Jeffreys) -- >Comment By: Jason Dillon (user57) Date: 2002-02-13 00:17 Message: Logged In: YES user_id=15045 With the current optimization hacks around the container, any client that does not provide an Invocation object which contains the method call information will fail. Need to talk to Marc about this. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=515542&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-516835 ] pk constraint name too long
Bugs item #516835, was opened at 2002-02-13 00:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516835&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: pk constraint name too long Initial Comment: RH 20020212, W2K, Oracle 8.1.7. Supplying a broken jbosscmp-jdbc.xml reveals, that the CMP pk constraint name generation code does not take into account the maximum identifier length allowed by the underlying data source. It seems as if EB and pk field names are simply concatenated without looking at the length of the generated identifier. Georg -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516835&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] new container optimizations & bug [ #515542 ]
I was looking over this bug and realized that with the container optimizations you added that no JMX compliant client (or adapter) will function correctly unless they have been specifically coded to use our Invocation objects. I now understand what is going on here, I was confused at first because of the invoke() method looking like a Proxy IH, but it is part of the DynamicMBean API. Is this really what we want to be doing? Wouldn't it make more sense to provide a separate invoke-like method which functions with these optimizations? For example, if invoke(), did the normal thing of taking actionName and translating that into a method call, then a invokeOptimized(Invocation) could be used to speed things up for internal usage. It would still go through invoke, but the first thing it would do would check if actionName is "invokeOptimized", then branch to that method, which would do what invoke() does now. Else it could use the typical reflection fluff. In order for this to work, methods will have to be provided for each of the functionality which is currently swicthed. The optimized switch would call the method and the standard invoke would reflect to it. Since we don't need to expose any public here we could even make them private for any compile time speedups that would get us. Clients would then invoke the action "invokeOptimized" instead of passing in "" or garbage as they do now. I assigned the bug to you for the time being. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss Code Style Guide
> Off topic, but were you able to get NetBeans to build JBoss using its > ant fluff? I've never tried in fact... I always compile ant from the command line. One thing to add about netbeans: A problem with netbeans regarding JBoss structure is that JBoss has its source folders disseminated in many sub-folders of the jboss-all main folder. It is tiring because it means you have to add many many sub-folders by hand through at least 5 clicks each time. But I think there is a solution. If you look at the different plugins available for netbeans, one is still in beta but allows you to just bind the jboss-all folder once and then, right-click on the appropriate sub-folders (xxx/src/main) to add them to the list of available classpath. It is really easier, but still in beta. Cheesr, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/invocation Invocation.java
User: user57
Date: 02/02/13 01:13:34
Modified:src/main/org/jboss/invocation Invocation.java
Log:
o Added Invocation.INVOKE_SIGNATURE so we don't have to keep creating
new String[]'s
o Cleaned up LocalInvoker to use the ServiceMBeanSupport class properly
Revision ChangesPath
1.5 +90 -100 jboss/src/main/org/jboss/invocation/Invocation.java
Index: Invocation.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/invocation/Invocation.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Invocation.java 6 Feb 2002 20:59:27 - 1.4
+++ Invocation.java 13 Feb 2002 09:13:34 - 1.5
@@ -1,9 +1,10 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+
package org.jboss.invocation;
import java.util.Map;
@@ -13,90 +14,91 @@
import javax.transaction.Transaction;
-
/**
-* The Invocation object is the generic object flowing through our interceptors
-*
-* The heart of it is the payload map that can contain anything we then put
readers on them
-* The first "reader" is this "Invocation" object that can interpret the data in
it.
-*
-* Essentially we can carry ANYTHING from the client to the server, we keep a
series of
-* of predifined variables and method calls to get at the pointers. But really it
is just
-* a repository of objects.
-*
-* @see
-* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
-* @version $Revision: 1.4 $
-* Revisions:
-*
-* Revisions:
-*
-* 2001114 marc fleury:
-*
-*Initial check-in
-*
-*/
-
+ * The Invocation object is the generic object flowing through our interceptors.
+ *
+ * The heart of it is the payload map that can contain anything we then put
readers on them
+ *The first "reader" is this "Invocation" object that can interpret the data in
it.
+ *
+ * Essentially we can carry ANYTHING from the client to the server, we keep a
series of
+ *of predifined variables and method calls to get at the pointers. But really
it is just
+ *a repository of objects.
+ *
+ * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
+ * @version $Revision: 1.5 $
+ *
+ * Revisions:
+ *
+ * Revisions:
+ *
+ * 2001114 marc fleury:
+ *
+ *Initial check-in
+ *
+ */
public class Invocation
{
-
- // Attributes
+ /** The signature of the invoke() method */
+ public static final String[] INVOKE_SIGNATURE = { "java.lang.Object" };
/**
- * The payload is a repository of everything associated with the invocation
- * with the exception of the generic transaction and security information above.
- */
+* The payload is a repository of everything associated with the invocation
+* with the exception of the generic transaction and security information above.
+*/
public Map payload;
-
-
-
- // Static
-
+
+ //
+ // NOTE: The following comment style does not make for good javadocs!
+ //
/**
- * We are using the generic payload to store some of our data, we define some
integer entries.
- * These are just some variables that we define for use in "typed" getters and
setters.
- * One can define anything either in here explicitely or through the use of
external calls to getValue
- */
+* We are using the generic payload to store some of our data, we define some
integer entries.
+* These are just some variables that we define for use in "typed" getters and
setters.
+* One can define anything either in here explicitely or through the use of
external calls to getValue
+*/
public static final Integer
- // Transactional information with the invocation
- TRANSACTION = new Integer(new String("TRANSACTION").hashCode()),
- PRINCIPAL = new Integer(new String("PRINCIPAL").hashCode()),
- CREDENTIAL = new Integer(new String("CREDENTIAL").hashCode()),
-
- // We can keep a reference to an abstract "container" this invocation is
associated with
- CONTAINER = new Integer(new String("CONTAINER").hashCode()),
- // The type can be any qualifier for the invocation, anything (used in EJB)
- TYPE = new Integer(new String("TYPE").hashCode()),
- // The Cache-ID associates an instance in cache somewhere on the server with
this invocation
- CACHE_ID = new Integer(new String("CACHE_ID").hashCode()),
- // The invocation can be a method invocation, we give the method to call
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss/invocation/local LocalInvoker.java
User: user57
Date: 02/02/13 01:13:35
Modified:src/main/org/jboss/invocation/local LocalInvoker.java
Log:
o Added Invocation.INVOKE_SIGNATURE so we don't have to keep creating
new String[]'s
o Cleaned up LocalInvoker to use the ServiceMBeanSupport class properly
Revision ChangesPath
1.5 +52 -108 jboss/src/main/org/jboss/invocation/local/LocalInvoker.java
Index: LocalInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/invocation/local/LocalInvoker.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- LocalInvoker.java 7 Feb 2002 07:48:49 - 1.4
+++ LocalInvoker.java 13 Feb 2002 09:13:34 - 1.5
@@ -1,11 +1,11 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
-package org.jboss.invocation.local;
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+package org.jboss.invocation.local;
import java.net.InetAddress;
import javax.management.ObjectName;
@@ -24,140 +24,84 @@
import org.jboss.logging.Logger;
/**
-* The Invoker is a local gate in the JMX system.
-*
-* @author mailto:[EMAIL PROTECTED]>Marc Fleury
-*
-* @version $Revision: 1.4 $
-*
-*/
-
+ * The Invoker is a local gate in the JMX system.
+ *
+ * @author mailto:[EMAIL PROTECTED]>Marc Fleury
+ * @version $Revision: 1.5 $
+ */
public class LocalInvoker
-extends ServiceMBeanSupport
-implements Invoker, LocalInvokerMBean
+ extends ServiceMBeanSupport
+ implements Invoker, LocalInvokerMBean
{
- // Constants -
- protected static Logger log = Logger.getLogger(LocalInvoker.class);
-
- // Attributes
-
- // The MBean Server
- protected MBeanServer server;
-
- // The ObjectName for the local invoker
- protected ObjectName name;
- // Static
-
- // Constructors --
-
- // Public
-
- // Service implementation ---
-
- public String getName() { return "LocalInvoker";}
-
- public void create()
- throws Exception
+ protected void createService() throws Exception
{
- //note on design: We need to call it ourselves as opposed to letting the
client JRMPDelegate look it
- // up through the use of Registry, the reason being including the classes in
the client.
- // If we move to a JNDI format (with local calls) for the registry we could
remove the call below
+ // note on design: We need to call it ourselves as opposed to
+ // letting the client JRMPDelegate look it
+ // up through the use of Registry, the reason being including
+ // the classes in the client.
+ // If we move to a JNDI format (with local calls) for the
+ // registry we could remove the call below
JRMPInvokerProxy.setLocal(this);
- Registry.bind(name, this);
+ Registry.bind(serviceName, this);
}
-
- public void start()
- throws Exception
+ protected void startService() throws Exception
{
-
- GenericProxy.setTransactionManager((TransactionManager)new
InitialContext().lookup("java:/TransactionManager"));
-
+ InitialContext ctx = new InitialContext();
+ try {
+ TransactionManager tm =
(TransactionManager)ctx.lookup("java:/TransactionManager");
+ GenericProxy.setTransactionManager(tm);
+ }
+ finally {
+ ctx.close();
+ }
+
log.debug("Local invoker for JMX node started");
}
- public void stop()
- {
- }
-
- public void destroy()
+ protected void destroyService()
{
- Registry.unbind(name);
+ Registry.unbind(serviceName);
}
// Invoker implementation
public String getServerHostName()
{
- try {return InetAddress.getLocalHost().getHostName();}
-
- catch (Exception ignored) {return null;}
+ try {
+ return InetAddress.getLocalHost().getHostName();
+ }
+ catch (Exception ignored) {
+ return null;
+ }
}
-
/**
- * Invoke a method.
- */
- public Object invoke(Invocation invocation)
- throws Exception
+* Invoke a method.
+*/
+ public Object invoke(Invocation invocation) throws Exception
{
-
[JBoss-dev] JBossCMP, tag on custom EJB-QL finders
..is ignored completely. Shall I file a bugreport, or it that a known or already fixed one? Christopher -- .Digital.Yearning.for.Networked.Assassination.and.Xenocide ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: juhalindfors Date: 02/02/13 03:07:02 Modified:.modules Log: added log4j to jboss-mx checkout Revision ChangesPath 1.87 +2 -1 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.86 retrieving revision 1.87 diff -u -r1.86 -r1.87 --- modules 5 Feb 2002 02:03:53 - 1.86 +++ modules 13 Feb 2002 11:07:02 - 1.87 @@ -200,7 +200,8 @@ thirdparty/oswego \ thirdparty/junit \ thirdparty/jdom \ -thirdparty/sun/jmx +thirdparty/sun/jmx \ +thirdparty/apache/log4j _jboss-mx-modules -a \ _jboss-mx_build \ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jmx build.xml
> User: user57 > Date: 02/02/12 20:14:08 > > Modified:.build.xml > Log: > o if these classes don't need to be built then why > hy are they there? > because the tests won't work correctly if those classes are in the system classpath instead of loaded dynamically. Please add the removed tags back or replace it with a similar functionality. Ask before you change, please. -- Juha _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=5587 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-516953 ] setRollbackOnly() in sfsb behaviour
Bugs item #516953, was opened at 2002-02-13 05:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516953&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chris Harris (charris) Assigned to: Nobody/Anonymous (nobody) Summary: setRollbackOnly() in sfsb behaviour Initial Comment: JBoss 2.4.3, JDK1.3.1 on Win2000. The attached file contains a simple sfsb with a single method that calls EJBContext.setRollbackOnly(). Two consecutive calls to this method from an ordinary java client result in the following exception propagated back to the client: = java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackExceptio n: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans javax.transaction.TransactionRolledbackException: Application Error: no concurrent calls on stateful beans; nested exception is: java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans java.rmi.RemoteException: Application Error: no concurrent calls on stateful beans at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro mServer(StreamRemoteCall.java:245) at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_ Stub.invoke(Unknown Source) at org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo keContainer(GenericProxy.java:357) at org.jboss.ejb.plugins.jrmp.interfaces.StatefulSessionPr oxy.invoke(StatefulSessionProxy.java:136) at $Proxy1.error(Unknown Source) at com.lombardrisk.trading.test.StatefulTestBeanTest.main (StatefulTestBeanTest.java:24) == On the server, this exception is preceded by: === [StatefulSessionEnterpriseContext] locked < 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(TCPTransport.java:706) at java.lang.Thread.run(Thread.java:484) [StatefulSessionEnterpriseContext] locked < 0 java.lang.Throwable at org.jboss.ejb.EnterpriseContext.unlock (EnterpriseContext.java:170) at org.jboss.ejb.plugins.StatefulSessionInstanceIntercepto r$InstanceSynchronization.afterCom pletion(StatefulSessionInstanceInterceptor.java:410) at tyrex.tm.impl.TransactionImpl.forget (TransactionImpl.java:2009) at tyrex.tm.impl.TransactionImpl.rollback (TransactionImpl.java:541) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:352) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:99) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:195) at org.jboss.ejb.StatefulSessionContainer.invoke (StatefulSessionContainer.java:341) at org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker. invoke(JRMPContainerInvoker.java:3 95) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run (Transport.java:152) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages (TCPTransport.java:465) at
[JBoss-dev] [ jboss-Bugs-516707 ] Undeploy Broken on MacOS X
Bugs item #516707, was opened at 2002-02-12 15:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516707&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hunter Hillegas (hunterhillegas) Assigned to: David Jencks (d_jencks) Summary: Undeploy Broken on MacOS X Initial Comment: The new deployer doesn't seem to undeploy reliably on MacOS X. When an ear is removed from the deploy directory, nothing happens. This worked fine before the new deployer was implemented so I don't think it is a MacOS X JVM bug. Even if it is, Apple probably won't fix it unless we can tell them where the bug is. -- >Comment By: David Jencks (d_jencks) Date: 2002-02-13 06:13 Message: Logged In: YES user_id=60525 I don't understand the previous comment. Do you claim this is still broken on w2k? It appears fixed to me on linux and mac osx. If you find it is broken, please state so very clearly with an example. -- Comment By: Georg Schmid (giorgio42) Date: 2002-02-13 00:11 Message: Logged In: YES user_id=437570 The same on W2K, no reaction at all on removing the ejb jar. Georg -- Comment By: David Jencks (d_jencks) Date: 2002-02-12 19:39 Message: Logged In: YES user_id=60525 I guess we need a test case to keep people from breaking the most basic functionality. -- Comment By: Hunter Hillegas (hunterhillegas) Date: 2002-02-12 15:33 Message: Logged In: YES user_id=7380 It looks like it is the same story for deploying new ears placed in the directory after the server has started... They are never noticed... Again, this worked fine before the deployer re-write. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516707&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-515537 ] Deployer loops on failed deployment
Bugs item #515537, was opened at 2002-02-10 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=515537&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: David Jencks (d_jencks) Summary: Deployer loops on failed deployment Initial Comment: Deployer loops on failed deployment Basic info: INFO JBoss (MX MicroKernel) 3.0.0DR1(200202092237) [RABBIT-HOLE] ... 11:40:24,734 INFO [Info] Java version: 1.3.1_02,Sun Microsystems Inc. 11:40:24,734 INFO [Info] Java VM: Java HotSpot(TM) Client VM 1.3.1_02-b02,Sun Microsystems Inc. 11:40:24,734 INFO [Info] OS-System: Windows 2000 5.0,x86 Bug: Failed deployment puts Deployer into endless loop. Although the deployment fails, the deployer puts it on the watch list and treats it as if the deployment succeeded: 2002-02-10 12:34:52,265 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.Mainte nanceEB] jar:file:/I:/jboss/jboss- 3.0.0DR1/tmp/deploy/66.entity-beans.jar!/META- INF/jbosscmp-jdbc.xml found. Overriding defaults 2002-02-10 12:34:52,625 ERROR [org.jboss.ejb.EJBDeployer] Could not deploy file:/I:/jboss/jboss-3.0.0DR1/deploy/entity-beans.jar org.jboss.deployment.DeploymentException: Role: module- belongs-to-facility with multiplicity many using foreign-key mapping is not allowed to have key-fields at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationshi pRoleMetaData.loadKeyFields (JDBCRelationshipRoleMetaData.java:352) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationshi pRoleMetaData.init (JDBCRelationshipRoleMetaData.java:157) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationMet aData.(JDBCRelationMetaData.java:308) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCApplication MetaData.(JDBCApplicationMetaData.java:383) at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCXmlFileLoad er.load(JDBCXmlFileLoader.java:75) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadJDB CEntityMetaData(JDBCStoreManager.java:503) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.create (JDBCStoreManager.java:277) at org.jboss.ejb.plugins.CMPPersistenceManager.create (CMPPersistenceManager.java:134) at org.jboss.ejb.EntityContainer.create (EntityContainer.java:342) at org.jboss.ejb.Application.start (Application.java:214) at org.jboss.ejb.EJBDeployer.deploy (EJBDeployer.java:431) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:396) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:362) at org.jboss.deployment.MainDeployer.scan (MainDeployer.java:243) at org.jboss.deployment.MainDeployer.run (MainDeployer.java:229) at java.lang.Thread.run(Unknown Source) 2002-02-10 12:34:52,937 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/I:/jboss/jboss-3.0.0DR1/deploy/entity-beans.jar 2002-02-10 12:34:52,937 WARN [org.jboss.deployment.MainDeployer] operation failed; ignoring java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.stop (JDBCStoreManager.java:346) at org.jboss.ejb.plugins.CMPPersistenceManager.stop (CMPPersistenceManager.java:180) at org.jboss.ejb.EntityContainer.stop (EntityContainer.java:408) at org.jboss.ejb.Application.stop (Application.java:240) at org.jboss.ejb.EJBDeployer.deploy (EJBDeployer.java:444) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:396) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:362) at org.jboss.deployment.MainDeployer.scan (MainDeployer.java:243) at org.jboss.deployment.MainDeployer.run (MainDeployer.java:229) at java.lang.Thread.run(Unknown Source) 2002-02-10 12:35:03,437 INFO [org.jboss.deployment.MainDeployer] Undeploying file:/I:/jboss/jboss-3.0.0DR1/deploy/entity-beans.jar 2002-02-10 12:35:03,437 ERROR [org.jboss.deployment.MainDeployer] Undeployment failed: file:/I:/jboss/jboss-3.0.0DR1/deploy/entity- beans.jar org.jboss.deployment.DeploymentException: URL not deployed at org.jboss.ejb.EJBDeployer.undeploy (EJBDeployer.java:472) at org.jboss.ejb.EJBDeployer.undeploy (EJBDeployer.java:461) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:315) at org.jboss.deployment.MainDeployer.scan (MainDeployer.java:258) at org.jboss.deployment.MainDeployer.run (MainDeployer.java:229) at java.lang.Thread.run(Unknown Source) 2002-02-10 12:35:08,562 INFO [org.jboss.deployment.MainDeployer] Undeploying file:/I:/jboss/jboss-3.0.0DR1/deploy/entity-beans.jar 2002-02-10 12:35:08,578 ERROR [org.jboss.deployment.MainDeployer] Undeployment failed: file:/I:/jboss/jboss-3.0.0DR1/deploy/entity- beans.jar org.jboss.deployment.DeploymentException: URL not deployed at org.jboss.ejb.EJBDeployer
[JBoss-dev] Syntax error in jboss.xml....
hi there, i have problem with deploying my session bean. i get following repport form jboss: - [ERROR,XmlFileLoader] failed to load jboss.xml. There could be a syntax error. [ERROR,ContainerFactory] DeploymentError org.jboss.deployment.DeploymentException: Error in jboss.xml for Bean Scheduler: found in jboss.xml but not in ejb-jar.xml at org.jboss.metadata.ApplicationMetaData.importJbossXml(ApplicationMeta Data.java:387) at org.jboss.metadata.XmlFileLoader.load(XmlFileLoader.java:186) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:436) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:369) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:306) at java.lang.reflect.Method.invoke(Native Method) - my ejb-jar.xml has something like that: SchedulerEJB com.videlity.session.SchedulerHome com.videlity.session.Scheduler com.videlity.session.SchedulerBean Stateful Container ejb/Event Entity com.videlity.entity.event.EventHome com.videlity.entity.event.Event Event ejb/EventInstance Entity entity.event_instance.EventInstanceHome event_instance.EventInstance EventInstance and my jboss.xml has something like that: SchedulerEJB ejb/Scheduler what is wrong ? regards, piotr _ View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=8441 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] bug in ear deployment
If I got it right, the following happens during deployment of an ear: 1. the MainDeployer unpacks the ear and iterates over the modules 2. the MainDeployer retrieves an apropriate deployer for each module (e.g. EJBDeployer) and invokes the method "deploy" on it 3. The EJBDeployer creates an Application for its ejb-jar and _starts_ it! 4. The Application initializes, _creates_ and starts a Container for every bean 5. The create Method invokes setupEnvironment 6. during setupEnvironment the ejb-links are resolved getApplication(). So there's one Application per ejb-jar, instead of one Application per ear. That's a problem: If the ear contained two ejb-jars and an ejb from the first jar "ejb-ref"-links an ejb from the second jar, the link cannot be resolved: getApplication().getContainer(ref.getLink()) .. will fail, because the two beans are in different applications. If I'm right, the EJBDeployer should not instantiate a separate Application for each ejb-jar, but share one Application instance per ear-File. If that's not possible, the Applications could be arranged hierarchically. All ejb-jar Applications from one ear have one ear Application as parent. Anyway, there must be a unit, that maps all ejb-names from all modules of an ear to the appropriate Containers. The Application can be started, after all modules of the container are deployed. Holger ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-517018 ] forced cmp-field init during create
Bugs item #517018, was opened at 2002-02-13 07:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517018&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Thomas Hamann (thomash76) Assigned to: Nobody/Anonymous (nobody) Summary: forced cmp-field init during create Initial Comment: windows 2000; jdk1.3.1_01; JBoss 3.0.0DR1(2-13-2002; GMT 10:00); Hi, i tried to create instance of an entity bean, but all i got was exceptions until i initialized all cmp fields during the ejbCreate() method of that bean. such a bug is not really severe because an initialization should always be possible (at least with default values) but according to the ejb specification the application provider does not have to initialize the cmp-fields. i checked whether the problem is in the database or in Jboss... the db allows creation of rows such as (xyz, null, null) - Jboss not! when encountering a null valued cmp-field the process of sql query composition stops and the creation of the bean instance is unsuccessful - see log output. (this was the actual problem of bug #516404 "invalid type mapping") 2002-02-13 15:51:57,243 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.jatek/GlossaryEntry] Create: pk=Reference [uid: 2176] 2002-02-13 15:51:57,258 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.jatek/GlossaryEntry] Executing SQL: SELECT COUNT(*) FROM GLOSSARYENTRY WHERE uid_column=? 2002-02-13 15:51:57,258 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.jatek/GlossaryEntry.uid] Set parameter: index=1, jdbcType=BIGINT, value=2176 2002-02-13 15:51:57,258 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.jatek/GlossaryEntry] Executing SQL: INSERT INTO GLOSSARYENTRY (uid_column, allowedUsers_column, allowedGroups_column, deniedUsers_column, deniedGroups_column, par_column, pos_column, ver_column, scr_column, typLearnTime_column, matData_column) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) 2002-02-13 15:51:57,258 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.jatek/GlossaryEntry.uid] Set parameter: index=1, jdbcType=BIGINT, value=2176 2002-02-13 15:51:57,258 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.jatek/GlossaryEntry.allowedUsers] Set parameter: index=2, jdbcType=JAVA_OBJECT, value=NULL 2002-02-13 15:51:57,493 ERROR [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.jatek/GlossaryEntry] Could not create entity javax.ejb.EJBException: Internal error setting parameters for field allowedUsers Embedded Exception Ungültiger Spaltentyp at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setArgumentParameters(JDBCAbs tractCMPFieldBridge.java:238) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setInstanceParameters(JDBCAbst ractCMPFieldBridge.java:211) at ... seems like there's a problem in org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil at line 144 btw.: my "old" version of JBoss 3.0.0DR1 managed to create the tables itself by using the specified type mapping - the new one (from this morning) doesn't - any clue? Thanks for the support yesterday! Thomas -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517018&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-517062 ] JAWS ResultSet Column Order
Bugs item #517062, was opened at 2002-02-13 09:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517062&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Michael Prescott (fuseboy) Assigned to: Nobody/Anonymous (nobody) Summary: JAWS ResultSet Column Order Initial Comment: The free and otherwise decent Microsoft JDBC Driver for SQL Server 2000 (they've licensed Merant's driver) has a limitation that requires that 'TEXT' fields be retrieved from ResultSets in the order that they're specified in the SELECT statement. JAWS composes the SELECT statement based on the order that CMP fields are returned from a Hashtable (effectively an undefined order), but moves primary key fields to be the first columns in the SELECT statement. (See http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jboss/src/main/org/jboss/ejb/plug ins/jaws/jdbc/JDBCLoadEntityCommand.java?annotate=1.18 lines 214-242). On retrieval, however, it doesn't retrieve the primary key columns first, it retrieves them in the Hashtable order. Is there any reason for this, or can I submit a patch that causes the retrieval order to match the SELECT column order? There are numerous workarounds, from changing the name of the pk columns until the hash causes them to come out first (a flaky hack) to changing the JDBC driver, but this since the Microsoft driver is likely to be come the default for SQL Server installations it strikes me as an important compatability issue. Incidentally, lines 215-221 don't seem to have any effect, nor have they done since they were written. Am I just on crack? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517062&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BCEL & org.jboss.proxy.compiler
I've just submitted patch 517088 to completely remove the jboss proxy compiler
and replace it with use of java.lang.reflect.Proxy.
The BCEL looks pretty good for all sorts of stuff, but the JDK Proxy class
does everything that the JBoss one does.
An 'interesting' use of the BCEL would be to post process the .class files
before deployment for production and completely remove the
if (log.isDebugEnabled()) {
...
}
code from the .class file.
I can't get too excited after the miniscule performance increase you'd get
from this (I've followed the log4j discussions on this in the past on this
list and others). but as an intellectual exercise it might be quite
interesting to do...
On Mon, Feb 11, 2002 at 08:35:44PM -0800, Jason Dillon wrote:
> Any thoughts on replacing our proxy compiler with the Byte Code
> Engineering Library, recently added to the list of Jakarta
> sub-projects?
>
> --jason
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
--
regards
Neale Swinnerton
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-516684 ] CCE on redeployment of ear with sar/ejb
Bugs item #516684, was opened at 2002-02-12 14:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: CCE on redeployment of ear with sar/ejb Initial Comment: The perf-service.ear in the current main testsuite is not usable across redeployments. Steps to reproduce: 1. Deploy the perf-service.ear and then execute the jboss.test:service=PerfTest runTests(100) operation. Ignore the NPE shown under testTimings. 2. Simply touch the perf-service.ear and then execute the runTests(100) operation again on the jboss.test:service=PerfTest mbean, you will see: +++ testTimingsCMT() testTimingsCMT failed: java.lang.ClassCastException: $Proxy19 at org.jboss.test.perf.test.PerfTest.testTimingsCMT (PerfTest.java:134) at org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:66) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Thread.java:484) -- >Comment By: David Jencks (d_jencks) Date: 2002-02-13 09:12 Message: Logged In: YES user_id=60525 I notice that you can redeploy many times successfully as long as you don't run the test. Once you have run the test, after redeploying, the test fails. deploy redeploy redeploy run test (succeeds) redeploy run test (fails) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-517088 ] Remove org.jboss.proxy.compiler.*
Patches item #517088, was opened at 2002-02-13 10:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517088&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neale Swinnerton (neales) Assigned to: Nobody/Anonymous (nobody) Summary: Remove org.jboss.proxy.compiler.* Initial Comment: Jason Dillon Suggested replacing the jboss proxy compiler with the the BCEL (BInary Code Engineering Library) from Apache on the jboss-dev mailing list on Feb 11. I investigated this and found that there is nothing in the jboss proxy compiler that can't be acheived using the java.lang.reflect.Proxy class (and friends). I think this proxy compiler is a throwback to before the dynamic proxy support was introduced in JDK1.3. Since JDK1.3 is the minimum JDK for jboss these days we can use the inbuilt support. This patch makes the mods to the code. In addition to the patch you'll have to cvs remove -f server/src/main/org/jboss/proxy/* since I can't do this on my machine without cvs RW perms and get it in the diff. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517088&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] BCEL & org.jboss.proxy.compiler
I believe the one thing that the java.lang.reflect.Proxy won't do that
JBoss needs is to generate implementations of abstract classes (rather
than interfaces) this is important in a few places (EJB 2.0 CMP for one)
danch
Neale Swinnerton wrote:
> I've just submitted patch 517088 to completely remove the jboss proxy compiler
> and replace it with use of java.lang.reflect.Proxy.
>
> The BCEL looks pretty good for all sorts of stuff, but the JDK Proxy class
> does everything that the JBoss one does.
>
> An 'interesting' use of the BCEL would be to post process the .class files
> before deployment for production and completely remove the
>
> if (log.isDebugEnabled()) {
> ...
> }
>
> code from the .class file.
>
> I can't get too excited after the miniscule performance increase you'd get
> from this (I've followed the log4j discussions on this in the past on this
> list and others). but as an intellectual exercise it might be quite
> interesting to do...
>
>
> On Mon, Feb 11, 2002 at 08:35:44PM -0800, Jason Dillon wrote:
>
>>Any thoughts on replacing our proxy compiler with the Byte Code
>>Engineering Library, recently added to the list of Jakarta
>>sub-projects?
>>
>>--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-dev] [ jboss-Bugs-516684 ] CCE on redeployment of ear with sar/ejb
Bugs item #516684, was opened at 2002-02-12 14:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: CCE on redeployment of ear with sar/ejb Initial Comment: The perf-service.ear in the current main testsuite is not usable across redeployments. Steps to reproduce: 1. Deploy the perf-service.ear and then execute the jboss.test:service=PerfTest runTests(100) operation. Ignore the NPE shown under testTimings. 2. Simply touch the perf-service.ear and then execute the runTests(100) operation again on the jboss.test:service=PerfTest mbean, you will see: +++ testTimingsCMT() testTimingsCMT failed: java.lang.ClassCastException: $Proxy19 at org.jboss.test.perf.test.PerfTest.testTimingsCMT (PerfTest.java:134) at org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:66) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Thread.java:484) -- >Comment By: Scott M Stark (starksm) Date: 2002-02-13 10:17 Message: Logged In: YES user_id=175228 That is correct. -- Comment By: David Jencks (d_jencks) Date: 2002-02-13 09:12 Message: Logged In: YES user_id=60525 I notice that you can redeploy many times successfully as long as you don't run the test. Once you have run the test, after redeploying, the test fails. deploy redeploy redeploy run test (succeeds) redeploy run test (fails) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Failed to Setup ENC
Still seems broken from here... When I deploy the second ear I see this: 11:45:52,174 ERROR [JBossWebApplicationContext#/vagrant-admin] failed to setup ENC javax.naming.NameAlreadyBoundException; remaining name 'env' at org.jnp.server.NamingServer.createSubcontext(NamingServer.java:451) at org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:664) at org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:650) at org.jboss.web.AbstractWebContainer.parseWebAppDescriptors(AbstractWebContain er.java:503) at org.jboss.web.AbstractWebContainer$DescriptorParser.parseWebAppDescriptors(A bstractWebContainer.java:706) at org.jboss.jetty.JBossWebApplicationContext.setUpENC(JBossWebApplicationConte xt.java:324) at org.jboss.jetty.JBossWebApplicationContext.startHandlers(JBossWebApplication Context.java:283) at org.mortbay.http.HttpContext.start(HttpContext.java:1341) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. java:428) at org.jboss.jetty.Jetty.deploy(Jetty.java:270) at org.jboss.jetty.JettyService.performDeploy(JettyService.java:284) at org.jboss.web.AbstractWebContainer.deploy(AbstractWebContainer.java:366) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:457) at org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:791) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:452) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:412) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:271) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:258) at java.lang.Thread.run(Thread.java:496) > From: "Scott M Stark" <[EMAIL PROTECTED]> > Organization: JBoss Group > Reply-To: "Scott M Stark" <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2002 23:34:36 -0800 > To: "JBoss Dev" <[EMAIL PROTECTED]> > Subject: Re: [JBoss-dev] Failed to Setup ENC > > I just tried deploying the tomcat-test.ear twice with different > contexts for the war included in the ear, and I do not see this > problem. The stack traces no longer match the current code > so refresh, retry and then report back. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Hunter Hillegas" <[EMAIL PROTECTED]> > To: "JBoss Dev" <[EMAIL PROTECTED]> > Sent: Tuesday, February 12, 2002 3:24 PM > Subject: [JBoss-dev] Failed to Setup ENC > > >> I have two EARs to deploy... >> >> Each one contains two wars and and ejb-jar. One of the wars in each ear is >> our content management system... Since a tree refresh a couple of weeks > back >> I am getting the trace below when I deploy the second ear... >> >> While both ears have a copy of the content management war in them (they > are >> for different Web sites), they have different contexts specified in the >> application.xml file in the ear... >> >> Is it illegal to have two different wars, with the same name, in two >> different ears, even if mapped differently in the application.xml file? >> >> 15:20:08,721 ERROR [JBossWebApplicationContext#/badreligion] failed to > setup >> ENC >> javax.naming.NameAlreadyBoundException >> at org.jnp.server.NamingServer.bind(NamingServer.java:130) >> at org.jnp.interfaces.NamingContext.bind(NamingContext.java:330) >> at org.jnp.interfaces.NamingContext.bind(NamingContext.java:302) >> at >> > org.jboss.web.AbstractWebContainer.parseWebAppDescriptors(AbstractWebContain >> er.java:479) >> at >> > org.jboss.web.AbstractWebContainer$DescriptorParser.parseWebAppDescriptors(A >> bstractWebContainer.java:682) >> at >> > org.jboss.jetty.JBossWebApplicationContext.setUpENC(JBossWebApplicationConte >> xt.java:324) >> at >> > org.jboss.jetty.JBossWebApplicationContext.startHandlers(JBossWebApplication >> Context.java:283) >> at org.mortbay.http.HttpContext.start(HttpContext.java:1341) >> at >> > org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext. >> java:428) >> at org.jboss.jetty.Jetty.deploy(Jetty.java:270) >> at > org.jboss.jetty.JettyService.performDeploy(JettyService.java:284) >> at >> org.jboss.web.AbstractWebContainer.deploy(AbstractWebContainer.java:345) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:453) >> at >> org.jboss.deployment.MainDeployer.deploySubPackages(MainDeployer.java:798) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:448) >> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:408) >> at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:269) >> at org.jboss.deployment.MainDeployer.run(MainDeployer.java:247) >> at java.lang.Thread.run(Thread.java:496) >> >> >>
Re: [JBoss-dev] BCEL & org.jboss.proxy.compiler
Yep this package is an absolute requirement of CMP 2.0. The
java.lang.reflect.Proxy package can't generate a subclass of an abstract
class, and this is where BCEL could take over.
If you want to look into writing a replacement with BCEL that would be
very cool (they do have a sample dynamic proxy generator).
-dain
danch wrote:
> I believe the one thing that the java.lang.reflect.Proxy won't do that
> JBoss needs is to generate implementations of abstract classes (rather
> than interfaces) this is important in a few places (EJB 2.0 CMP for one)
>
> danch
>
> Neale Swinnerton wrote:
>
>> I've just submitted patch 517088 to completely remove the jboss proxy
>> compiler
>> and replace it with use of java.lang.reflect.Proxy.
>>
>> The BCEL looks pretty good for all sorts of stuff, but the JDK Proxy
>> class
>> does everything that the JBoss one does.
>> An 'interesting' use of the BCEL would be to post process the .class
>> files
>> before deployment for production and completely remove the
>> if (log.isDebugEnabled()) {
>> ...
>> }
>>
>> code from the .class file.
>>
>> I can't get too excited after the miniscule performance increase you'd
>> get
>> from this (I've followed the log4j discussions on this in the past on
>> this
>> list and others). but as an intellectual exercise it might be quite
>> interesting to do...
>>
>>
>> On Mon, Feb 11, 2002 at 08:35:44PM -0800, Jason Dillon wrote:
>>
>>> Any thoughts on replacing our proxy compiler with the Byte Code
>>> Engineering Library, recently added to the list of Jakarta
>>> sub-projects?
>>> --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: contrib/iiop/src/main/org/jboss/proxy/compiler - New directory
User: reverbel Date: 02/02/13 12:12:14 contrib/iiop/src/main/org/jboss/proxy/compiler - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/proxy/compiler IIOPStubCompiler.java Util.java
User: reverbel
Date: 02/02/13 12:21:46
Added: iiop/src/main/org/jboss/proxy/compiler IIOPStubCompiler.java
Util.java
Log:
Moving IIOP stub compiler classes from the org.jboss.proxy package:
org.jboss.proxy.IIOPStubCompiler -> org.jboss.proxy.compiler.IIOPStubCompiler
org.jboss.proxy.Util -> org.jboss.proxy.compiler.Util
Revision ChangesPath
1.1
contrib/iiop/src/main/org/jboss/proxy/compiler/IIOPStubCompiler.java
Index: IIOPStubCompiler.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.proxy.compiler; // IIOPStubCompiler is in this package
// because it calls some ProxyAssembler
// methods that currently are package
// accessible
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.rmi.RemoteException;
import org.jboss.iiop.rmi.AttributeAnalysis;
import org.jboss.iiop.rmi.ExceptionAnalysis;
import org.jboss.iiop.rmi.InterfaceAnalysis;
import org.jboss.iiop.rmi.OperationAnalysis;
import org.jboss.iiop.rmi.RMIIIOPViolationException;
import org.jboss.ejb.plugins.iiop.CDRStream;
import org.jboss.ejb.plugins.iiop.client.DynamicStub;
import org.jboss.ejb.plugins.iiop.client.StubStrategy;
/**
* Utility class responsible for the dynamic generation of bytecodes of
* IIOP stub classes.
*
* @author Unknown
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
* @version $Revision: 1.1 $
*/
public class IIOPStubCompiler
{
// Constants --
/**
* Parameter type array for StubStrategy.forMethod()
* invocations.
*/
private static final Class[] stubStrategyParams = {
String[].class, String[].class, String[].class, String.class,
ClassLoader.class
};
/**
* Parameter type array for DynamicStub.invoke() invocations.
*/
private static final Class[] invokeParams = {
String.class, StubStrategy.class, Object[].class
};
/**
* Parameter type array for
* org.omg.CORBA.ORB.object_to_string() invocations.
*/
private static final Class[] corbaObjectParam = {
org.omg.CORBA.Object.class
};
/**
* Parameter type array for a method that takes a single string parameter.
*/
private static final Class[] stringParam = {
String.class
};
/**
* Parameter type array for a method that takes no parameters.
*/
private static final Class[] noParams = { };
// Private methods
/**
* Returns the name of the stub strategy field associated with the method
* whose index is methodIndex.
*/
private static String strategy(int methodIndex) {
return "$s" + methodIndex;
}
/**
* Returns the name of static initializer method associated with the method
* whose index is methodIndex.
*/
private static String init(int methodIndex) {
return "$i" + methodIndex;
}
/**
* Generates the code of a given method within a stub class.
*
* @param asm the ProxyAssembler used to assemble
* the method code
* @param superclassthe superclass of the stub class within which the
* method will be generated
* @param m a Method instance describing the
* method declaration by an RMI/IDL interface
* @param idlName a string with the method name mapped to IDL
* @param strategyField a string with the name of the strategy field that
* will be associated with the generated method
* @param initMethoda string with the name of the static initialization
* method that will be associated with the generated
* method.
*/
private static void generateMethodCode(ProxyAssembler asm,
Class superclass,
Method m,
String idlName,
String strategyField,
String initMethod)
{
String methodName = m.getName();
Class returnType = m.getReturnType();
Class[] paramTypes = m.getParameterTypes();
Class[] exceptions = m.getExceptionTypes();
// Generate a static field with the StubStrategy for the method
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/proxy IIOPStubCompiler.java Util.java
User: reverbel Date: 02/02/13 12:21:46 Removed: iiop/src/main/org/jboss/proxy IIOPStubCompiler.java Util.java Log: Moving IIOP stub compiler classes from the org.jboss.proxy package: org.jboss.proxy.IIOPStubCompiler -> org.jboss.proxy.compiler.IIOPStubCompiler org.jboss.proxy.Util -> org.jboss.proxy.compiler.Util ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client DynamicStub.java StubClassLoader.java
User: reverbel Date: 02/02/13 12:45:34 Modified:iiop/src/main/org/jboss/ejb/plugins/iiop/client DynamicStub.java StubClassLoader.java Log: - org.jboss.proxy.IIOPStubCompiler moved to org.jboss.proxy.compiler.IIOPStubCompiler. - JacORB now privides the standard class org.omg.CORBA.LocalObject, so we now use this class rather than the JacORB-specific org.jacorb.orb.LocalityConstrainedObject. - "Hardwired" JNDI names for the ORB and the home POA replaced by constant strings defined in org.jboss.iiop.CorbaORBService. - Interface repository is now being bound to JNDI. Revision ChangesPath 1.5 +2 -2 contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java Index: DynamicStub.java === RCS file: /cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/DynamicStub.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- DynamicStub.java 26 Nov 2001 23:41:21 - 1.4 +++ DynamicStub.java 13 Feb 2002 20:45:33 - 1.5 @@ -17,7 +17,7 @@ import org.jboss.ejb.plugins.iiop.HandleImpl; import org.jboss.ejb.plugins.iiop.HomeHandleImpl; import org.jboss.ejb.plugins.iiop.LocalInvoker; -import org.jboss.proxy.InvocationHandler; +import org.jboss.proxy.compiler.InvocationHandler; /** * Dynamically generated IIOP stub classes extend this abstract superclass, @@ -33,7 +33,7 @@ * of operation parameters. * * @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel - * @version $Revision: 1.4 $ + * @version $Revision: 1.5 $ */ public abstract class DynamicStub extends javax.rmi.CORBA.Stub 1.2 +2 -2 contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/StubClassLoader.java Index: StubClassLoader.java === RCS file: /cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/client/StubClassLoader.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- StubClassLoader.java 28 Aug 2001 22:19:00 - 1.1 +++ StubClassLoader.java 13 Feb 2002 20:45:33 - 1.2 @@ -6,7 +6,7 @@ */ package org.jboss.ejb.plugins.iiop.client; -import org.jboss.proxy.IIOPStubCompiler; +import org.jboss.proxy.compiler.IIOPStubCompiler; /** * This class loader dynamically generates and loads client stub classes. @@ -14,7 +14,7 @@ * Should not be necessary when the IORs contain a JAVA_CODE_BASE tag. * * @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel - * @version $Revision: 1.1 $ + * @version $Revision: 1.2 $ */ public class StubClassLoader extends ClassLoader ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server CodebaseInterceptor.java CodebaseInterceptorInitializer.java CodebasePolicy.java CodebasePolicyFactory.java IIOPContainerInvoker.java
User: reverbel
Date: 02/02/13 12:45:34
Modified:iiop/src/main/org/jboss/ejb/plugins/iiop/server
CodebaseInterceptor.java
CodebaseInterceptorInitializer.java
CodebasePolicy.java CodebasePolicyFactory.java
IIOPContainerInvoker.java
Log:
- org.jboss.proxy.IIOPStubCompiler moved to
org.jboss.proxy.compiler.IIOPStubCompiler.
- JacORB now privides the standard class org.omg.CORBA.LocalObject, so
we now use this class rather than the JacORB-specific
org.jacorb.orb.LocalityConstrainedObject.
- "Hardwired" JNDI names for the ORB and the home POA replaced by
constant strings defined in org.jboss.iiop.CorbaORBService.
- Interface repository is now being bound to JNDI.
Revision ChangesPath
1.2 +3 -4
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebaseInterceptor.java
Index: CodebaseInterceptor.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebaseInterceptor.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CodebaseInterceptor.java 30 Oct 2001 21:56:13 - 1.1
+++ CodebaseInterceptor.java 13 Feb 2002 20:45:34 - 1.2
@@ -7,8 +7,7 @@
package org.jboss.ejb.plugins.iiop.server;
import org.omg.IOP.TAG_JAVA_CODEBASE;
-//import org.omg.CORBA.LocalObject; // JacORB does not have it yet
-import org.jacorb.orb.LocalityConstrainedObject; // using this one instead
+import org.omg.CORBA.LocalObject;
import org.omg.IOP.TaggedComponent;
import org.omg.PortableInterceptor.IORInfo;
import org.omg.PortableInterceptor.IORInterceptor;
@@ -19,10 +18,10 @@
* that adds a Java codebase component to an IOR.
*
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class CodebaseInterceptor
- extends /*LocalObject*/ LocalityConstrainedObject
+ extends LocalObject
implements IORInterceptor
{
// org.omg.PortableInterceptor.IORInterceptor operations ---
1.2 +3 -4
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebaseInterceptorInitializer.java
Index: CodebaseInterceptorInitializer.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebaseInterceptorInitializer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CodebaseInterceptorInitializer.java 30 Oct 2001 21:56:13 - 1.1
+++ CodebaseInterceptorInitializer.java 13 Feb 2002 20:45:34 - 1.2
@@ -6,8 +6,7 @@
*/
package org.jboss.ejb.plugins.iiop.server;
-//import org.omg.CORBA.LocalObject; // JacORB does not have it yet
-import org.jacorb.orb.LocalityConstrainedObject; // using this one instead
+import org.omg.CORBA.LocalObject;
import org.omg.PortableInterceptor.ORBInitializer;
import org.omg.PortableInterceptor.ORBInitInfo;
@@ -17,10 +16,10 @@
* CodebasePolicyFactory.
*
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
public class CodebaseInterceptorInitializer
- extends /*LocalObject*/ LocalityConstrainedObject
+ extends LocalObject
implements ORBInitializer
{
1.2 +3 -4
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebasePolicy.java
Index: CodebasePolicy.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebasePolicy.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CodebasePolicy.java 30 Oct 2001 21:56:13 - 1.1
+++ CodebasePolicy.java 13 Feb 2002 20:45:34 - 1.2
@@ -6,8 +6,7 @@
*/
package org.jboss.ejb.plugins.iiop.server;
-//import org.omg.CORBA.LocalObject; // JacORB does not have it yet
-import org.jacorb.orb.LocalityConstrainedObject; // using this one instead
+import org.omg.CORBA.LocalObject;
import org.omg.CORBA.Policy;
/**
@@ -15,10 +14,10 @@
* strings.
*
* @author mailto:[EMAIL PROTECTED]";>Francisco Reverbel
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*/
class CodebasePolicy
- extends /*LocalObject*/ LocalityConstrainedObject
+ extends LocalObject
implements Policy
{
// Private -
1.2 +3 -4
contrib/iiop/src/main/org/jboss/ejb/plugins/iiop/server/CodebasePolicyF
[JBoss-dev] [ jboss-Bugs-517130 ] serialization failure
Bugs item #517130, was opened at 2002-02-13 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517130&group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Egan Allen (eganallen) Assigned to: Nobody/Anonymous (nobody) Summary: serialization failure Initial Comment: I have an instance variable jndiContext of type Context that is assigned new InitialContext() in the setSessionContext() method in my stateful session EJBs. I realize that javax.naming.Context is not serializable but I understood that the container (as per the EJB1.1/2.0 spec) should still be able to deal with this instance variable given it is of javax.naming.Conext (and thus, javax.naming.InitialContext) and NOT hinder passivation. Here is server.log info: [Bean Cache] Scheduling for passivation overaged bean LineageManagerEJB with id = 1012776007792 - Cache size = 1 [Bean Cache] Aging out from cache bean LineageManagerEJBwith id = 1012776007792; cache size = 1 [Container factory] Scheduled passivation of bean LineageManagerEJB with id = 1012776007792 [Container factory] java.rmi.ServerException: Could not passivate; nested exception is: [Container factory] java.io.NotSerializableException: javax.naming.InitialContext [Container factory] java.io.NotSerializableException: javax.naming.InitialContext [Container factory] at java.io.ObjectOutputStream.outputObject(Unknown Source) [Container factory] at java.io.ObjectOutputStream.writeObject(Unknown Source) [Container factory] at java.io.ObjectOutputStream.outputClassFields(Unknown Source) [Container factory] at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) [Container factory] at java.io.ObjectOutputStream.outputObject(Unknown Source) [Container factory] at java.io.ObjectOutputStream.writeObject(Unknown Source) [Container factory] at org.jboss.ejb.plugins.StatefulSessionFilePersistenceMan ager.passivateSession (StatefulSessionFilePersistenceManager.java:285) [Container factory] at org.jboss.ejb.plugins.StatefulSessionInstanceCache.pass ivate(StatefulSessionInstanceCache.java:67) [Container factory] at org.jboss.ejb.plugins.AbstractInstanceCache$1.execute (AbstractInstanceCache.java:709) [Container factory] at org.jboss.util.WorkerQueue$QueueLoop.run (WorkerQueue.java:199) [Container factory] at java.lang.Thread.run(Unknown Source) Help!! thanks, Egan Allen -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=517130&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Code Style Guide
On 12 Feb 2002 15:24:31 -0800, Jason Dillon wrote: >Has anyone played with a decent cross platform tool that can easily >translate from style to style? It seems that we will always have this >problem, but if we could gave something translate a users style back >into jboss style then we can end this thread once and for all. Should >also help improve diffs. Well, there is currently one under development. It's called Jalopy and has just reached beta status. I'm currently uploading the second beta (called jalopy-1.0b1 ;-) and have to state that this code is not fully tested (not an easy task) but does a fairly good job for me. I've tested it with - castor 0.9.3 - Doug Lea's util.concurrent 1.3 - jaxp 1.1 - log4j 1.1.3 - jboss 2.2.2 - jedit 3.2.2 - xalan 2.1.0 - jgl 3.1.0 and after resolving the places where a developer used the keyword "assert", it went without problems (the used parser parses JDK 1.4 syntax, derived from a slightly modified ANLTR java grammar). But of course, I'm eager to hear about the experiences from others. Ah, if one may want to take a look, see http://sourceforge.net/projects/jalopy Cheers, Marco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/build build.xml
User: patriot1burke Date: 02/02/13 14:46:03 Modified:src/build Tag: Branch_2_4 build.xml Log: added ApplicationDeadlockException to jboss-client Revision ChangesPath No revision No revision 1.77.2.12 +1 -0 jboss/src/build/Attic/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/src/build/Attic/build.xml,v retrieving revision 1.77.2.11 retrieving revision 1.77.2.12 diff -u -r1.77.2.11 -r1.77.2.12 --- build.xml 29 Dec 2001 04:41:34 - 1.77.2.11 +++ build.xml 13 Feb 2002 22:46:03 - 1.77.2.12 @@ -252,6 +252,7 @@ + ___ 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/lock ApplicationDeadlockException.java BeanLockSupport.java QueuedPessimisticEJBLock.java
User: patriot1burke
Date: 02/02/13 14:46:57
Modified:src/main/org/jboss/ejb/plugins/lock Tag: Branch_2_4
BeanLockSupport.java QueuedPessimisticEJBLock.java
Added: src/main/org/jboss/ejb/plugins/lock Tag: Branch_2_4
ApplicationDeadlockException.java
Log:
Added application deadlock detection.
Revision ChangesPath
No revision
No revision
1.4.4.4 +47 -19jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java
Index: BeanLockSupport.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java,v
retrieving revision 1.4.4.3
retrieving revision 1.4.4.4
diff -u -r1.4.4.3 -r1.4.4.4
--- BeanLockSupport.java 20 Nov 2001 09:42:52 - 1.4.4.3
+++ BeanLockSupport.java 13 Feb 2002 22:46:57 - 1.4.4.4
@@ -6,10 +6,7 @@
*/
package org.jboss.ejb.plugins.lock;
-
-import java.util.LinkedList;
-import java.util.HashMap;
-import java.util.Collections;
+
import java.lang.reflect.Method;
import javax.transaction.Transaction;
@@ -18,13 +15,16 @@
import org.jboss.ejb.BeanLock;
import org.jboss.ejb.MethodInvocation;
import org.jboss.logging.Logger;
+import java.util.HashMap;
+import java.util.HashSet;
+
/**
* Support for the BeanLock
*
* @author Bill Burke
* @author Marc Fleury
- * @version $Revision: 1.4.4.3 $
+ * @version $Revision: 1.4.4.4 $
*
* Revisions:
* 2001/07/29: marcf
@@ -35,9 +35,6 @@
public abstract class BeanLockSupport
implements BeanLock
{
- /** Use a JBoss custom log4j category for trace level logging */
- static Logger log = Logger.getLogger(BeanLock.class);
-
/**
* Number of threads invoking methods on this bean
* (1 normally >1 if reentrant)
@@ -56,6 +53,9 @@
/** Are reentrant calls allowed? */
protected boolean reentrant;
+ /** Logger instance */
+ static Logger log = Logger.getLogger(BeanLock.class);
+
protected Transaction tx = null;
protected boolean synched = false;
@@ -142,23 +142,51 @@
protected boolean isCallAllowed(MethodInvocation mi)
{
+ // is this a reentrant bean
if (reentrant)
{
return true;
}
- else
+
+ // is this a known non-entrant method
+ Method m = mi.getMethod();
+ if (m.equals(getEJBHome) ||
+ m.equals(getHandle) ||
+ m.equals(getPrimaryKey) ||
+ m.equals(isIdentical) ||
+ m.equals(remove))
{
- Method m = mi.getMethod();
- if (m.equals(getEJBHome) ||
- m.equals(getHandle) ||
- m.equals(getPrimaryKey) ||
- m.equals(isIdentical) ||
- m.equals(remove))
- {
-return true;
- }
+ return true;
}
-
+
return false;
+ }
+
+ // This following is for deadlock detection
+ protected static HashMap waiting = new HashMap();
+
+ public void deadlockDetection(Transaction miTx) throws
ApplicationDeadlockException
+ {
+ HashSet set = new HashSet();
+ set.add(miTx);
+
+ Object checkTx = this.tx;
+ synchronized(waiting)
+ {
+ while (checkTx != null)
+ {
+ Object waitingFor = waiting.get(checkTx);
+ if (waitingFor != null)
+ {
+if (set.contains(waitingFor))
+{
+ log.error("Application deadlock detected: " + miTx + " has deadlock
conditions");
+ throw new ApplicationDeadlockException("application deadlock
detected");
+}
+set.add(waitingFor);
+ }
+ checkTx = waitingFor;
+ }
+ }
}
}
1.3.4.4 +86 -58
jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java
Index: QueuedPessimisticEJBLock.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/QueuedPessimisticEJBLock.java,v
retrieving revision 1.3.4.3
retrieving revision 1.3.4.4
diff -u -r1.3.4.3 -r1.3.4.4
--- QueuedPessimisticEJBLock.java 20 Nov 2001 09:42:52 - 1.3.4.3
+++ QueuedPessimisticEJBLock.java 13 Feb 2002 22:46:57 - 1.3.4.4
@@ -9,15 +9,13 @@
import java.util.LinkedList;
import java.util.HashMap;
-import java.util.Collections;
-import java.lang.reflect.Method;
-import javax.ejb.EJBObject;
-import javax.transaction.Status;
import javax.transaction.Transaction;
+import javax.transaction.Status;
import org.jboss.ejb.MethodInvocation;
+
/**
* This class is
[JBoss-dev] JBoss a JavaWorld finalist
Somebody on the ant list just posted that Ant is a "JavaWorld Finalist". It appears JBoss is also. Best Java Application Server (alphabetical order) BEA WebLogic Server 6.1, BEA Systems JBoss 2.4.4, JBoss.org WebSphere Application Server 4.0, IBM from: http://www.javaworld.com/javaworld/jw-02-2002/jw-0211-finalists.html I sure hope JBoss wins, for the look on the other guy's faces. Of course, that means that Marc will have to go to the JavaOne awards ceremony while everybody else is partying at JBossOne. :) Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net business solutions http://www.novell.com ___ 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/lock BeanLockSupport.java
User: patriot1burke
Date: 02/02/13 15:20:38
Modified:src/main/org/jboss/ejb/plugins/lock BeanLockSupport.java
Log:
added ApplicationDeadlockException
Revision ChangesPath
1.12 +3 -3 jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java
Index: BeanLockSupport.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/lock/BeanLockSupport.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- BeanLockSupport.java 12 Jan 2002 21:14:28 - 1.11
+++ BeanLockSupport.java 13 Feb 2002 23:20:38 - 1.12
@@ -24,7 +24,7 @@
*
* @author Bill Burke
* @author Marc Fleury
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*
* Revisions:
* 2001/07/29: marcf
@@ -171,7 +171,7 @@
// This following is for deadlock detection
protected static HashMap waiting = new HashMap();
- public void deadlockDetection(Transaction miTx)
+ public void deadlockDetection(Transaction miTx) throws Exception
{
HashSet set = new HashSet();
set.add(miTx);
@@ -187,7 +187,7 @@
if (set.contains(waitingFor))
{
log.error("Application deadlock detected: " + miTx + " has deadlock
conditions");
- throw new RuntimeException("application deadlock detected");
+ throw new ApplicationDeadlockException("application deadlock
detected");
}
set.add(waitingFor);
}
___
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/lock ApplicationDeadlockException.java
User: patriot1burke Date: 02/02/13 15:20:56 Added: src/main/org/jboss/ejb/plugins/lock ApplicationDeadlockException.java Log: added ApplicationDeadlockException Revision ChangesPath 1.2 +40 -0 jboss/src/main/org/jboss/ejb/plugins/lock/ApplicationDeadlockException.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: patriot1burke Date: 02/02/13 15:20:12 Modified:.build.xml Log: added ApplicationDeadlockException to jboss-client Revision ChangesPath 1.57 +2 -1 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.56 retrieving revision 1.57 diff -u -r1.56 -r1.57 --- build.xml 13 Feb 2002 04:22:31 - 1.56 +++ build.xml 13 Feb 2002 23:20:11 - 1.57 @@ -12,7 +12,7 @@ - + @@ -575,6 +575,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-517248 ] ApplicationDeadlockException
Change Notes item #517248, was opened at 2002-02-13 15:29
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=517248&group_id=22866
Category: None
Group: v3.0 (Rabbit Hole)
Status: Open
Priority: 5
Submitted By: Bill Burke (patriot1burke)
Assigned to: Nobody/Anonymous (nobody)
Summary: ApplicationDeadlockException
Initial Comment:
org.jboss.ejb.plugins.lock.ApplicationDeadlockException
is now thrown if application deadlock is detected.
On the client side, you'll need to catch it as follows:
catch (RemoteException de)
{
Throwable cause = null;
RemoteException dex = de;
while (dex.detail != null) {
cause = dex.detail;
if (cause instanceof RemoteException)
{
dex = (RemoteException)cause;
}
else {
break;
}
}
if (cause instanceof
ApplicationDeadlockException) {
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=517248&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Failed to Setup ENC
You'll have to provide a testcase then as I am able to deploy two ears, each with two copies of the same war with different context-root values without seeing this ENC creation failure. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Hunter Hillegas" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]>; "JBoss Dev" <[EMAIL PROTECTED]> Sent: Wednesday, February 13, 2002 11:46 AM Subject: Re: [JBoss-dev] Failed to Setup ENC > Still seems broken from here... When I deploy the second ear I see this: > > 11:45:52,174 ERROR [JBossWebApplicationContext#/vagrant-admin] failed to > setup ENC > javax.naming.NameAlreadyBoundException; remaining name 'env' > at > org.jnp.server.NamingServer.createSubcontext(NamingServer.java:451) > at > org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:664) > at > org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:650) > at > org.jboss.web.AbstractWebContainer.parseWebAppDescriptors(AbstractWebContain > er.java:503) > at ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] message selectors
After having a bad day trying to get a message selector working for a topic listener I came across a few bugs. 1) If the message selector is invalid but the connection is not started but no error is thrown. So if you createTopicSession then createSubscriber and then start the connection the connection looks good but there are no messages delivered. (I spent most of the day trying to sort this one out) 2) The message selectors do not seem to like boolean types. My query is app_id='AK' and production=TRUE 3) What parser are we using for the message selectors. I thought we were using javacc and jms.jj. But in Selector the default is set to parser which is from jms.y. I don't even think this thing is getting re-processed. I did swicth the default to SelectorParser but that did not work as well. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jmx build.xml
I will fix this. --jason On Wed, 2002-02-13 at 03:44, Juha Lindfors wrote: > > User: user57 > > Date: 02/02/12 20:14:08 > > > > Modified:.build.xml > > Log: > > o if these classes don't need to be built then why > > hy are they there? > > > > because the tests won't work correctly if those classes are in the system classpath >instead of loaded dynamically. Please add the removed tags back or replace it with a >similar functionality. > > Ask before you change, please. > > -- Juha > > > _ > View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=5587 > > ___ > 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: contrib/jetty/src/main/org/jboss/jetty JettyService.java
User: jules_gosnell
Date: 02/02/13 17:03:16
Modified:jetty/src/main/org/jboss/jetty JettyService.java
Log:
a bit more work on timers etc..
comment out Mortbay Logger MBean - it's causing trouble
Revision ChangesPath
1.45 +6 -6 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.44
retrieving revision 1.45
diff -u -r1.44 -r1.45
--- JettyService.java 12 Feb 2002 22:34:34 - 1.44
+++ JettyService.java 14 Feb 2002 01:03:16 - 1.45
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JettyService.java,v 1.44 2002/02/12 22:34:34 olegnitz Exp $
+// $Id: JettyService.java,v 1.45 2002/02/14 01:03:16 jules_gosnell Exp $
//--
@@ -26,7 +26,7 @@
import org.jboss.web.AbstractWebContainer;
import org.jboss.web.WebApplication;
import org.mortbay.util.jmx.CodeMBean;
-import org.mortbay.util.jmx.LogMBean;
+//import org.mortbay.util.jmx.LogMBean;
import org.mortbay.util.Log;
//--
@@ -34,7 +34,7 @@
* A service to launch jetty from JMX.
*
* @author mailto:[EMAIL PROTECTED]";>Julian Gosnell
- * @version $Revision: 1.44 $
+ * @version $Revision: 1.45 $
*/
// NOTES
@@ -53,7 +53,7 @@
CodeMBean_debug = null;
Jetty_jetty = null;
MBeanServer _server = null;
- LogMBean _logbean = null;
+ // LogMBean _logbean = null;
public
JettyService()
@@ -162,10 +162,10 @@
_log.debug("MBean peers WILL be created for Jetty Contexts");
_mbean = new JettyMBean(_jetty);
_debug = new CodeMBean();
-_logbean = new LogMBean();
+ //_logbean = new LogMBean();
_server.registerMBean(_mbean, null);
_server.registerMBean(_debug, new
ObjectName(_mbean.getDefaultDomain()+":Jetty=Debug"));
-_server.registerMBean (_logbean, new
ObjectName(_mbean.getDefaultDomain()+":Jetty=Log"));
+ //_server.registerMBean (_logbean, new
ObjectName(_mbean.getDefaultDomain()+":Jetty=Log"));
}
catch (Throwable e)
{
___
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/util AbstractTimeOutManager.java NaiveTimeOutManager.java
User: jules_gosnell
Date: 02/02/13 17:03:17
Modified:jetty/src/main/org/jboss/jetty/util
AbstractTimeOutManager.java
NaiveTimeOutManager.java
Log:
a bit more work on timers etc..
comment out Mortbay Logger MBean - it's causing trouble
Revision ChangesPath
1.4 +1 -4
contrib/jetty/src/main/org/jboss/jetty/util/AbstractTimeOutManager.java
Index: AbstractTimeOutManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/util/AbstractTimeOutManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- AbstractTimeOutManager.java 1 Feb 2002 19:12:03 - 1.3
+++ AbstractTimeOutManager.java 14 Feb 2002 01:03:16 - 1.4
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: AbstractTimeOutManager.java,v 1.3 2002/02/01 19:12:03 jules_gosnell Exp $
+// $Id: AbstractTimeOutManager.java,v 1.4 2002/02/14 01:03:16 jules_gosnell Exp $
//--
@@ -19,9 +19,6 @@
public void register(Object object, long now, long maxInactiveInterval);
public void reregister(Object object, long now, long maxInactiveInterval);
public void deregister(Object object);
-
- public void start();
- public void stop();
public interface
TimeOutHelper
1.7 +72 -57
contrib/jetty/src/main/org/jboss/jetty/util/NaiveTimeOutManager.java
Index: NaiveTimeOutManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/util/NaiveTimeOutManager.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- NaiveTimeOutManager.java 13 Feb 2002 01:03:06 - 1.6
+++ NaiveTimeOutManager.java 14 Feb 2002 01:03:17 - 1.7
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: NaiveTimeOutManager.java,v 1.6 2002/02/13 01:03:06 jules_gosnell Exp $
+// $Id: NaiveTimeOutManager.java,v 1.7 2002/02/14 01:03:17 jules_gosnell Exp $
//--
@@ -16,6 +16,13 @@
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
+import org.jboss.logging.Logger;
+
+//--
+
+// This needn't be so Naive. If it tried to keep a handle on which was
+// the next entry to timeout it could simply sleep until that time,
+// instead of a set period. This might save some processing time...
//--
@@ -24,9 +31,12 @@
NaiveTimeOutManager
implements AbstractTimeOutManager
{
- final List_entries=new LinkedList();
- final long_interval;
- final TimeOutHelper _helper;
+ protected final Logger_log=Logger.getLogger(getClass().getName());
+ protected final List _entries=new LinkedList();
+ protected final long _interval;
+ protected final TimeOutHelper _helper;
+ protected Sweeper _sweeper;
+
public
NaiveTimeOutManager(long interval, TimeOutHelper helper)
@@ -61,6 +71,29 @@
}
}
+ class Sweeper
+extends Thread
+ {
+volatile boolean _running=false;
+
+public void
+ run()
+{
+ _log.info("background thread started: "+NaiveTimeOutManager.this);
+ while (_running)
+ {
+ try
+ {
+ sleep(_interval);
+ sweep();
+ }
+ catch (InterruptedException e)
+ {}
+ }
+ _log.info("background thread ended: "+NaiveTimeOutManager.this);
+}
+ }
+
public synchronized void
register(Object object, long timeRegistered, long maxInactiveInterval)
{
@@ -70,31 +103,46 @@
Entry entry=new Entry(object, timeRegistered, maxInactiveInterval);
synchronized (_entries) {
+ // start sweeping if this is the first to go into the list...
+ if (_entries.size()==0)
+ {
+ _sweeper=new Sweeper(); // can we reuse this thread ? - TODO
+ _sweeper._running=true;
+ _sweeper.start();
+ }
+
_entries.add(entry);
}
}
public synchronized void
-reregister(Object object, long timeRegistered, long maxInactiveInterval)
-{
- // could be optimised - but this is simpler for the moment...
- deregister(object);
- register(object, timeRegistered, maxInactiveInterval);
-}
-
- public synchronized void
deregister(Object object)
{
Entry p=find(object);
synchr
[JBoss-dev] [ jboss-Change Notes-517250 ] added entity bean deadlock detection
Change Notes item #517250, was opened at 2002-02-13 15:33
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=517250&group_id=22866
Category: None
Group: v2.4.5
Status: Open
Priority: 5
Submitted By: Bill Burke (patriot1burke)
Assigned to: Nobody/Anonymous (nobody)
Summary: added entity bean deadlock detection
Initial Comment:
Added application deadlock detection to Entity Beans.
If application deadlock is detected and exception is
thrown. This will help out with debugging because
users can look at the stack trace and actually
positively know they have application deadlock.
org.jboss.ejb.plugins.lock.ApplicationDeadlockException
is now thrown if application deadlock is detected.
On the client side, you'll need to catch it as
follows:
catch (RemoteException de)
{
Throwable cause = null;
RemoteException dex = de;
while (dex.detail != null) {
cause = dex.detail;
if (cause instanceof RemoteException)
{
dex = (RemoteException)cause;
}
else {
break;
}
}
if (cause instanceof
ApplicationDeadlockException) {
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=381174&aid=517250&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-517252 ] jca-javaspace adapter
Patches item #517252, was opened at 2002-02-13 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517252&group_id=22866 Category: JBossCX Group: None Status: Open Resolution: None Priority: 1 Submitted By: David Jencks (d_jencks) Assigned to: David Jencks (d_jencks) Summary: jca-javaspace adapter Initial Comment: This is a possibly complete but untested jca adapter to javaspaces. I believe all significant functionality is implemented but I have not been able to set up enough supporting jini services to test this. Help would be appreciated. In any case it provides an example of how to implement a simple jca adapter. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517252&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx build.xml
User: user57 Date: 02/02/13 17:08:19 Modified:.build.xml Log: o build two jars, one with main classes and one with tests Revision ChangesPath 1.15 +14 -6 jmx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jmx/build.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- build.xml 13 Feb 2002 04:14:08 - 1.14 +++ build.xml 14 Feb 2002 01:08:18 - 1.15 @@ -12,7 +12,7 @@ - + @@ -228,6 +228,14 @@ + + + + + + + + @@ -395,10 +403,10 @@ - - - - + + + + @@ -411,7 +419,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss a JavaWorld finalist
This means we already edged out Oracle and others. -dain Jeff Tulley wrote: > Somebody on the ant list just posted that Ant is a "JavaWorld Finalist". > It appears JBoss is also. > > Best Java Application Server (alphabetical order) > BEA WebLogic Server 6.1, BEA Systems > JBoss 2.4.4, JBoss.org > WebSphere Application Server 4.0, IBM > > from: > http://www.javaworld.com/javaworld/jw-02-2002/jw-0211-finalists.html > > > I sure hope JBoss wins, for the look on the other guy's faces. Of > course, that means that Marc will have to go to the JavaOne awards > ceremony while everybody else is partying at JBossOne. :) > > > Jeff Tulley ([EMAIL PROTECTED]) > (801)861-5322 > Novell, Inc., the leading provider of Net business solutions > http://www.novell.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
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/session DistributedHttpSessionManager.java
User: jules_gosnell
Date: 02/02/13 17:03:16
Modified:jetty/src/main/org/jboss/jetty/session
DistributedHttpSessionManager.java
Log:
a bit more work on timers etc..
comment out Mortbay Logger MBean - it's causing trouble
Revision ChangesPath
1.13 +9 -11
contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java
Index: DistributedHttpSessionManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- DistributedHttpSessionManager.java13 Feb 2002 01:03:06 - 1.12
+++ DistributedHttpSessionManager.java14 Feb 2002 01:03:16 - 1.13
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: DistributedHttpSessionManager.java,v 1.12 2002/02/13 01:03:06 jules_gosnell
Exp $
+// $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16 jules_gosnell
Exp $
// TODO
@@ -110,7 +110,8 @@
super(notifyActivate, notifyPassivate);
}
- public void snapshot(DistributedHttpSession session)
+ public void
+snapshot(DistributedHttpSession session)
{}
}
@@ -125,7 +126,7 @@
timeOut(Object object)
{
IntervalSnapshotStrategy iss=(IntervalSnapshotStrategy)object;
- System.out.println("snapshotting HttpSessions for Context
("+iss._manager.getServletContext()+")");
+ System.out.println("snapshotting HttpSessions for Context
("+iss._manager.getServletContext().getServletContextName()+")");
iss._manager.snapshot(iss._notifyActivate, iss._notifyPassivate); //
should probably be done on another thread
iss._timer.reregister(iss, System.currentTimeMillis(), iss._interval*1000);
}
@@ -133,7 +134,6 @@
public long
timeRemaining(Object object, long timeRegistered, long timeNow, long
maxInactiveInterval)
{
- System.out.println("checking time left:
"+((timeRegistered+maxInactiveInterval)-timeNow));
return (timeRegistered+maxInactiveInterval)-timeNow;
}
}
@@ -148,20 +148,20 @@
super(notifyActivate, notifyPassivate);
_interval=interval;
_manager=manager;
-
-_timer.register(this, System.currentTimeMillis(), _interval*1000);
}
public void
start()
{
-_timer.start();
+super.start();
+_timer.register(this, System.currentTimeMillis(), _interval*1000);
}
public void
stop()
{
-_timer.stop();
+super.stop();
+_timer.deregister(this);
}
}
@@ -201,7 +201,7 @@
//--
/**
*
- * @version $Id: DistributedHttpSessionManager.java,v 1.12 2002/02/13 01:03:06
jules_gosnell Exp $
+ * @version $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16
jules_gosnell Exp $
* @author [EMAIL PROTECTED]
*/
//
@@ -439,7 +439,6 @@
throws Exception
{
_isStarted=true;
-_scavenger.start();
_snapshotStrategy.start();
// sessions are activated lazily...
@@ -449,7 +448,6 @@
stop() // TODO
{
_snapshotStrategy.stop();
-_scavenger.stop();
_isStarted=false;// TODO
// tidy up all sessions...
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
What version of JBoss are you using? --jason On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > After having a bad day trying to get a message selector working for a > topic listener I came across a few bugs. > > 1) If the message selector is invalid but the connection is not started > but no error is thrown. So if you createTopicSession then > createSubscriber and then start the connection the connection looks good > but there are no messages delivered. (I spent most of the day trying to > sort this one out) > > 2) The message selectors do not seem to like boolean types. My query is > app_id='AK' and production=TRUE > > 3) What parser are we using for the message selectors. I thought we were > using javacc and jms.jj. But in Selector the default is set to parser > which is from jms.y. I don't even think this thing is getting > re-processed. I did swicth the default to SelectorParser but that did > not work as well. > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-517274 ] Fix - so JSPs will compile with Catalina
Patches item #517274, was opened at 2002-02-13 17:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517274&group_id=22866 Category: None Group: v3.0 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Robert Whitehead (wrwhitehead) Assigned to: Nobody/Anonymous (nobody) Summary: Fix - so JSPs will compile with Catalina Initial Comment: Currently, Java Server Pages (JSPs) don't compile for Tomcat4 (Catalina). The classloader doesn't pick up all the necessary jar files. Looking at the Catalina bootstrap.java and the way Jetty now does class loading for JBoss, I inserted a new method: public ClassLoader setUpLoader(ClassLoader parent). This method sets up a catalina classloader and the results are inserted into the classloader hierarchy. Also stripped off the ".war" from the ctxPath so the context is set up correctly. See attached diff file. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=517274&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss a JavaWorld finalist
Didn't think about it, I'm too used to only see BEA and JBoss, but there are nearly 20 players in this game, including HP AS, OAS, iPlanet... and Lutris, heh :) > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En nombre de Dain > Sundstrom > Enviado el: jueves, 14 de febrero de 2002 1:18 > Para: Jeff Tulley > CC: [EMAIL PROTECTED] > Asunto: Re: [JBoss-dev] JBoss a JavaWorld finalist > > > This means we already edged out Oracle and others. > > -dain > > > Jeff Tulley wrote: > > > Somebody on the ant list just posted that Ant is a "JavaWorld Finalist". > > It appears JBoss is also. > > > > Best Java Application Server (alphabetical order) > > BEA WebLogic Server 6.1, BEA Systems > > JBoss 2.4.4, JBoss.org > > WebSphere Application Server 4.0, IBM > > > > from: > > http://www.javaworld.com/javaworld/jw-02-2002/jw-0211-finalists.html > > > > > > I sure hope JBoss wins, for the look on the other guy's faces. Of > > course, that means that Marc will have to go to the JavaOne awards > > ceremony while everybody else is partying at JBossOne. :) > > > > > > Jeff Tulley ([EMAIL PROTECTED]) > > (801)861-5322 > > Novell, Inc., the leading provider of Net business solutions > > http://www.novell.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 > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
CVS as off 5pm EST Feb13 Jason Dillon wrote: > What version of JBoss are you using? > > --jason > > > On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > >>After having a bad day trying to get a message selector working for a >>topic listener I came across a few bugs. >> >>1) If the message selector is invalid but the connection is not started >>but no error is thrown. So if you createTopicSession then >>createSubscriber and then start the connection the connection looks good >>but there are no messages delivered. (I spent most of the day trying to >>sort this one out) >> >>2) The message selectors do not seem to like boolean types. My query is >>app_id='AK' and production=TRUE >> >>3) What parser are we using for the message selectors. I thought we were >>using javacc and jms.jj. But in Selector the default is set to parser >>which is from jms.y. I don't even think this thing is getting >>re-processed. I did swicth the default to SelectorParser but that did >>not work as well. >> >> >>___ >>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/invocation/jrmp/server JRMPInvoker.java
User: user57
Date: 02/02/13 17:31:01
Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvoker.java
Log:
o Using Invocation.INVOKE_SIGNATURE
Revision ChangesPath
1.13 +13 -3 jboss/src/main/org/jboss/invocation/jrmp/server/JRMPInvoker.java
Index: JRMPInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/invocation/jrmp/server/JRMPInvoker.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JRMPInvoker.java 8 Feb 2002 01:06:19 - 1.12
+++ JRMPInvoker.java 14 Feb 2002 01:31:01 - 1.13
@@ -54,7 +54,7 @@
* from RMI/JRMP into the JMX base.
*
* @author mailto:[EMAIL PROTECTED]>Marc Fleury
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*
* Revisions:
* 2002/01/13: Sacha Labourey
@@ -75,14 +75,19 @@
/** The port the container will be exported on */
protected int rmiPort = ANONYMOUS_PORT;
+
/** An optional custom client socket factory */
protected RMIClientSocketFactory clientSocketFactory;
+
/** An optional custom server socket factory */
protected RMIServerSocketFactory serverSocketFactory;
+
/** The class name of the optional custom client socket factory */
protected String clientSocketFactoryName;
+
/** The class name of the optional custom server socket factory */
protected String serverSocketFactoryName;
+
/** The address to bind the rmi port on */
protected String serverAddress;
@@ -93,7 +98,7 @@
protected int state;
protected int id = 0;
- protected RemoteStub invokerStub = null;
+ protected RemoteStub invokerStub;
// Static
@@ -354,7 +359,12 @@
ObjectName mbean = (ObjectName) Registry.lookup((Integer)
invocation.getContainer());
// The cl on the thread should be set in another interceptor
- return new MarshalledObject(server.invoke(mbean, "", new Object[]
{invocation}, new String[] {"java.lang.Object"}));
+ Object obj = server.invoke(mbean,
+"",
+new Object[] {invocation},
+Invocation.INVOKE_SIGNATURE);
+
+ return new MarshalledObject(obj);
}
catch (Exception e) {
e = org.jboss.util.ThrowableTranslator.translate(e);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx/src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
User: user57
Date: 02/02/13 17:31:01
Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
Log:
o Using Invocation.INVOKE_SIGNATURE
Revision ChangesPath
1.11 +37 -50
jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java
Index: JRMPInvokerHA.java
===
RCS file:
/cvsroot/jboss/jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JRMPInvokerHA.java12 Feb 2002 00:53:35 - 1.10
+++ JRMPInvokerHA.java14 Feb 2002 01:31:01 - 1.11
@@ -1,9 +1,10 @@
/*
-* JBoss, the OpenSource J2EE webOS
-*
-* Distributable under LGPL license.
-* See terms of license at gnu.org.
-*/
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
+ */
+
package org.jboss.invocation.jrmp.server;
import java.rmi.ServerException;
@@ -34,49 +35,29 @@
import java.util.HashMap;
import java.util.Iterator;
-
/**
-* The JRMPInvokerHA is an HA-RMI implementation that can generate Invocations from
RMI/JRMP
-* into the JMX base
-*
-* @author mailto:[EMAIL PROTECTED]>Bill Burke
-*
-* @version $Revision: 1.10 $
-*/
-
+ * The JRMPInvokerHA is an HA-RMI implementation that can generate Invocations from
RMI/JRMP
+ * into the JMX base
+ *
+ * @author mailto:[EMAIL PROTECTED]>Bill Burke
+ * @version $Revision: 1.11 $
+ */
public class JRMPInvokerHA
-extends JRMPInvoker
+ extends JRMPInvoker
{
- // Constants -
-
- // Attributes
protected HashMap beanMap = new HashMap();
- // Static
-
- // Constructors --
-
- // Public
-
- // MBean parameters
-
- public String getName() {return "JRMPInvokerHA";}
-
- // Service implementation ---
-
- // Static
-
- // Constructors --
+ public String getName() {
+ return "JRMPInvokerHA";
+ }
public JRMPInvokerHA()
{
super();
}
- // Public
-
public void start()
- throws Exception
+ throws Exception
{
if (getState() != STOPPED && getState() != FAILED)
return;
@@ -129,7 +110,10 @@
public void registerBean(String beanName, HATarget target) throws Exception
{
Integer hash = new Integer((new ObjectName(beanName)).hashCode());
- log.info(" BEAN NAME IS "+beanName);
+ if (log.isDebugEnabled()) {
+ log.debug("BEAN NAME IS "+beanName);
+ }
+
if (beanMap.containsKey(hash)) {
// FIXME [oleg] In theory this is possible!
throw new IllegalStateException("Trying to register bean with the existing
hashCode");
@@ -154,12 +138,11 @@
}
/**
- * Invoke a Remote interface method.
- */
+* Invoke a Remote interface method.
+*/
public Object invoke(Invocation invocation)
- throws Exception
+ throws Exception
{
-
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
try
@@ -174,7 +157,11 @@
// The cl on the thread should be set in another interceptor
- Object rtn = server.invoke(mbean, "", new Object[] {invocation}, new
String[] {"java.lang.Object"});
+ Object rtn = server.invoke(mbean,
+"",
+new Object[] { invocation },
+Invocation.INVOKE_SIGNATURE);
+
HARMIResponse rsp = new HARMIResponse();
HATarget target = (HATarget)beanMap.get((Integer)
invocation.getContainer());
@@ -189,18 +176,18 @@
rsp.response = rtn;
return new MarshalledObject(rsp);
}
- catch (MBeanException mbe) { throw mbe.getTargetException(); }
- catch (Exception e) {e.printStackTrace(); throw e;}
+ catch (MBeanException e)
+ {
+ throw e.getTargetException();
+ }
+ catch (Exception e)
+ {
+ throw e;
+ }
finally
{
Thread.currentThread().setContextClassLoader(oldCl);
}
}
-
- // Package protected -
Re: [JBoss-dev] message selectors
I did not think we were using the old parser anymore... Is there a reason this is still around after Scott reimplemented in JavaCC? --jason On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > After having a bad day trying to get a message selector working for a > topic listener I came across a few bugs. > > 1) If the message selector is invalid but the connection is not started > but no error is thrown. So if you createTopicSession then > createSubscriber and then start the connection the connection looks good > but there are no messages delivered. (I spent most of the day trying to > sort this one out) > > 2) The message selectors do not seem to like boolean types. My query is > app_id='AK' and production=TRUE > > 3) What parser are we using for the message selectors. I thought we were > using javacc and jms.jj. But in Selector the default is set to parser > which is from jms.y. I don't even think this thing is getting > re-processed. I did swicth the default to SelectorParser but that did > not work as well. > > > ___ > 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] message selectors
Please submit a bug for this. --jason On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > After having a bad day trying to get a message selector working for a > topic listener I came across a few bugs. > > 1) If the message selector is invalid but the connection is not started > but no error is thrown. So if you createTopicSession then > createSubscriber and then start the connection the connection looks good > but there are no messages delivered. (I spent most of the day trying to > sort this one out) > > 2) The message selectors do not seem to like boolean types. My query is > app_id='AK' and production=TRUE > > 3) What parser are we using for the message selectors. I thought we were > using javacc and jms.jj. But in Selector the default is set to parser > which is from jms.y. I don't even think this thing is getting > re-processed. I did swicth the default to SelectorParser but that did > not work as well. > > > ___ > 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] message selectors
Actually it's worse than that. If you change the default parser to SelectorParser, nothing works! So a simple slector like type='cadex' bombs. Jason Dillon wrote: > I did not think we were using the old parser anymore... Is there a > reason this is still around after Scott reimplemented in JavaCC? > > --jason > > > On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > >>After having a bad day trying to get a message selector working for a >>topic listener I came across a few bugs. >> >>1) If the message selector is invalid but the connection is not started >>but no error is thrown. So if you createTopicSession then >>createSubscriber and then start the connection the connection looks good >>but there are no messages delivered. (I spent most of the day trying to >>sort this one out) >> >>2) The message selectors do not seem to like boolean types. My query is >>app_id='AK' and production=TRUE >> >>3) What parser are we using for the message selectors. I thought we were >>using javacc and jms.jj. But in Selector the default is set to parser >>which is from jms.y. I don't even think this thing is getting >>re-processed. I did swicth the default to SelectorParser but that did >>not work as well. >> >> >>___ >>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] JBoss a JavaWorld finalist
Yeah. I'm in awe of this! This is really really good news. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Wednesday, February 13, 2002 8:18 PM > To: Jeff Tulley > Cc: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] JBoss a JavaWorld finalist > > > This means we already edged out Oracle and others. > > -dain > > > Jeff Tulley wrote: > > > Somebody on the ant list just posted that Ant is a "JavaWorld Finalist". > > It appears JBoss is also. > > > > Best Java Application Server (alphabetical order) > > BEA WebLogic Server 6.1, BEA Systems > > JBoss 2.4.4, JBoss.org > > WebSphere Application Server 4.0, IBM > > > > from: > > http://www.javaworld.com/javaworld/jw-02-2002/jw-0211-finalists.html > > > > > > I sure hope JBoss wins, for the look on the other guy's faces. Of > > course, that means that Marc will have to go to the JavaOne awards > > ceremony while everybody else is partying at JBossOne. :) > > > > > > Jeff Tulley ([EMAIL PROTECTED]) > > (801)861-5322 > > Novell, Inc., the leading provider of Net business solutions > > http://www.novell.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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
How about making us a MessageSelectorTestCase so we can catch this next time. I am about to commit a fix to the build system so that changes to jms.jj actually will get used, as well as making SelectorParser the default. Going to keep parser.java & jms.y around for a bit, but once the javacc one is tested we can ditch it. --jason On Wed, 2002-02-13 at 17:52, Dave Smith wrote: > Actually it's worse than that. If you change the default parser to > SelectorParser, nothing works! So a simple slector like type='cadex' bombs. > > > Jason Dillon wrote: > > I did not think we were using the old parser anymore... Is there a > > reason this is still around after Scott reimplemented in JavaCC? > > > > --jason > > > > > > On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > > > >>After having a bad day trying to get a message selector working for a > >>topic listener I came across a few bugs. > >> > >>1) If the message selector is invalid but the connection is not started > >>but no error is thrown. So if you createTopicSession then > >>createSubscriber and then start the connection the connection looks good > >>but there are no messages delivered. (I spent most of the day trying to > >>sort this one out) > >> > >>2) The message selectors do not seem to like boolean types. My query is > >>app_id='AK' and production=TRUE > >> > >>3) What parser are we using for the message selectors. I thought we were > >>using javacc and jms.jj. But in Selector the default is set to parser > >>which is from jms.y. I don't even think this thing is getting > >>re-processed. I did swicth the default to SelectorParser but that did > >>not work as well. > >> > >> > >>___ > >>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: jbossmq build.xml
User: user57
Date: 02/02/13 18:54:29
Modified:.build.xml
Log:
o Removing files generated by JavaCC.
o Renamed jms.jj to SelectorParser.jj (it generates SelectorParser.java)
o Made SelectorParser the deafult
o Fixed build system to correctly build the parser
Revision ChangesPath
1.18 +18 -5 jbossmq/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbossmq/build.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- build.xml 13 Feb 2002 06:38:33 - 1.17
+++ build.xml 14 Feb 2002 02:54:29 - 1.18
@@ -12,7 +12,7 @@
-
+
@@ -262,7 +262,7 @@
| documentation compiles.
-->
@@ -270,7 +270,7 @@
-
@@ -287,9 +287,22 @@
includeAntRuntime="${javac.include.ant.runtime}"
includeJavaRuntime="${javac.include.java.runtime}"
failonerror="${javac.fail.onerror}">
-
-
+
+
+
+
+
+
+
+
+
+
+
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/selectors SelectorParser.jj Operator.java Selector.java ASCII_CharStream.java ParseException.java SelectorParser.java SelectorParserConstants.java SelectorParserTokenManager.java Token.java TokenMgrError.java jms.jj
User: user57
Date: 02/02/13 18:54:30
Modified:src/main/org/jboss/mq/selectors Operator.java Selector.java
Added: src/main/org/jboss/mq/selectors SelectorParser.jj
Removed: src/main/org/jboss/mq/selectors ASCII_CharStream.java
ParseException.java SelectorParser.java
SelectorParserConstants.java
SelectorParserTokenManager.java Token.java
TokenMgrError.java jms.jj
Log:
o Removing files generated by JavaCC.
o Renamed jms.jj to SelectorParser.jj (it generates SelectorParser.java)
o Made SelectorParser the deafult
o Fixed build system to correctly build the parser
Revision ChangesPath
1.5 +4 -27 jbossmq/src/main/org/jboss/mq/selectors/Operator.java
Index: Operator.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/selectors/Operator.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Operator.java 24 Aug 2001 17:27:08 - 1.4
+++ Operator.java 14 Feb 2002 02:54:29 - 1.5
@@ -9,15 +9,16 @@
import java.util.HashSet;
/**
- * An operator for the selector system
+ * An operator for the selector system.
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
* @author [EMAIL PROTECTED]
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
-public class Operator {
+public class Operator
+{
int operation;
Object oper1;
Object oper2;
@@ -32,53 +33,29 @@
int class3;
public final static int EQUAL = 0;
- //Done
public final static int NOT = 1;
- //Done
public final static int AND = 2;
- //Done
public final static int OR = 3;
- //Done
public final static int GT = 4;
- //Done
public final static int GE = 5;
- //Done
public final static int LT = 6;
- //Done
public final static int LE = 7;
- //Done
public final static int DIFFERENT = 8;
- //Done
public final static int ADD = 9;
- //Done
public final static int SUB = 10;
- //Done
public final static int NEG = 11;
- //Done
public final static int MUL = 12;
- //Done
public final static int DIV = 13;
- //Done
public final static int BETWEEN = 14;
- //Done
public final static int NOT_BETWEEN = 15;
- //Done
public final static int LIKE = 16;
- //Done
public final static int NOT_LIKE = 17;
- //Done
public final static int LIKE_ESCAPE = 18;
- //Done
public final static int NOT_LIKE_ESCAPE = 19;
- //Done
public final static int IS_NULL = 20;
- //Done
public final static int IS_NOT_NULL = 21;
- //Done
public final static int IN = 22;
- //Done
public final static int NOT_IN = 23;
- //Done
public final static int STRING = 0;
public final static int DOUBLE = 1;
1.8 +32 -25jbossmq/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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Selector.java 13 Jan 2002 01:10:03 - 1.7
+++ Selector.java 14 Feb 2002 02:54:29 - 1.8
@@ -17,37 +17,44 @@
import org.jboss.mq.SpyMessage;
/**
- * This class implements a Message Selector.
+ * This class implements a Message Selector.
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
* @author [EMAIL PROTECTED]
* @createdAugust 16, 2001
- * @version$Revision: 1.7 $
+ * @version$Revision: 1.8 $
*/
public class Selector
{
/** The logging interface */
static Logger cat = Logger.getLogger(Selector.class);
+
/** The ISelectorParser implementation class */
- private static Class parserClass = parser.class;
+ private static Class parserClass = SelectorParser.class;
public HashMap identifiers;
+
public Object result;
+
private Class resultType;
- /** Get the class that implements the ISelectorParser interface to be used by
-Selector instances.
+ /**
+* Get the class that implements the ISelectorParser interface to be used by
+* Selector instances.
*/
public static Class getSelectorParserClass()
{
return Selector.parserClass;
}
- /** Set the class that implements the ISelectorParser interface to be used by
-Selector in
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 484 Successful tests: 476 Errors:4 Failures: 4 [time of test: 14 February 2002 2:53 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Mbean dependancies
|So it then delays startup but once the EJB is deployed it does not start |the mbean. I'm I getting closer? not really, you will hold up the deployment but since the dependency logic is only present in the SARDeployer at the moment, you miss the deployment of the ejb. to do what you want you should put the ejb inside the sar, anywhere, and that will work. marcf | | |Dave Smith wrote: |> Do we have any docs on this stuff? I'm tring to create a dependancy with |> a message driven Mbean that will wait until the topic it publishes is |> created and also wait until the EJB that it uses is deployed. From a |> quick look at the example with the TopicManager it looks like you have |> to create a an MBean attribute with type ObjectName that maps to the JMX |> service you need. If that is the case how would you tie it to an EJB? |> |> Head spinning in Toronto ... |> |> |> |> ___ |> 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] CVS update: jboss/src/main/org/jboss/ejb Container.java StatefulSessionContainer.java
Is it more expensive to use log.trace? can we bypass the string creation
with trace?
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
|M Stark
|Sent: Tuesday, February 12, 2002 12:16 AM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
|Container.java StatefulSessionContainer.java
|
|
| User: starksm
| Date: 02/02/12 00:15:35
|
| Modified:src/main/org/jboss/ejb Container.java
|StatefulSessionContainer.java
| Log:
| Change all use of log.debug to log.trace for method that are in the
| invocation path or associated with timers. Debug is only for O(1)
| messages.
|
| Revision ChangesPath
| 1.72 +21 -33jboss/src/main/org/jboss/ejb/Container.java
|
| Index: Container.java
| ===
| RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
| retrieving revision 1.71
| retrieving revision 1.72
| diff -u -r1.71 -r1.72
| --- Container.java 6 Feb 2002 20:59:27 - 1.71
| +++ Container.java 12 Feb 2002 08:15:35 - 1.72
| @@ -78,7 +78,7 @@
| * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
| * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
| * @author Bill Burke
| -* @version $Revision: 1.71 $
| +* @version $Revision: 1.72 $
| *
| * Revisions:
| *
| @@ -543,50 +543,41 @@
| * Handle a operation invocation.
| */
| public Object invoke(String actionName, Object[] params,
|String[] signature)
| - throws MBeanException, ReflectionException
| - {
| -
| + throws MBeanException, ReflectionException
| + {
| if( params != null && params.length == 1 && (params[0]
|instanceof Invocation) == false )
|throw new MBeanException(new
|IllegalArgumentException("Expected zero or single Invocation argument"));
| -
| +
| Object value = null;
| Invocation mi = null;
| if( params != null && params.length == 1 )
|mi = (Invocation) params[0];
| -
| +
| ClassLoader callerClassLoader =
|Thread.currentThread().getContextClassLoader();
| + boolean trace = log.isTraceEnabled();
| try
| {
| - Thread.currentThread().setContextClassLoader(this.classLoader);
| -
| -
| +
|Thread.currentThread().setContextClassLoader(this.classLoader);
|switch (mi.getType())
|{
| -
| // Check against home, remote, localHome, local,
|getHome, getRemote, getLocalHome, getLocal
| case Invocation.REMOTE:
| -
| if (mi instanceof MarshalledInvocation)
| -
| {
| ((MarshalledInvocation)
|mi).setMethodMap(marshalledInvocationMapping);
|
| - if (log.isDebugEnabled())
| - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
|ARE INTEGRATED
| - log.debug("METHOD REMOTE INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
| -
| + // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE
|INTEGRATED
| + if( trace )
| + log.trace("METHOD REMOTE INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
| }
| // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
| else if
|(!mi.getMethod().getDeclaringClass().isAssignableFrom(remoteInterface))
| {
| -
| - if (log.isDebugEnabled())
| + if( trace )
| {
|// FIXME FIXME FIXME FIXME REMOVE WHEN CL
|ARE INTEGRATED
| - log.debug("METHOD REMOTE INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
| -
| - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
|ARE INTEGRATED
| - log.debug("WARNING: YOU ARE RUNNING
|NON-OPTIMIZED");
| + log.trace("METHOD REMOTE INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
| + log.trace("WARNING: YOU ARE RUNNING
|NON-OPTIMIZED");
| }
|
| // TEMP FIXME HACK This makes user
|transactions on the server work until
| @@ -624,24 +615,22 @@
|
| ((MarshalledInvocation)
|mi).setMethodMap(marshalledInvocationMapping);
|
| - if (log.isDebugEnabled())
| - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
|ARE INTEGRATED
| - log.debug("METHOD HOME INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||"+mi.getArgume
|nts().toString());
| + // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE
|INTEGRATED
| + if( trace )
| + log.trace("METHOD HOME INVOKE
|"+mi.getContainer()+"||"+mi.getMethod().getName()+"||"+mi.getArgume
|nts().toString());
|
| }
| // FI
[JBoss-dev] Dropping plugins directory
I think I made a mistake by adding the plugins/ sub-directory under jboss-all. I would like to get rid of it, such that all modules are peers. This means that all modules under plugins: catalina/ jboss.net/ jetty/ tomcat/ varia/ Will now be peers to build/ It is a small config change to the plugin build files (+build/build.xml) and a change to CVSROOT/modules. Since the module mappings will change you will have to pull a fresh copy of jboss-all. I am not going todo this just yet, but I think it would be a good idea to do sooner rather than later. Let me know if there are any major objections. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 484 Successful tests: 477 Errors:4 Failures: 3 [time of test: 14 February 2002 3:22 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jbossmx/src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
don't do new objectname(string) it is a pig
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Oleg
|Nitz
|Sent: Monday, February 11, 2002 4:54 PM
|To: [EMAIL PROTECTED]
|Subject: [JBoss-dev] CVS update:
|jbossmx/src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
|
|
| User: olegnitz
| Date: 02/02/11 16:53:35
|
| Modified:src/main/org/jboss/invocation/jrmp/server JRMPInvokerHA.java
| Log:
| The bean hashCode was calculated incorrectly: was
|String.hashCode(), should be (new ObjectName(String)).hashCode()
|
| Revision ChangesPath
| 1.10 +32 -19
|jbossmx/src/main/org/jboss/invocation/jrmp/server/JRMPInvokerHA.java
|
| Index: JRMPInvokerHA.java
| ===
| RCS file:
|/cvsroot/jboss/jbossmx/src/main/org/jboss/invocation/jrmp/server/JR
|MPInvokerHA.java,v
| retrieving revision 1.9
| retrieving revision 1.10
| diff -u -r1.9 -r1.10
| --- JRMPInvokerHA.java 7 Feb 2002 08:56:34 - 1.9
| +++ JRMPInvokerHA.java 12 Feb 2002 00:53:35 - 1.10
| @@ -41,7 +41,7 @@
| *
| * @author mailto:[EMAIL PROTECTED]>Bill Burke
| *
| -* @version $Revision: 1.9 $
| +* @version $Revision: 1.10 $
| */
|
| public class JRMPInvokerHA
| @@ -99,7 +99,7 @@
| state = STARTED;
| log.info("Started");
| }
| -
| +
| public void stop()
| {
| if (getState() != STARTED)
| @@ -125,49 +125,62 @@
| public void destroy()
| {
| }
| -
| +
| public void registerBean(String beanName, HATarget target)
|throws Exception
| {
| + Integer hash = new Integer((new ObjectName(beanName)).hashCode());
| log.info(" BEAN NAME IS "+beanName);
| - beanMap.put(new Integer(beanName.hashCode()), target);
| + if (beanMap.containsKey(hash)) {
| + // FIXME [oleg] In theory this is possible!
| + throw new IllegalStateException("Trying to register
|bean with the existing hashCode");
| + }
| + beanMap.put(hash, target);
| }
| -
| +
| public JRMPInvokerProxy createProxy(String beanName,
|LoadBalancePolicy policy) throws Exception
| {
| - HATarget target = (HATarget)beanMap.get(new
|Integer(beanName.hashCode()));
| + Integer hash = new Integer((new ObjectName(beanName)).hashCode());
| + HATarget target = (HATarget)beanMap.get(hash);
| + if (target == null) {
| + throw new IllegalStateException("The bean hashCode not found");
| + }
| return new JRMPInvokerProxyHA(target.getReplicants(), policy);
| }
| -
| +
| public void unregisterBean(String beanName) throws Exception
| {
| - beanMap.remove(new Integer(beanName.hashCode()));
| + Integer hash = new Integer((new ObjectName(beanName)).hashCode());
| + beanMap.remove(hash);
| }
| -
| +
| /**
| * Invoke a Remote interface method.
| */
| public Object invoke(Invocation invocation)
| throws Exception
| - {
| -
| + {
| +
| ClassLoader oldCl =
|Thread.currentThread().getContextClassLoader();
| -
| +
| try
| {
| - // Deserialize the transaction if it is there
| + // Deserialize the transaction if it is there
|
|invocation.setTransaction(importTPC(((MarshalledInvocation)
|invocation).getTransactionPropagationContext()));
| -
| +
|// Extract the ObjectName, the rest is still marshalled
|ObjectName mbean = (ObjectName)
|Registry.lookup((Integer) invocation.getContainer());
| -
| +
|long clientViewId =
|((Long)invocation.getValue("CLUSTER_VIEW_ID")).longValue();
| -
| -
| +
| +
|// The cl on the thread should be set in another interceptor
| - Object rtn = server.invoke(mbean, "", new Object[]
|{invocation}, new String[] {"java.lang.Object"});
| + Object rtn = server.invoke(mbean, "", new Object[]
|{invocation}, new String[] {"java.lang.Object"});
|HARMIResponse rsp = new HARMIResponse();
| -
| +
|HATarget target = (HATarget)beanMap.get((Integer)
|invocation.getContainer());
| + if (target == null) {
| +throw new IllegalStateException("The bean hashCode
|not found");
| + }
|if (clientViewId != target.getCurrentViewId())
|{
| rsp.newReplicants = new ArrayList(target.getReplicants());
|
|
|
|
|___
|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] message selectors
Can you please verify that things are still broken with the latest CVS (with the changes I just commited). Please submit a testcase, if you are in there and finding problems just throw something together and submit it. --jason On Wed, 2002-02-13 at 17:52, Dave Smith wrote: > Actually it's worse than that. If you change the default parser to > SelectorParser, nothing works! So a simple slector like type='cadex' bombs. > > > Jason Dillon wrote: > > I did not think we were using the old parser anymore... Is there a > > reason this is still around after Scott reimplemented in JavaCC? > > > > --jason > > > > > > On Wed, 2002-02-13 at 16:53, Dave Smith wrote: > > > >>After having a bad day trying to get a message selector working for a > >>topic listener I came across a few bugs. > >> > >>1) If the message selector is invalid but the connection is not started > >>but no error is thrown. So if you createTopicSession then > >>createSubscriber and then start the connection the connection looks good > >>but there are no messages delivered. (I spent most of the day trying to > >>sort this one out) > >> > >>2) The message selectors do not seem to like boolean types. My query is > >>app_id='AK' and production=TRUE > >> > >>3) What parser are we using for the message selectors. I thought we were > >>using javacc and jms.jj. But in Selector the default is set to parser > >>which is from jms.y. I don't even think this thing is getting > >>re-processed. I did swicth the default to SelectorParser but that did > >>not work as well. > >> > >> > >>___ > >>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] CVS update: jboss/src/main/org/jboss/ejbContainer.java StatefulSessionContainer.java
Have not actually run any tests, but I would imagine that trace is a
little slower than debug, but I can't imagine it would be that
noticeable... though I have not run any benchmarks.
I am still not too convinced that using trace over debug is that
important... especially with classes that only use trace and no debug.
The same would be achieved by simply turning on and off debug for that
class...
at the same time I like having the extra level of separation... which
allows us to provide rich debug information as we as terse debugging.
The first would be useful to track down problems inside the server,
while the second may be more useful to app designers to find out what is
going on and not getting lost by the traffic.
--jason
On Wed, 2002-02-13 at 22:18, marc fleury wrote:
> Is it more expensive to use log.trace? can we bypass the string creation
> with trace?
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> |M Stark
> |Sent: Tuesday, February 12, 2002 12:16 AM
> |To: [EMAIL PROTECTED]
> |Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
> |Container.java StatefulSessionContainer.java
> |
> |
> | User: starksm
> | Date: 02/02/12 00:15:35
> |
> | Modified:src/main/org/jboss/ejb Container.java
> |StatefulSessionContainer.java
> | Log:
> | Change all use of log.debug to log.trace for method that are in the
> | invocation path or associated with timers. Debug is only for O(1)
> | messages.
> |
> | Revision ChangesPath
> | 1.72 +21 -33jboss/src/main/org/jboss/ejb/Container.java
> |
> | Index: Container.java
> | ===
> | RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
> | retrieving revision 1.71
> | retrieving revision 1.72
> | diff -u -r1.71 -r1.72
> | --- Container.java 6 Feb 2002 20:59:27 - 1.71
> | +++ Container.java 12 Feb 2002 08:15:35 - 1.72
> | @@ -78,7 +78,7 @@
> | * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
> | * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
> | * @author Bill Burke
> | -* @version $Revision: 1.71 $
> | +* @version $Revision: 1.72 $
> | *
> | * Revisions:
> | *
> | @@ -543,50 +543,41 @@
> | * Handle a operation invocation.
> | */
> | public Object invoke(String actionName, Object[] params,
> |String[] signature)
> | - throws MBeanException, ReflectionException
> | - {
> | -
> | + throws MBeanException, ReflectionException
> | + {
> | if( params != null && params.length == 1 && (params[0]
> |instanceof Invocation) == false )
> |throw new MBeanException(new
> |IllegalArgumentException("Expected zero or single Invocation argument"));
> | -
> | +
> | Object value = null;
> | Invocation mi = null;
> | if( params != null && params.length == 1 )
> |mi = (Invocation) params[0];
> | -
> | +
> | ClassLoader callerClassLoader =
> |Thread.currentThread().getContextClassLoader();
> | + boolean trace = log.isTraceEnabled();
> | try
> | {
> | - Thread.currentThread().setContextClassLoader(this.classLoader);
> | -
> | -
> | +
> |Thread.currentThread().setContextClassLoader(this.classLoader);
> |switch (mi.getType())
> |{
> | -
> | // Check against home, remote, localHome, local,
> |getHome, getRemote, getLocalHome, getLocal
> | case Invocation.REMOTE:
> | -
> | if (mi instanceof MarshalledInvocation)
> | -
> | {
> | ((MarshalledInvocation)
> |mi).setMethodMap(marshalledInvocationMapping);
> |
> | - if (log.isDebugEnabled())
> | - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
> |ARE INTEGRATED
> | - log.debug("METHOD REMOTE INVOKE
> |"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
> | -
> | + // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE
> |INTEGRATED
> | + if( trace )
> | + log.trace("METHOD REMOTE INVOKE
> |"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
> | }
> | // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE INTEGRATED
> | else if
> |(!mi.getMethod().getDeclaringClass().isAssignableFrom(remoteInterface))
> | {
> | -
> | - if (log.isDebugEnabled())
> | + if( trace )
> | {
> |// FIXME FIXME FIXME FIXME REMOVE WHEN CL
> |ARE INTEGRATED
> | - log.debug("METHOD REMOTE INVOKE
> |"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
> | -
> | - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
> |ARE INTEGRATED
> | - log.debug("WARNING: YOU ARE RUNNING
> |NON-OPTIM
Re: [JBoss-dev] Mbean dependancies
On 2002.02.14 01:18:47 -0500 marc fleury wrote: > |So it then delays startup but once the EJB is deployed it does not start > |the mbean. I'm I getting closer? > > not really, you will hold up the deployment but since the dependency > logic > is only present in the SARDeployer at the moment, you miss the deployment > of > the ejb. Actually the RARDeployer registers RARDeployments with ServiceController so they participate in dependency management also. I changed Application and Container so EJB mbeans do this also: do you mind if I put it in before 3.0 beta? Do you want to wait until we are using jsr-77 mbeans for dependencies? david jencks > > to do what you want you should put the ejb inside the sar, anywhere, and > that will work. > > marcf > | > | > |Dave Smith wrote: > |> Do we have any docs on this stuff? I'm tring to create a dependancy > with > |> a message driven Mbean that will wait until the topic it publishes is > |> created and also wait until the EJB that it uses is deployed. From a > |> quick look at the example with the TopicManager it looks like you have > |> to create a an MBean attribute with type ObjectName that maps to the > JMX > |> service you need. If that is the case how would you tie it to an EJB? > |> > |> Head spinning in Toronto ... > |> > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java StatefulSessionContainer.java
Its not a question of the expense of log.debug vs log.trace here.
Both are used under a guard in this code and will only incur the
cost of generating the log message string if logging is requested.
The issue is that a lot of useful information is issued using
debug level messages that are not related to method invocations.
Using trace vs debug is simply a question of isolating logging messages
that are issued O(N) or higher with respect to method invocation vs debug
msgs that may be verbose, but are still O(1) with respect to method
invocations. Basically, if I am running with a filter that allows DEBUG
level messages, the log should not fill up because I run a trival stateless
session test with 100,000 method invocations. If I run with TRACE
enabled, I might be getting 1Gb of data detailing the activity at the
method invocation level.
- Original Message -
From: "marc fleury" <[EMAIL PROTECTED]>
To: "Scott M Stark" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, February 13, 2002 10:18 PM
Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
Container.java StatefulSessionContainer.java
> Is it more expensive to use log.trace? can we bypass the string creation
> with trace?
>
> marcf
>
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
> |M Stark
> |Sent: Tuesday, February 12, 2002 12:16 AM
> |To: [EMAIL PROTECTED]
> |Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb
> |Container.java StatefulSessionContainer.java
> |
> |
> | User: starksm
> | Date: 02/02/12 00:15:35
> |
> | Modified:src/main/org/jboss/ejb Container.java
> |StatefulSessionContainer.java
> | Log:
> | Change all use of log.debug to log.trace for method that are in the
> | invocation path or associated with timers. Debug is only for O(1)
> | messages.
> |
> | Revision ChangesPath
> | 1.72 +21 -33jboss/src/main/org/jboss/ejb/Container.java
> |
> | Index: Container.java
> | ===
> | RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
> | retrieving revision 1.71
> | retrieving revision 1.72
> | diff -u -r1.71 -r1.72
> | --- Container.java 6 Feb 2002 20:59:27 - 1.71
> | +++ Container.java 12 Feb 2002 08:15:35 - 1.72
> | @@ -78,7 +78,7 @@
> | * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
> | * @author mailto:[EMAIL PROTECTED]";>Scott Stark.
> | * @author Bill Burke
> | -* @version $Revision: 1.71 $
> | +* @version $Revision: 1.72 $
> | *
> | * Revisions:
> | *
> | @@ -543,50 +543,41 @@
> | * Handle a operation invocation.
> | */
> | public Object invoke(String actionName, Object[] params,
> |String[] signature)
> | - throws MBeanException, ReflectionException
> | - {
> | -
> | + throws MBeanException, ReflectionException
> | + {
> | if( params != null && params.length == 1 && (params[0]
> |instanceof Invocation) == false )
> |throw new MBeanException(new
> |IllegalArgumentException("Expected zero or single Invocation argument"));
> | -
> | +
> | Object value = null;
> | Invocation mi = null;
> | if( params != null && params.length == 1 )
> |mi = (Invocation) params[0];
> | -
> | +
> | ClassLoader callerClassLoader =
> |Thread.currentThread().getContextClassLoader();
> | + boolean trace = log.isTraceEnabled();
> | try
> | {
> | -
Thread.currentThread().setContextClassLoader(this.classLoader);
> | -
> | -
> | +
> |Thread.currentThread().setContextClassLoader(this.classLoader);
> |switch (mi.getType())
> |{
> | -
> | // Check against home, remote, localHome, local,
> |getHome, getRemote, getLocalHome, getLocal
> | case Invocation.REMOTE:
> | -
> | if (mi instanceof MarshalledInvocation)
> | -
> | {
> | ((MarshalledInvocation)
> |mi).setMethodMap(marshalledInvocationMapping);
> |
> | - if (log.isDebugEnabled())
> | - // FIXME FIXME FIXME FIXME REMOVE WHEN CL
> |ARE INTEGRATED
> | - log.debug("METHOD REMOTE INVOKE
> |"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
> | -
> | + // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE
> |INTEGRATED
> | + if( trace )
> | + log.trace("METHOD REMOTE INVOKE
> |"+mi.getContainer()+"||"+mi.getMethod().getName()+"||");
> | }
> | // FIXME FIXME FIXME FIXME REMOVE WHEN CL ARE
INTEGRATED
> | else if
> |(!mi.getMethod().getDeclaringClass().isAssignableFrom(remoteInterface))
> | {
> | -
> | - if (log.isDebugEnabled())
> | + if( trace )
> | {
> |// FIXME FIXME FIXME
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 484 Successful tests: 477 Errors:4 Failures: 3 [time of test: 14 February 2002 5:11 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-12] See http://lubega.com for full details NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
OK. it looks like it does not like the BOOLEAN token as a combo fo the
TRUE and FALSE tokens. Inlining them works. Patch inclosed.
Now the selector will parse but still does not deliver it properly.
Going to bed , have a look in the morning...
Dave Smith wrote:
> Ok. First problem solved. We have to call the SelectorParser constructor
> with at least a string reader. The problem is when you go to run ReInit
> with the actual selector it throws a NPE. So in SelectorParser.jj add
> the following to the no-args constructor
> this(new StringReader(""));
>
> Boolean slector still does not work ... looking
>
>
>
> Jason Dillon wrote:
>
>> Can you please verify that things are still broken with the latest CVS
>> (with the changes I just commited). Please submit a testcase, if you
>> are in there and finding problems just throw something together and
>> submit it.
>>
>> --jason
>>
>>
>> On Wed, 2002-02-13 at 17:52, Dave Smith wrote:
>>
>>> Actually it's worse than that. If you change the default parser to
>>> SelectorParser, nothing works! So a simple slector like type='cadex'
>>> bombs.
>>>
>>>
>>> Jason Dillon wrote:
>>>
I did not think we were using the old parser anymore... Is there a
reason this is still around after Scott reimplemented in JavaCC?
--jason
On Wed, 2002-02-13 at 16:53, Dave Smith wrote:
> After having a bad day trying to get a message selector working for
> a topic listener I came across a few bugs.
>
> 1) If the message selector is invalid but the connection is not
> started but no error is thrown. So if you createTopicSession then
> createSubscriber and then start the connection the connection looks
> good but there are no messages delivered. (I spent most of the day
> trying to sort this one out)
>
> 2) The message selectors do not seem to like boolean types. My
> query is
> app_id='AK' and production=TRUE
>
> 3) What parser are we using for the message selectors. I thought we
> were using javacc and jms.jj. But in Selector the default is set to
> parser which is from jms.y. I don't even think this thing is
> getting re-processed. I did swicth the default to SelectorParser
> but that did not work as well.
>
>
> ___
> 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
>
--- SelectorParser.jj Wed Feb 13 23:59:07 2002
+++ SelectorParser.jj.new Wed Feb 13 23:58:48 2002
@@ -55,6 +55,7 @@
public SelectorParser()
{
+this(new StringReader(""));
}
}
PARSER_END(SelectorParser)
@@ -72,9 +73,7 @@
TOKEN :
{
- < TRUE: "TRUE" | "true" >
- | < FALSE: "FALSE" | "false" >
- | < BOOLEAN: | >
+ < BOOLEAN: "TRUE" | "true" | "FALSE" | "false" >
| < NULL: "NULL" | "null" >
| < AND: "AND" | "and" >
| < NOT: "NOT" >
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/perf/test PerfTest.java
User: starksm
Date: 02/02/13 22:27:53
Modified:src/main/org/jboss/test/perf/test PerfTest.java
Log:
Print out the code sources for the ProbeHome proxy interfaces and
the local ProbeHome class code source
Revision ChangesPath
1.2 +24 -7 jbosstest/src/main/org/jboss/test/perf/test/PerfTest.java
Index: PerfTest.java
===
RCS file: /cvsroot/jboss/jbosstest/src/main/org/jboss/test/perf/test/PerfTest.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PerfTest.java 12 Feb 2002 21:34:44 - 1.1
+++ PerfTest.java 14 Feb 2002 06:27:53 - 1.2
@@ -11,6 +11,8 @@
import java.io.StringWriter;
import java.net.URL;
import java.net.URLClassLoader;
+import java.security.CodeSource;
+import java.security.ProtectionDomain;
import java.text.NumberFormat;
import javax.naming.InitialContext;
@@ -24,7 +26,7 @@
*showing the output of each test run.
@author [EMAIL PROTECTED]
- @version $Revision: 1.1 $
+ @version $Revision: 1.2 $
*/
public class PerfTest implements PerfTestMBean
{
@@ -94,9 +96,10 @@
results.append("\n+++ testTimings()");
Object obj = new InitialContext().lookup("Probe");
// Print out some codebase info for the ProbeHome
- ClassLoader cl = obj.getClass().getClassLoader();
+ Class homeClass = obj.getClass();
+ ClassLoader cl = homeClass.getClassLoader();
results.append("\nProbeHome.ClassLoader="+cl);
- ClassLoader parent = cl.getParent();
+ ClassLoader parent = cl;
while( parent != null )
{
results.append("\n.."+parent);
@@ -113,12 +116,26 @@
if( parent != null )
parent = parent.getParent();
}
-
results.append("\nProbeHome.CodeSource="+obj.getClass().getProtectionDomain().getCodeSource());
- URL objURL =
obj.getClass().getProtectionDomain().getCodeSource().getLocation();
- results.append("\nProbeHome.codebase="+objURL);
+ results.append("\nProbeHome Interfaces:");
+ Class[] ifaces = homeClass.getInterfaces();
+ for(int i = 0; i < ifaces.length; i ++)
+ {
+ results.append("\n++"+ifaces[i]);
+ ProtectionDomain pd = ifaces[i].getProtectionDomain();
+ CodeSource cs = pd.getCodeSource();
+ if( cs != null )
+results.append("\nCodeSource: "+cs);
+ else
+results.append("\nNull CodeSource");
+ }
+ CodeSource homeCS = ProbeHome.class.getProtectionDomain().getCodeSource();
+ if( homeCS != null )
+ results.append("\nPerfTest ProbHome CodeSource: "+homeCS);
+ else
+ results.append("\nPerfTest ProbHome CodeSource is NULL");
ProbeHome home = (ProbeHome) obj;
- results.append("\nFound ProbeHome @ jndiName=Probe");
+ results.append("\n\nFound ProbeHome @ jndiName=Probe");
Probe bean = home.create();
results.append("\nCreated Probe");
warmup(bean, results);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-516684 ] CCE on redeployment of ear with sar/ejb
Bugs item #516684, was opened at 2002-02-12 14:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: CCE on redeployment of ear with sar/ejb Initial Comment: The perf-service.ear in the current main testsuite is not usable across redeployments. Steps to reproduce: 1. Deploy the perf-service.ear and then execute the jboss.test:service=PerfTest runTests(100) operation. Ignore the NPE shown under testTimings. 2. Simply touch the perf-service.ear and then execute the runTests(100) operation again on the jboss.test:service=PerfTest mbean, you will see: +++ testTimingsCMT() testTimingsCMT failed: java.lang.ClassCastException: $Proxy19 at org.jboss.test.perf.test.PerfTest.testTimingsCMT (PerfTest.java:134) at org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:66) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Thread.java:484) -- >Comment By: Scott M Stark (starksm) Date: 2002-02-13 22:33 Message: Logged In: YES user_id=175228 The most recent PerfTest mbean output shows clearly what the problem is. On the initial deployment and execution of the runTests operation, both the ProbeHome interface as seen by the proxy bound in JNDI and the class reference in the PerfTest service mbean are seen to be loaded from the same perf.jar location: ProbeHome Interfaces: ++interface org.jboss.test.perf.interfaces.ProbeHome CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar ) ++interface javax.ejb.Handle CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/6.jboss- j2ee.jar ) PerfTest ProbHome CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar ) After a new deployment of the perf-service.ear, the proxy bound in JNDI continues to reference the ProxyHome class loaded from the original perf.jar, while the PerfTest service mbean ProbeHome now refers to the new perf.jar deployment: ProbeHome Interfaces: ++interface org.jboss.test.perf.interfaces.ProbeHome CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/62.60.perf.jar ) ++interface javax.ejb.Handle CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/6.jboss- j2ee.jar ) PerfTest ProbHome CodeSource: (file:/D:/usr/local/src/cvsroot/Main/jboss- all/build/output/jboss-3.0.0DR2/tmp/deploy/68.66.perf.jar ) The JNDI bindings of the proxies are not being updated correctly on redeployment. -- Comment By: Scott M Stark (starksm) Date: 2002-02-13 10:17 Message: Logged In: YES user_id=175228 That is correct. -- Comment By: David Jencks (d_jencks) Date: 2002-02-13 09:12 Message: Logged In: YES user_id=60525 I notice that you can redeploy many times successfully as long as you don't run the test. Once you have run the test, after redeploying, the test fails. deploy redeploy redeploy run test (succeeds) redeploy run test (fails) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
According to the JMS spec the reserved words are case insensitive. A
part of the TOKEN spec I use in the new EJB-QL parser follows:
TOKEN [IGNORE_CASE] : /* RESERVED WORDS */
{
< FALSE: "FALSE" >
| < NOT: "NOT" >
| < NULL: "NULL" >
| < TRUE: "TRUE" >
}
The boolean declaration won't work because you have the same regular
expression in two sections. Remember that token is part of the lexing
step where the input stream is broken into logical token. Then the
syntax part happens. If you need a production later in the grammar
which can be true or false, you would add the following bnf_prduction:
void Boolean() :
{}
{
( | )
}
I'm by no means a JavaCC expert (I'm still learning it my self), but if
you want, I'll look over your jj file when you finish.
-dain
Dave Smith wrote:
> OK. it looks like it does not like the BOOLEAN token as a combo fo the
> TRUE and FALSE tokens. Inlining them works. Patch inclosed.
>
> Now the selector will parse but still does not deliver it properly.
> Going to bed , have a look in the morning...
>
>
> Dave Smith wrote:
>
>> Ok. First problem solved. We have to call the SelectorParser
>> constructor with at least a string reader. The problem is when you go
>> to run ReInit with the actual selector it throws a NPE. So in
>> SelectorParser.jj add the following to the no-args constructor
>> this(new StringReader(""));
>>
>> Boolean slector still does not work ... looking
>>
>>
>>
>> Jason Dillon wrote:
>>
>>> Can you please verify that things are still broken with the latest CVS
>>> (with the changes I just commited). Please submit a testcase, if you
>>> are in there and finding problems just throw something together and
>>> submit it.
>>>
>>> --jason
>>>
>>>
>>> On Wed, 2002-02-13 at 17:52, Dave Smith wrote:
>>>
Actually it's worse than that. If you change the default parser to
SelectorParser, nothing works! So a simple slector like type='cadex'
bombs.
Jason Dillon wrote:
> I did not think we were using the old parser anymore... Is there a
> reason this is still around after Scott reimplemented in JavaCC?
>
> --jason
>
>
> On Wed, 2002-02-13 at 16:53, Dave Smith wrote:
>
>
>> After having a bad day trying to get a message selector working
>> for a topic listener I came across a few bugs.
>>
>> 1) If the message selector is invalid but the connection is not
>> started but no error is thrown. So if you createTopicSession then
>> createSubscriber and then start the connection the connection
>> looks good but there are no messages delivered. (I spent most of
>> the day trying to sort this one out)
>>
>> 2) The message selectors do not seem to like boolean types. My
>> query is
>> app_id='AK' and production=TRUE
>>
>> 3) What parser are we using for the message selectors. I thought
>> we were using javacc and jms.jj. But in Selector the default is
>> set to parser which is from jms.y. I don't even think this thing
>> is getting re-processed. I did swicth the default to
>> SelectorParser but that did not work as well.
>>
>>
>> ___
>> 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
>>
>
>
>
>
> --- SelectorParser.jj Wed Feb 13 23:59:07 2002
> +++ SelectorParser.jj.new Wed Feb 13 23:58:48 2002
> @@ -55,6 +55,7 @@
>
> public SelectorParser()
> {
> +this(new StringReader(""));
> }
> }
> PARSER_END(SelectorParser)
> @@ -72,9 +73,7 @@
>
> TOKEN :
> {
> - < TRUE: "TRUE" | "true" >
> - | < FALSE: "FALSE" | "false" >
> - | < BOOLEAN: | >
> + < BOOLEAN: "TRUE" | "true" | "FALSE" | "false" >
>| < NULL: "NULL" | "null" >
>| < AND: "AND" | "and" >
>| < NOT: "NOT" >
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: user57
Date: 02/02/13 23:37:32
Modified:.build.xml
Log:
o drop bogus encoding variable, so the docs will build again
Revision ChangesPath
1.58 +1 -2 jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- build.xml 13 Feb 2002 23:20:11 - 1.57
+++ build.xml 14 Feb 2002 07:37:32 - 1.58
@@ -12,7 +12,7 @@
-
+
@@ -874,7 +874,6 @@
package="${javadoc.package}"
protected="${javadoc.protected}"
private="${javadoc.private}"
- encoding="${javadoc.encoding}"
use="${javadoc.use}"
verbose="${javadoc.verbose}">
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] message selectors
If you have a chance, sanity check
messaging/src/main/org/jboss/mq/selectors/SelectorParser.jj
It has been at least 2 years since I did any active JavaCC work.
--jason
On Wed, 2002-02-13 at 23:01, Dain Sundstrom wrote:
> According to the JMS spec the reserved words are case insensitive. A
> part of the TOKEN spec I use in the new EJB-QL parser follows:
>
> TOKEN [IGNORE_CASE] : /* RESERVED WORDS */
> {
> < FALSE: "FALSE" >
> | < NOT: "NOT" >
> | < NULL: "NULL" >
> | < TRUE: "TRUE" >
> }
>
> The boolean declaration won't work because you have the same regular
> expression in two sections. Remember that token is part of the lexing
> step where the input stream is broken into logical token. Then the
> syntax part happens. If you need a production later in the grammar
> which can be true or false, you would add the following bnf_prduction:
>
> void Boolean() :
> {}
> {
> ( | )
> }
>
> I'm by no means a JavaCC expert (I'm still learning it my self), but if
> you want, I'll look over your jj file when you finish.
>
> -dain
>
> Dave Smith wrote:
>
> > OK. it looks like it does not like the BOOLEAN token as a combo fo the
> > TRUE and FALSE tokens. Inlining them works. Patch inclosed.
> >
> > Now the selector will parse but still does not deliver it properly.
> > Going to bed , have a look in the morning...
> >
> >
> > Dave Smith wrote:
> >
> >> Ok. First problem solved. We have to call the SelectorParser
> >> constructor with at least a string reader. The problem is when you go
> >> to run ReInit with the actual selector it throws a NPE. So in
> >> SelectorParser.jj add the following to the no-args constructor
> >> this(new StringReader(""));
> >>
> >> Boolean slector still does not work ... looking
> >>
> >>
> >>
> >> Jason Dillon wrote:
> >>
> >>> Can you please verify that things are still broken with the latest CVS
> >>> (with the changes I just commited). Please submit a testcase, if you
> >>> are in there and finding problems just throw something together and
> >>> submit it.
> >>>
> >>> --jason
> >>>
> >>>
> >>> On Wed, 2002-02-13 at 17:52, Dave Smith wrote:
> >>>
> Actually it's worse than that. If you change the default parser to
> SelectorParser, nothing works! So a simple slector like type='cadex'
> bombs.
>
>
> Jason Dillon wrote:
>
> > I did not think we were using the old parser anymore... Is there a
> > reason this is still around after Scott reimplemented in JavaCC?
> >
> > --jason
> >
> >
> > On Wed, 2002-02-13 at 16:53, Dave Smith wrote:
> >
> >
> >> After having a bad day trying to get a message selector working
> >> for a topic listener I came across a few bugs.
> >>
> >> 1) If the message selector is invalid but the connection is not
> >> started but no error is thrown. So if you createTopicSession then
> >> createSubscriber and then start the connection the connection
> >> looks good but there are no messages delivered. (I spent most of
> >> the day trying to sort this one out)
> >>
> >> 2) The message selectors do not seem to like boolean types. My
> >> query is
> >> app_id='AK' and production=TRUE
> >>
> >> 3) What parser are we using for the message selectors. I thought
> >> we were using javacc and jms.jj. But in Selector the default is
> >> set to parser which is from jms.y. I don't even think this thing
> >> is getting re-processed. I did swicth the default to
> >> SelectorParser but that did not work as well.
> >>
> >>
> >> ___
> >> 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
> >>
> >
> >
> >
> >
> > --- SelectorParser.jj Wed Feb 13 23:59:07 2002
> > +++ SelectorParser.jj.new Wed Feb 13 23:58:48 2002
> > @@ -55,6 +55,7 @@
> >
> > public SelectorParser()
> > {
> > +this(new StringReader(""));
> > }
> > }
> > PARSER_END(SelectorParser)
> > @@ -72,9 +73,7 @@
> >
> > TOKEN :
> > {
> > - < TRUE: "TRUE" | "true" >
> > - | < FALSE: "FALSE" | "false" >
> > - | < BOOLEAN: | >
> > + < BOOLEAN: "TRUE" | "true" | "FALSE" | "false" >
> >| < NULL: "NULL" | "null" >
> >| < AND: "AND" | "and" >
> >| < NOT: "NOT" >
> >
>
>
>
> ___
> Jboss-development mai
