[JBoss-dev] newbie question on log.trace
so I knew how to configure log4j to only show INFO, DEBUG or WARN. I am in the dark as to how to configure the TRACE thing in log4j. Is it the same? I only say TRACE? And what is the advantage over DEBUG again? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] newbie question on log.trace
If you look at the bottom of log4j.xml it has examples of enabling TRACE for some categories. For prop style, you say ...=TRACE#org.jboss.logging.XPriority Have a look at http://jboss.org/developers/guide/logging.jsp for more details. Looks like the examples need to be updated... --jason marc fleury wrote: so I knew how to configure log4j to only show INFO, DEBUG or WARN. I am in the dark as to how to configure the TRACE thing in log4j. Is it the same? I only say TRACE? And what is the advantage over DEBUG again? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] newbie question on log.trace
gee, that makes me feel good ... my own website, it is well written too and I understood :) thanks kid it is exactly what I needed marcf PS: is there a threadTrace() thingy where it creates a new file per thread that would come it and the messages are linked to a given thread going through? is that a custom logger? |-Original Message- |From: Jason Dillon [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, February 26, 2002 12:35 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] newbie question on log.trace | | |If you look at the bottom of log4j.xml it has examples of enabling |TRACE for some categories. For prop style, you say |...=TRACE#org.jboss.logging.XPriority | |Have a look at http://jboss.org/developers/guide/logging.jsp for more |details. Looks like the examples need to be updated... | |--jason | | |marc fleury wrote: | |so | |I knew how to configure log4j to only show INFO, DEBUG or WARN. | |I am in the dark as to how to configure the TRACE thing in log4j. | |Is it the same? I only say TRACE? And what is the advantage over DEBUG |again? | |marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
Does this mean that we will always have seperate .xml? Packaged is nice for classes and file systems, but when the config is inside too, then it is a pain to configure. Take jetty-plugin.sar. If a user wants to change ports or add/remove listeners then need to unjar/edit/rejar... kinda painful. If your not talking about this at all then just ignore... --jason marc fleury wrote: There is a fundamental weakness we carry in our design since 2.0 days the jboss.jcml/service.xml files we mix in SAR/jcml existence of the bean configuration of the bean classes for the bean If we change the configuration of the service we are requiring that we restart the service. Only changes through 8082/direct JMX won't do that. In short with the jcml stuff (compounded in service.xml) we actually mask one of the big features of JMX, the fact that we can reconfigure an MBean at run-time. If we touch the service.xml, we cycle everyone. The adaptation must do the following: if new file then create and configure if old file just reconfigure (don't undeploy) if file removed then undeploy Class changes need a full redeploy, which is a fundamental problem of the EJB packaging, we should be able to cycle the ejb-jar.xml files (env-entries) dynamically without warranting a redeploy and class loader ditch/class reload. I tell you, one of the biggest problem in J2EE is this artificial packaging madness. I much, much, much prefer the solution where we isolate the classes and monitor these independently cycle the deployments that depend on them but DON'T CYCLE THE XML ONLY DEPLOYMENTS, this is just a ON THE FLY reconfiguration. And unless I am so tired I don't see it, I think this solves that... we require xml only deployment with separate classes in case you want fine grained redeploy of SARs and JARs. that was ok, I think I can code that but if there is a brave soul, or a young coder looking for fame and fortune (not you Jason, you already have fame)... marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] newbie question on log.trace
PS: is there a threadTrace() thingy where it creates a new file per thread that would come it and the messages are linked to a given thread going through? is that a custom logger? You lost me here. What are you trying to track? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers/guide logging.jsp
User: user57
Date: 02/02/26 00:54:12
Modified:src/docs/developers/guide logging.jsp
Log:
o updated for xml style (have not tested that this will render correctly)
Revision ChangesPath
1.3 +52 -7 newsite/src/docs/developers/guide/logging.jsp
Index: logging.jsp
===
RCS file: /cvsroot/jboss/newsite/src/docs/developers/guide/logging.jsp,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- logging.jsp 21 Nov 2001 03:21:09 - 1.2
+++ logging.jsp 26 Feb 2002 08:54:12 - 1.3
@@ -1,5 +1,5 @@
jsp:include page=/developers/head.jsp flush=true/
-!-- $Id: logging.jsp,v 1.2 2001/11/21 03:21:09 user57 Exp $ --
+!-- $Id: logging.jsp,v 1.3 2002/02/26 08:54:12 user57 Exp $ --
jsp:include page=/developers/slogan.jsp flush=true
jsp:param name=SLOGAN value=LOGGING GUIDE/
/jsp:include
@@ -122,25 +122,70 @@
h2Activating the ttTRACE/tt Priority/h2
pActivating the ttTRACE/tt level priority is done by adding a
- category threshold statement to the ttlog4j.properties/tt file.
+ category threshold statement to the ttlog4j.xml/tt file.
To enable tracing for a particular ttJaasSecurityManager/tt security
domain called ttother/tt add:
+
+pre class=output
+ category name=org.jboss.security.plugins.JaasSecurityManager.other
+priority value=TRACE class=org.jboss.logging.XPriority/
+ /category
+/pre
+
+pTo enable the ttTRACE/tt level priority for all
+ ttJaasSecurityManager/tt instances add:
+pre class=output
+ category name=org.jboss.security.plugins.JaasSecurityManager
+priority value=TRACE class=org.jboss.logging.XPriority/
+ /category
+/pre
+
+pTo enable the ttTRACE/tt level priority for all components in the
+ ttsecurity/tt package:
+pre class=output
+ category name=org.jboss.security
+priority value=TRACE class=org.jboss.logging.XPriority/
+ /category
+/pre
+
+pYou can also redirect a given categories message to a seperate log
+ file or endpoint by assiging it a different appender. For example,
+ to redirect all ttsecurity/tt output to a ttsecurity.log/tt file,
+ and set the security package threshold to ttTRACE/tt use:
+pre class=output
+ appender name=SECURIRTYLOG class=org.apache.log4j.FileAppender
+param name=File value=${jboss.home}/log/security.log/
+param name=Append value=false/
+
+layout class=org.apache.log4j.PatternLayout
+ param name=ConversionPattern value=%d %-5p [%c] %m%n/
+/layout
+ /appender
+
+ category name=org.jboss.security
+priority value=TRACE class=org.jboss.logging.XPriority/
+appender-ref ref=SECURIRTYLOG/
+ /category
+/pre
+
+pFor properties style configuration (via log4j.properties):
pre class=output
log4j.category.org.jboss.security.plugins.JaasSecurityManager.other=\
-TRACE#org.jboss.logging.log4j.TracePriority
+TRACE#org.jboss.logging.XPriority
/pre
pTo enable the ttTRACE/tt level priority for all
ttJaasSecurityManager/tt instances add:
pre class=output
log4j.category.org.jboss.security.plugins.JaasSecurityManager=\
-TRACE#org.jboss.logging.log4j.TracePriority
+TRACE#org.jboss.logging.XPriority
/pre
pTo enable the ttTRACE/tt level priority for all components in the
ttsecurity/tt package:
pre class=output
-log4j.category.org.jboss.security=TRACE#org.jboss.logging.log4j.TracePriority
+log4j.category.org.jboss.security=\
+TRACE#org.jboss.logging.XPriority
/pre
pYou can also redirect a given categories message to a seperate log
@@ -150,12 +195,12 @@
pre class=output
### The security.log file appender
log4j.appender.SecurityLog=org.apache.log4j.FileAppender
-log4j.appender.SecurityLog.File=../log/security.log
+log4j.appender.SecurityLog.File=${jboss.home}/log/security.log
log4j.appender.SecurityLog.layout=org.apache.log4j.PatternLayout
log4j.appender.SecurityLog.layout.ConversionPattern=[%c{1}] %m%n
log4j.appender.SecurityLog.Append=false
log4j.category.org.jboss.security=\
-TRACE#org.jboss.logging.log4j.TracePriority, SecurityLog
+TRACE#org.jboss.logging.XPriority, SecurityLog
/pre
jsp:include page=/developers/navigation.jsp flush=true/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: user57 Date: 02/02/26 00:57:30 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: o using jboss.home property in config files that otherwise used ../XXX Revision ChangesPath 1.22 +1 -2 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- jboss-service.xml 24 Feb 2002 05:08:29 - 1.21 +++ jboss-service.xml 26 Feb 2002 08:57:30 - 1.22 @@ -60,7 +60,6 @@ attribute name=ConfigurationElement Configure class=org.mortbay.jetty.Server - !-- === -- !-- Add the listener-- !-- === -- @@ -83,7 +82,7 @@ !-- === -- Set name=RequestLog New class=org.mortbay.http.NCSARequestLog - ArgSystemProperty name=jetty.log default=../log//_mm_dd.request.log + ArgSystemProperty name=jboss.home/SystemProperty name=jetty.log default=../log//_mm_dd.request.log /Arg Set name=retainDays90/Set Set name=appendtrue/Set ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/conf/default log4j.xml
User: user57
Date: 02/02/26 00:57:30
Modified:src/etc/conf/default log4j.xml
Log:
o using jboss.home property in config files that otherwise used ../XXX
Revision ChangesPath
1.3 +2 -2 jboss/src/etc/conf/default/log4j.xml
Index: log4j.xml
===
RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/log4j.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- log4j.xml 24 Feb 2002 10:16:52 - 1.2
+++ log4j.xml 26 Feb 2002 08:57:30 - 1.3
@@ -7,7 +7,7 @@
!-- --
!-- = --
-!-- $Id: log4j.xml,v 1.2 2002/02/24 10:16:52 user57 Exp $ --
+!-- $Id: log4j.xml,v 1.3 2002/02/26 08:57:30 user57 Exp $ --
!--
| For more configuration infromation and examples see the Jakarta Log4j
@@ -22,7 +22,7 @@
!-- A time/date based rolling appender --
appender name=FILE class=org.apache.log4j.DailyRollingFileAppender
-param name=File value=../log/server.log/
+param name=File value=${jboss.home}/log/server.log/
param name=Append value=false/
!-- Rollover at midnight each day --
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] notes on configuration
|-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Tuesday, February 26, 2002 12:41 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] notes on configuration | | |Does this mean that we will always have seperate .xml? Packaged is nice |for classes and file systems, but when the config is inside too, then it |is a pain to configure. Take jetty-plugin.sar. If a user wants to |change ports or add/remove listeners then need to unjar/edit/rejar... |kinda painful. | |If your not talking about this at all then just ignore... That and the fact that if you need to change the configuration without shutting down the service you can't do that. a touch to jetty-plugin.sar will restart jetty. In some cases I guess that is good (the port change) in some others... the class needs to pick up the changes and we need a callback in there, somehow, somewhere, this part needs more thinking marcf | |--jason | | |marc fleury wrote: | |There is a fundamental weakness we carry in our design since 2.0 days | |the jboss.jcml/service.xml files | |we mix in SAR/jcml |existence of the bean |configuration of the bean |classes for the bean | |If we change the configuration of the service we are requiring that we |restart the service. Only changes through 8082/direct JMX won't |do that. In |short with the jcml stuff (compounded in service.xml) we actually mask one |of the big features of JMX, the fact that we can reconfigure an MBean at |run-time. If we touch the service.xml, we cycle everyone. | |The adaptation must do the following: |if new file then create and configure |if old file just reconfigure (don't undeploy) |if file removed then undeploy | |Class changes need a full redeploy, which is a fundamental problem of the |EJB packaging, we should be able to cycle the ejb-jar.xml files |(env-entries) dynamically without warranting a redeploy and class loader |ditch/class reload. I tell you, one of the biggest problem in |J2EE is this |artificial packaging madness. | |I much, much, much prefer the solution where we isolate the classes and |monitor these independently cycle the deployments that depend on them but |DON'T CYCLE THE XML ONLY DEPLOYMENTS, this is just a ON THE FLY |reconfiguration. | |And unless I am so tired I don't see it, I think this solves that... we |require xml only deployment with separate classes in case you want fine |grained redeploy of SARs and JARs. | |that was ok, I think I can code that but if there is a brave soul, or a |young coder looking for fame and fortune (not you Jason, you already have |fame)... | |marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
Why not make more usage of notifications here. Such that jetty could send a notificatioin when it needs to be redeployed due to config change. It may know best for some/most config changes. --jason marc fleury wrote: |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Tuesday, February 26, 2002 12:41 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] notes on configuration | | |Does this mean that we will always have seperate .xml? Packaged is nice |for classes and file systems, but when the config is inside too, then it |is a pain to configure. Take jetty-plugin.sar. If a user wants to |change ports or add/remove listeners then need to unjar/edit/rejar... |kinda painful. | |If your not talking about this at all then just ignore... That and the fact that if you need to change the configuration without shutting down the service you can't do that. a touch to jetty-plugin.sar will restart jetty. In some cases I guess that is good (the port change) in some others... the class needs to pick up the changes and we need a callback in there, somehow, somewhere, this part needs more thinking marcf | |--jason | | |marc fleury wrote: | |There is a fundamental weakness we carry in our design since 2.0 days | |the jboss.jcml/service.xml files | |we mix in SAR/jcml |existence of the bean |configuration of the bean |classes for the bean | |If we change the configuration of the service we are requiring that we |restart the service. Only changes through 8082/direct JMX won't |do that. In |short with the jcml stuff (compounded in service.xml) we actually mask one |of the big features of JMX, the fact that we can reconfigure an MBean at |run-time. If we touch the service.xml, we cycle everyone. | |The adaptation must do the following: |if new file then create and configure |if old file just reconfigure (don't undeploy) |if file removed then undeploy | |Class changes need a full redeploy, which is a fundamental problem of the |EJB packaging, we should be able to cycle the ejb-jar.xml files |(env-entries) dynamically without warranting a redeploy and class loader |ditch/class reload. I tell you, one of the biggest problem in |J2EE is this |artificial packaging madness. | |I much, much, much prefer the solution where we isolate the classes and |monitor these independently cycle the deployments that depend on them but |DON'T CYCLE THE XML ONLY DEPLOYMENTS, this is just a ON THE FLY |reconfiguration. | |And unless I am so tired I don't see it, I think this solves that... we |require xml only deployment with separate classes in case you want fine |grained redeploy of SARs and JARs. | |that was ok, I think I can code that but if there is a brave soul, or a |young coder looking for fame and fortune (not you Jason, you already have |fame)... | |marcf | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development | | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
WG: [JBoss-dev] JBoss/.Net plugin broken...
-Ursprüngliche Nachricht- Von: David Jencks [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 26. Februar 2002 06:29 An: Jung , Dr. Christoph Betreff: Re: [JBoss-dev] JBoss/.Net plugin broken... I think I've updated it to match the latest deployer structure -- it compiles anyway. It seems to be unable to find a deployment descriptor. I suggest that you try to find a way to deploy the servlet through packaging rather than explicitly calling the war deployer. If this won't work, you should be able to deploy it by calling deploy on MainDeployer, which would use whatever servlet engine is installed. Let me know if you would like more suggestions on how to do this. Yes, all it needs is to feed that f**cking web-application.xml to whatever WebDeployer there is. I already thought about the MainDeployer, but couldn´t yet make up my mind how to give it that xml as a war-descriptor. Repackaging would be an interesting idea which I will test ASAP. Thanks much, CGJ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] notes on configuration
|Why not make more usage of notifications here. Such that jetty could |send a notificatioin when it needs to be redeployed due to config |change. It may know best for some/most config changes. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] newbie question on log.trace
|PS: is there a threadTrace() thingy where it creates a new file per thread |that would come it and the messages are linked to a given thread going |through? is that a custom logger? | |You lost me here. What are you trying to track? A thread. A thread is coming in and collecting thread information as it goes. If 2 threads go through the log4j logger and trace do the message get mixed??? in that case it is VERY hard to debug a running system as you don't know what thread is talking. Think of that logger as a PROBE for a given thread going through. It goes through on only the messages originated by that thread get logged in a file. Ex: you are running a system, something is wrong, if you look at the logs you see 254 threads going through and the messages make no sense. You turn on the logTrace() and ONE thread that is going through gets redirected to a file (or a finite number whatever). Each file is just the talk from ONE thread. Useful for debugging the running system. Yes? marcf | |--jason | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerImpl.java ServerInfo.java ServerInfoMBean.java
Hi, Lurk mode off.. Jason Dillon wrote: o ServerImpl uses org.jboss.net.protocol.URLStreamHandlerFactory instead of setting system prop Setting the system property will work but the seperator char is '|' not ':'. The system property is a better solution as there can be only one StreamHandlerFactory registered (but the URL class only tries to load resource handlers using Class.forName() and the system-classloader so that might not work with custom classloaders). // Setup JBoss URL handlers - String handlerPkgs = System.getProperty(java.protocol.handler.pkgs, null); - if (handlerPkgs == null) - handlerPkgs = org.jboss.net.protocol; - else - handlerPkgs += :org.jboss.net.protocol; - System.setProperty(java.protocol.handler.pkgs, handlerPkgs ); + URL.setURLStreamHandlerFactory(new org.jboss.net.protocol.URLStreamHandlerFactory()); regards, Marcel Ammerlaan ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] newbie question on log.trace
You can specify %t in the appenders format to get the thread name. Look at http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/PatternLayout.html for more details. --jason marc fleury wrote: |PS: is there a threadTrace() thingy where it creates a new file per thread |that would come it and the messages are linked to a given thread going |through? is that a custom logger? | |You lost me here. What are you trying to track? A thread. A thread is coming in and collecting thread information as it goes. If 2 threads go through the log4j logger and trace do the message get mixed??? in that case it is VERY hard to debug a running system as you don't know what thread is talking. Think of that logger as a PROBE for a given thread going through. It goes through on only the messages originated by that thread get logged in a file. Ex: you are running a system, something is wrong, if you look at the logs you see 254 threads going through and the messages make no sense. You turn on the logTrace() and ONE thread that is going through gets redirected to a file (or a finite number whatever). Each file is just the talk from ONE thread. Useful for debugging the running system. Yes? marcf | |--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
Re: [JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerImpl.java ServerInfo.java ServerInfoMBean.java
Setting the system property will work but the seperator char is '|' not ':'. The system property is a better solution as there can be only one I found this out when looking at the source for URL...just looked at our jndi.properties file for an example... which is wrong. StreamHandlerFactory registered (but the URL class only tries to load resource handlers using Class.forName() and the system-classloader so that might not work with custom classloaders). We need to figure out why Class.forName() called from inside URL did not find the class then. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] newbie question on log.trace
I want just one thread though. Well I guess you can then grep for the thread name... not important thanks marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jason |Dillon |Sent: Tuesday, February 26, 2002 1:26 AM |To: marc fleury |Cc: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] newbie question on log.trace | | |You can specify %t in the appenders format to get the thread name. Look |at |http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/PatternLa |yout.html | |for more details. | |--jason | | |marc fleury wrote: | ||PS: is there a threadTrace() thingy where it creates a new file |per thread ||that would come it and the messages are linked to a given thread going ||through? is that a custom logger? || ||You lost me here. What are you trying to track? | |A thread. | |A thread is coming in and collecting thread information as it goes. | |If 2 threads go through the log4j logger and trace do the message get |mixed??? in that case it is VERY hard to debug a running system as you |don't know what thread is talking. Think of that logger as a PROBE for a |given thread going through. It goes through on only the messages |originated |by that thread get logged in a file. | |Ex: you are running a system, something is wrong, if you look at the logs |you see 254 threads going through and the messages make no sense. | You turn |on the logTrace() and ONE thread that is going through gets |redirected to |a file (or a finite number whatever). Each file is just the talk from ONE |thread. Useful for debugging the running system. | |Yes? | |marcf || ||--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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Long tmp deploy urls
These are murder when trying to debug something with deployment... do we really need this? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] newbie question on log.trace
On Tue, Feb 26, 2002 at 04:16:25AM -0800, marc fleury wrote: |PS: is there a threadTrace() thingy where it creates a new file per thread |that would come it and the messages are linked to a given thread going |through? is that a custom logger? | |You lost me here. What are you trying to track? A thread. A thread is coming in and collecting thread information as it goes. If 2 threads go through the log4j logger and trace do the message get mixed??? in that case it is VERY hard to debug a running system as you don't know what thread is talking. Think of that logger as a PROBE for a given thread going through. It goes through on only the messages originated by that thread get logged in a file. Check out the NDC(Nested Diagnostic Context) in log4j for this quote The NDC class implements nested diagnostic contexts as defined by Neil Harrison in the article Patterns for Logging Diagnostic Messages part of the book Pattern Languages of Program Design 3 edited by Martin et al. A Nested Diagnostic Context, or NDC in short, is an instrument to distinguish interleaved log output from different sources. Log output is typically interleaved when a server handles multiple clients near-simultaneously. Interleaved log output can still be meaningful if each log entry from different contexts had a distinctive stamp. This is where NDCs come into play. Note that NDCs are managed on a per thread basis. NDC operations such as push, pop(), clear(), getDepth() and setMaxDepth(int) affect the NDC of the current thread only. NDCs of other threads remain unaffected. /quote from http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html Ex: you are running a system, something is wrong, if you look at the logs you see 254 threads going through and the messages make no sense. You turn on the logTrace() and ONE thread that is going through gets redirected to a file (or a finite number whatever). Each file is just the talk from ONE thread. Useful for debugging the running system. Yes? marcf | |--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 -- regards Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] newbie question on log.trace
oka thanks :) I remember scott putting some of these NDCs around and I am thinking that the base should use these everywhere. But I guess scott is sleeping? god I am going to, got big phones tomorrow, one at 11 and one at 2... which leaves me 5 hours... easy BTW I am done with the auto-order deploy and it ... doesn't work yet :) manhana marcf |-Original Message- |From: Neale Swinnerton [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, February 26, 2002 1:35 AM |To: marc fleury |Cc: Jason Dillon; Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] newbie question on log.trace | | |On Tue, Feb 26, 2002 at 04:16:25AM -0800, marc fleury wrote: | | |PS: is there a threadTrace() thingy where it creates a new |file per thread | |that would come it and the messages are linked to a given thread going | |through? is that a custom logger? | | | |You lost me here. What are you trying to track? | | A thread. | | A thread is coming in and collecting thread information as it goes. | | If 2 threads go through the log4j logger and trace do the message get | mixed??? in that case it is VERY hard to debug a running system as you | don't know what thread is talking. Think of that logger as a PROBE for a | given thread going through. It goes through on only the |messages originated | by that thread get logged in a file. | | |Check out the NDC(Nested Diagnostic Context) in log4j for this | |quote | |The NDC class implements nested diagnostic contexts as defined by |Neil Harrison in the article Patterns for Logging Diagnostic |Messages part of the book Pattern Languages of Program Design 3 |edited by Martin et al. | |A Nested Diagnostic Context, or NDC in short, is an instrument to |distinguish interleaved log output from different sources. Log |output is typically interleaved when a server handles multiple |clients near-simultaneously. | |Interleaved log output can still be meaningful if each log entry |from different contexts had a distinctive stamp. This is where |NDCs come into play. | |Note that NDCs are managed on a per thread basis. NDC operations |such as push, pop(), clear(), getDepth() and setMaxDepth(int) |affect the NDC of the current thread only. NDCs of other threads |remain unaffected. | |/quote | |from http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html | | | | | Ex: you are running a system, something is wrong, if you look at the logs | you see 254 threads going through and the messages make no |sense. You turn | on the logTrace() and ONE thread that is going through gets |redirected to | a file (or a finite number whatever). Each file is just the |talk from ONE | thread. Useful for debugging the running system. | | Yes? | | marcf | | | |--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 | | | |-- |regards | | |Neale Swinnerton ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/web AbstractWebContainer.java
User: user57
Date: 02/02/26 01:44:56
Modified:src/main/org/jboss/web AbstractWebContainer.java
Log:
o not masking an exception trace
o a bit of debug
Revision ChangesPath
1.37 +9 -2 jboss/src/main/org/jboss/web/AbstractWebContainer.java
Index: AbstractWebContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/web/AbstractWebContainer.java,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- AbstractWebContainer.java 24 Feb 2002 19:28:19 - 1.36
+++ AbstractWebContainer.java 26 Feb 2002 09:44:56 - 1.37
@@ -148,7 +148,7 @@
@see org.jboss.security.SecurityAssociation;
@author [EMAIL PROTECTED]
-@version $Revision: 1.36 $
+@version $Revision: 1.37 $
*/
public abstract class AbstractWebContainer
extends ServiceMBeanSupport
@@ -247,7 +247,7 @@
}
catch (Exception e)
{
- log.error(Problem in init , e); throw new
DeploymentException(e.getMessage());
+ log.error(Problem in init , e); throw new DeploymentException(e);
}
log.debug(End init);
}
@@ -390,6 +390,13 @@
// If there is no webContext build one
if( webContext == null )
webContext = buildWebContext(di);
+
+ if (log.isDebugEnabled()) {
+log.debug(webContext: + webContext);
+log.debug(warURL: + warURL);
+log.debug(webAppParser: + webAppParser);
+ }
+
WebApplication warInfo = performDeploy(webContext, warURL.toString(),
webAppParser);
deploymentMap.put(warURL.toString(), warInfo);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
Thank you for asking Dain... Don't feel alone... ... JBoss: All your J2EE are belong to us Maybe I'm an idiot, but what the hell does this mean? -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] init/create calls with subpackaging not in the same order
Hello David, I doubt it is essential, however... init usually just identifies the deployment descriptor and file to watch. There is some advantage to locating this as soon as possible, to help avoid runaway redeploys in case of failure later. If an expected deployment descriptor is missing, you could stop immediately. Create and start pretty much need to be done inside out since usually outside packages depend on whats inside (applications depending on their ejb modules for instance). OK, thank you for explaining. You may doubt it is essential but in fact it is when you build such compound packages that depend on others: you need to know what to package in what. If P1 depends on P2, do I need P1 in P2 or P2 in P1? Which is why I was asking. And you gave me a brillant answer! Cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/bin run.sh
User: user57 Date: 02/02/26 01:53:29 Modified:src/bin run.sh Log: o don't need to be in bin/ dir to start anymore Revision ChangesPath 1.3 +1 -7 jboss-system/src/bin/run.sh Index: run.sh === RCS file: /cvsroot/jboss/jboss-system/src/bin/run.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- run.sh25 Feb 2002 02:33:16 - 1.2 +++ run.sh26 Feb 2002 09:53:29 - 1.3 @@ -5,7 +5,7 @@ ## ## ### == ### -### $Id: run.sh,v 1.2 2002/02/25 02:33:16 user57 Exp $ ### +### $Id: run.sh,v 1.3 2002/02/26 09:53:29 user57 Exp $ ### DIRNAME=`dirname $0` PROGNAME=`basename $0` @@ -105,9 +105,6 @@ # Setup JBoss sepecific properties JAVA_OPTS=$JAVA_OPTS -Djboss.boot.loader.name=$PROGNAME -# Where we need to be to start the server -startdir=$JBOSS_HOME/bin - # For Cygwin, switch paths to Windows format before running java if $cygwin; then JBOSS_HOME=`cygpath --path --windows $JBOSS_HOME` @@ -130,9 +127,6 @@ echo echo echo - -# Make sure we are in the correctly directory -cd $startdir if $useprofiler; then # Hand over control to profiler ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: user57 Date: 02/02/26 01:56:18 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: o ../ breaks things, I hope this is treated as a URL, else should use fil.sep* here instead Revision ChangesPath 1.23 +1 -1 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- jboss-service.xml 26 Feb 2002 08:57:30 - 1.22 +++ jboss-service.xml 26 Feb 2002 09:56:18 - 1.23 @@ -82,7 +82,7 @@ !-- === -- Set name=RequestLog New class=org.mortbay.http.NCSARequestLog - ArgSystemProperty name=jboss.home/SystemProperty name=jetty.log default=../log//_mm_dd.request.log + ArgSystemProperty name=jboss.home/SystemProperty name=jetty.log default=/log//_mm_dd.request.log /Arg Set name=retainDays90/Set Set name=appendtrue/Set ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-522893 ] Do not have to be in bin/ when starting
Change Notes item #522893, was opened at 2002-02-26 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522893group_id=22866 Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: Jason Dillon (user57) Assigned to: Jason Dillon (user57) Summary: Do not have to be in bin/ when starting Initial Comment: JBoss does not required that the starting directory for the JVM be bin/ anymore. This behavior was masked with the unix run.sh script before, but has been fixed for win32/batch users as well. Some odd relative path problems should now go away when using the unix script, as it will not change the working directory before starting the vm. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=522893group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerImpl.java ServerInfo.java ServerInfoMBean.java
Jason Dillon wrote: StreamHandlerFactory registered (but the URL class only tries to load resource handlers using Class.forName() and the system-classloader so that might not work with custom classloaders). We need to figure out why Class.forName() called from inside URL did not find the class then. I found this out the hard way (in another context). java.net.URL is loaded by the bootstrap classloader. Class.forName() will therefore only look at the classloader for java.net.URL (which is the bootstrap classloader) and the system classloader. When the resource handler is only available to a custom classloader the handler will not be found. A solution (and I filed a report with Sun), is to include the thread context-classloader when looking for a resource handler inside the URL class. For now, there is no neat solution.. regards, Marcel Ammerlaan ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging and more...]
Hi Jason, I've got a problem integrating JBossMX with your new Server code. In ServerLoader.load(ClassLoader) you construct a URLClassLoader and set it as the TCL (Thread class loader). This is for dynamically loading classes from configuration options. But Server.start() does not have this TCL. We do the same config processing in JBossMX, we can't find the classes during MBeanServerFactory.createMBeanServer(jboss) :-( Looks pretty good besides. P.S. You misspelt DEFUALT_BOOT_LIBRARY_LIST :-) Regards, Adrian Again for those that missed it... --jason Original Message Subject: Embedable, ServerLoader, jboss-boot.jar, logging and more... Date: Sun, 24 Feb 2002 03:37:31 -0800 From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] With the seperation changes also come the first major embedable change that I was planning, which was the introduction of the ServerLoader component. SL performs similar functionality as the newly added Boot utiltiy, but provides a JBoss specific interface with the sole purpose of loading the central Server component (which sets up the GPA/MicroKernel/Core system). jboss-boor.jar contains all of the required files to bootstrap (load and start) the Server component. It contains Server, ServerConfig and ServerLoader and is about 5k (with javac.debug=true). It provides a raw API to load, initialize and start a Server instance. ServerLoader accepts a parent CL for delegation, per Scott's list. To help keep things small, Server and ServerConfig have been turned into interfaces. I have provided implemeations for both as ServerImpl andf ServerConfigImpl, which perform the same basic functions they did before. MBean interfaces are also provided for these. To further keep things small (as well as expose more control to clients), server configuration is now initially property based. I followed the InitialContext aproache read config properties from a passed in Properties map. Cleints can create a map that will default to System.getProperties() thus allowing more control over how the server is configured. For example to change the temporray dir that is used by default, the client would: props.setProperty(ServerConfig.TEMP_DIR, R, /some/path/tmp); or on the command line (via Main): ./run.sh sh -Dorg.jboss.system.server.temp.dir=/some/path/tmp Defaults are still constructed in the previous value, only ServerConfig.HOME_DIR needs to be set, everything else can be calculated from there. See the javadoc for Server ServerConfig for more information. I said that config is initially property based, as once the Server impl is loaded a typed adapter (ServerConfigImpl) is created to allow typed access to the values provided here (and thus keeping clients from having to perfrom the same redundant data conversion). Since all (practically) libraries are now loaded off network and the classes on the system classpath have been minimized, the utility of a lib/ lib/ext seperation (as well as spineURL and such) have deminished. I have removed usage of these to reduce complexity. All library files go into lib/ now. Now that we can load log4j from the network durring bootstrapping, the core components now make use of it directly instead of using BootstrapLogger. A default log4j.properties file is provided in run.jar whichs sets up the default enviroment. Users can override this behavior by using log4j specific configuration. Log4jService still allows the config file to be read from system properties though. Javadoc in Main shows how todo this. May want to provide a default debug config in run.jar to avoid needing to append to the classpath... Since the core components now use log4j Main had to be updated to use the ServerLoader. I added a few more command line options to expose more control by allowing extra libraries and classpath URs to be specified. This is mostly to allow the above log4j override bits to work as well as allow any JAXP or JMX impl to work. Only crimson and xerces are supported by the --jaxp option, but by specifing the extra libs and the full jaxp factory impl properties on the command line any jaxp parser can be used. Same goes for JMX, right now only the RI is available, but if you specify the lib of another it will be prepended to the classpath and thus used first. To top things off Server will now append org.jboss.net.protocol to the protocol handler list, making these protocols available to the entire server. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9653
[JBoss-dev] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
Bugs item #521058, was opened at 2002-02-21 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=521058group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Argument type mismatch after redeploy Initial Comment: Bug: Deploy hello.jar, then undeploy, then redeploy it again. After the redeployment calling the hello method with a string parameter still works, but passing a HelloData instance as parameter in the howdy() method results in an IllegalArgumentException: 2002-02-21 17:36:19,188 INFO [org.jboss.ejb.EJBDeployer] Undeploying:file:/D:/apps/jboss/jboss- 3.0.0beta/deploy/hello.jar 2002-02-21 17:36:19,188 INFO [org.jboss.deployment.MainDeployer] could not delete directory file:/D:/apps/jboss/jboss- 3.0.0beta/tmp/deploy/70.hello.jar restart will delete it 2002-02-21 17:36:19,188 INFO [org.jboss.deployment.MainDeployer] Undeployed file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar 2002-02-21 17:36:39,392 INFO [org.jboss.deployment.MainDeployer] Deploying: file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar 2002-02-21 17:36:39,517 INFO [org.jboss.ejb.EJBDeployer] Deploying HelloWorld 2002-02-21 17:36:44,236 ERROR [org.jboss.invocation.jrmp.server.JRMPInvoker] operation failed java.rmi.ServerException: argument type mismatch; nested exception is: java.lang.IllegalArgumentException: argument type mismatch java.lang.IllegalArgumentException: argument type mismatch at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterc eptor.invoke(StatelessSessionContainer.java:642) at org.jboss.ejb.plugins.StatelessSessionInstanceIntercept or.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:127) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke (StatelessSessionContainer.java:308) at org.jboss.ejb.Container.invoke (Container.java:630) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1555) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke (JRMPInvoker.java:364) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch (Unknown Source) at sun.rmi.transport.Transport$1.run(Unknown Source) at java.security.AccessController.doPrivileged (Native Method) at sun.rmi.transport.Transport.serviceCall (Unknown Source) at sun.rmi.transport.tcp.TCPTransport.handleMessages (Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru n(Unknown Source) at java.lang.Thread.run(Unknown Source) Context: RH from CVS (less than one hour old) jdk1.3.1_02 from Sun JBoss-3.0.0beta CVSTag=Rel_3_0_0_3 Default config OS-System: Windows NT 4.0,x86 This happens on Windows NT as well as on Solaris. (On Solaris removing the jar during undeployment works, on WindowsNT never). The only way I have found to get around this is to restart the server. Georg -- Comment By: David Jencks (d_jencks) Date: 2002-02-26 05:15 Message: Logged In: YES user_id=60525 I think this is the remote version of the problem with classloaders seen in 516684 and 519699. If so it should be fixed only when we run on jbossmx. Any other opinions? david jencks -- Comment By: Georg Schmid (giorgio42) Date: 2002-02-23 06:09 Message: Logged In: YES user_id=437570 The easiest way to reproduce this error is to run the test suite a second time without restarting the server. After the second run has completed: testsuite\output\loggrep -n IllegalArgumentException *.log|wc -l 10 Some BeanUnitTestCase suffers from the same problem. This really gives me the breaks with JBoss, because I have to restart the server each time I need to redeploy an EJB. Any ideas? Any help? If someone is willing to point me in the right direction I'll attack this myself (have to), but currently I have no clue what could cause these exceptions. (I've been working all day with JBoss for the last two and a half month, making transitions from 2.4.4 to 3.0alpha to 3.0beta. Now that my project is approaching production mode, JBoss seems kind of messed up. And
Re: [JBoss-dev] Long tmp deploy urls
On 2002.02.26 04:31:22 -0500 Jason Dillon wrote: These are murder when trying to debug something with deployment... do we really need this? --jason I think so. They got longer so security permissions were determinable. They also let you predict where your deployment package will end up. Try putting jboss near the root of your filesystem;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-522617 ] Redeploy broken with tmp/deploy changes
Bugs item #522617, was opened at 2002-02-25 12:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 7 Submitted By: Scott M Stark (starksm) Assigned to: Nobody/Anonymous (nobody) Summary: Redeploy broken with tmp/deploy changes Initial Comment: With the change to use the original component jar name under the tmp/deploy directory we have regressed back to the ZipFile cache bug. Because the same file name is used for the initial deploy and subsequent deploys the jar contents are cached by the ZipFile under jdk1.3 and redeploy either fails with a java.lang.InternalError jzentry == 0, or the contents are not updated. I also see the same problem under jdk1.4 where I thought this issue was supposed to be fixed. Its simple to produce the problem. Run the org.jboss.test.hello.test.HelloTimingStressTestCase one, change the print statements in the org.jboss.test.hello.ejb.HelloBean class, rerun the HelloTimingStressTestCase and the reploy fails. Two solutions are: 1. Make the orig path name a directory under tmp/deploy and place uniqued jars under the directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/hello.jar/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/hello.jar/01.hello.jar The benefit of this approach is that one can still assign security permissions on a per component jar basis. 2. Only use the orig path upto the last directory. For example: origJar: /test/lib/hello.jar deployJar : jboss.home/tmp/deploy/test/lib/00.hello.jar redeployJar : jboss.home/tmp/deploy/test/lib/01.hello.jar This might be simpler but it limits the ability to set security permissions to the container directory. This is not that big a restriction as this is usually how one does permissions. -- Comment By: David Jencks (d_jencks) Date: 2002-02-26 05:16 Message: Logged In: YES user_id=60525 I think I fixed the zipfile part of this problem (I implemented (1)), but since it worked (got argument type mismatch) on my linux system anyway I can't check for sure. -- Comment By: Georg Schmid (giorgio42) Date: 2002-02-26 00:03 Message: Logged In: YES user_id=437570 No, the argument type mismatch is not windows specific. I get that with Solaris, too. It has nothing to do with this bug. The argument type mismatch bug is apparent for at least a week. It's more about a new proxy generated on redeploy, but reusing the first one and no rebinding. David already pointed to the CCE sar redeployment bug. That's from 2002-02-12. Redeploy has been totally broken since then (makes it impossible to pass any non-primitive type to a remote method call after a redeploy without restarting the server). Georg -- Comment By: Scott M Stark (starksm) Date: 2002-02-25 15:01 Message: Logged In: YES user_id=175228 I see the same thing on win2k if I rerun without modifying the hello.jar so I think that issue is a seperate class loader problem. Comitting the name change will fix the jar caching problem and then we can move on to why the straight redeploy fails. -- Comment By: David Jencks (d_jencks) Date: 2002-02-25 14:37 Message: Logged In: YES user_id=60525 I'm confused. I find that if I redeploy hello.jar and rerun the tests, I get java.rmi.ServerException: argument type mismatch; nested exception is: java.lang.IllegalArgumentException: argument type mismatch java.lang.IllegalArgumentException: argument type mismatch at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessi... This is with or without implementing solution (1), and with or without changing/recompiling hello.jar. Is this a windows only problem? I think the argument mismatch may be caused by a classloader issue like with calling an ejb from an mbean, but I haven't investigated. Want me to commit suggestion(1) anyway? david jencks -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=522617group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] notes on configuration
If we used ModelMBeans, the Attribute's desriptor could include a field runtimeConfigurable. The service deployer can then determine if a redeploy is required. Regards, Adrian |Why not make more usage of notifications here. Such that jetty could |send a notificatioin when it needs to be redeployed due to config |change. It may know best for some/most config changes. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-user] RE: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
Go searhc for All your base belong to us at google. You will be busy for hours reading about it. The short answer is that is was a bad translation in an old Nintendo game. It then moved into Photoshoping All your bases belong to us all over pictures. This was really big over a year ago. Later Jim -Original Message- From: Sacha Labourey Sent: Tue 2/26/2002 4:09 AM To: Dain Sundstrom; marc fleury Cc: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-user] RE: [JBoss-dev] Tshirts at JavaOne FREE TRAINING Thank you for asking Dain... Don't feel alone... ... JBoss: All your J2EE are belong to us Maybe I'm an idiot, but what the hell does this mean? -dain ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user winmail.dat
Re: [JBoss-dev] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
Bugs item #521058, was opened at 2002-02-21 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=37668 aid=521058group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Argument type mismatch after redeploy Comment By: David Jencks (d_jencks) Date: 2002-02-26 05:15 Message: Logged In: YES user_id=60525 I think this is the remote version of the problem with classloaders seen in 516684 and 519699. If so it should be fixed only when we run on jbossmx. Any other opinions? david jencks Hi David, I've fixed problem 519699. It fixes some problems with wars when running with JBossMX :-) It doesn't fix the perf tests. :-( I reported a while ago that MBeanClassLoaders are not being garbage collected, I didn't locate what was holding onto them. Could this be the problem? I forgot to add it the buglist :-( Regards, Adrian _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9283 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] newbie question on log.trace
Sounds like you need a custom log4j appender. Regards, Hiram From: marc fleury [EMAIL PROTECTED] To: Jason Dillon [EMAIL PROTECTED] CC: Jboss-Development@Lists. Sourceforge. Net [EMAIL PROTECTED] Subject: RE: [JBoss-dev] newbie question on log.trace Date: Tue, 26 Feb 2002 04:16:25 -0800 |PS: is there a threadTrace() thingy where it creates a new file per thread |that would come it and the messages are linked to a given thread going |through? is that a custom logger? | |You lost me here. What are you trying to track? A thread. A thread is coming in and collecting thread information as it goes. If 2 threads go through the log4j logger and trace do the message get mixed??? in that case it is VERY hard to debug a running system as you don't know what thread is talking. Think of that logger as a PROBE for a given thread going through. It goes through on only the messages originated by that thread get logged in a file. Ex: you are running a system, something is wrong, if you look at the logs you see 254 threads going through and the messages make no sense. You turn on the logTrace() and ONE thread that is going through gets redirected to a file (or a finite number whatever). Each file is just the talk from ONE thread. Useful for debugging the running system. Yes? marcf | |--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 _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/serverServerImpl.java ServerInfo.java ServerInfoMBean.java
StreamHandlerFactory registered (but the URL class only tries to load resource handlers using Class.forName() and the system-classloader so that might not work with custom classloaders). We need to figure out why Class.forName() called from inside URL did not find the class then. --jason I'm not sure, but I think Class.forName will only load classes that are in the same classloader that current class was loaded from. In your case (the system classloader since Class.forName() is called from URL). So you have to ask yourself, is my protocol class in the system classloader? So I think that is the problem. The URL class should have used the ContextClassLoader to load the class. Regards, Hiram _ Chat with friends online, try MSN Messenger: http://messenger.msn.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Tshirts at JavaOne FREE TRAINING
Definitely. I'd like to be able to display my support for JBoss in any way possible, especially since I'm still one of those punks trying to make his first contribs and having a t-shirt and/or stickers is an easy way to do that. ;) A friend of mine did a small sticker business a couple of years ago (it was for a Pagan Fish sticker...ala the Jesus Fish and Darwin Fish), and so I'd be happy to find out where she had hers produced. I'd be happy to step forward and handle this kind of merchandising...provided there's sufficient demand. -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 5:37 PM To: marc fleury Cc: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: Re: [JBoss-dev] Tshirts at JavaOne FREE TRAINING It's kinda late... but what about stickers? I would put one on my car and motorcycle... I would guess that others would too... --jason marc fleury wrote: OK we have a winner, well actually we have two. JBoss: All your J2EE are belong to us JBoss: May the source be with you Thanks for all the great proposals. We chose based on we won and went with classic stuff. So we put an order for 1000 of them, which is going to cost us AN ARM AND A LEG and take a bulky 21 boxes space that we need a truck to move. You guys better show up and buy them. WE WILL TIE IN A RAFFLE: BUY A T-SHIRT, AND GET A FREE SPOT AT A JBOSS GROUP TRAINING. Buy a t-shirt, give us your b-card, and we will pick a winner on wednesday night, you get a free training with the gurus ($3500 cost). For those that can't come to JBoss One, if you give us a bulk order of 10 + shipping ($230) then we will put you in the raffle but the order needs to reach us before the end of the JB1 conference when we will pick a winner, so you basically have a month to put the order. We will put the information online but basically write to a href=mailto:[EMAIL PROTECTED]?subject=10 tshirts pleasesales/a and when we get your paypal payment we will send it. You will join the raffle. We will put this online. BTW for the raffle it is ONE card PER tshirt. So if you buy 10 t-shirts you multiply your chances by 10. Is this as good as it gets? take care see you there, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] notes on configuration
On 2002.02.26 08:57:05 -0500 Adrian Brock wrote: If we used ModelMBeans, the Attribute's desriptor could include a field runtimeConfigurable. The service deployer can then determine if a redeploy is required. Regards, Adrian Yes. Also there is the choice of -change attribute value while mbean is started -stop, change attribute value, start -stop, destroy, create(with new values), start -stop, destroy, remove, install, create(with new valuew), start These could all be specified w/model mbean attributes. I think this whole question is also getting into how will we use mbean persistence? and just what is that replacement for jboss-auto.jcml? david jencks |Why not make more usage of notifications here. Such that jetty could |send a notificatioin when it needs to be redeployed due to config |change. It may know best for some/most config changes. correct, jetty knows best what requires a restart and what does not, all this handling should be done inside the MBean. we will get there, see, you are talking now :) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-dev lopment _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 ___ 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: RE: [JBoss-dev] notes on configuration
|If we used ModelMBeans, the Attribute's desriptor |could include a field runtimeConfigurable. |The service deployer can then determine if a redeploy |is required. ohhh so pretty we will use modelMBeans very soon, if we could get you get to put something out marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
On 2002.02.26 09:12:21 -0500 Adrian Brock wrote: Bugs item #521058, was opened at 2002-02-21 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=37668 aid=521058group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Nobody/Anonymous (nobody) Summary: Argument type mismatch after redeploy Comment By: David Jencks (d_jencks) Date: 2002-02-26 05:15 Message: Logged In: YES user_id=60525 I think this is the remote version of the problem with classloaders seen in 516684 and 519699. If so it should be fixed only when we run on jbossmx. Any other opinions? david jencks Hi David, I've fixed problem 519699. It fixes some problems with wars when running with JBossMX :-) It doesn't fix the perf tests. :-( I reported a while ago that MBeanClassLoaders are not being garbage collected, I didn't locate what was holding onto them. Could this be the problem? I forgot to add it the buglist :-( Regards, Adrian Great! I think marc is busy removing mbeanclassloaders anyway, we will see what happens next with that. Does jbossmx have any effect on this can't redeploy problem? (run hello test twice, no changes needed). How can I run jboss on jbossmx? Thanks david jencks _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9283 ___ 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] We need more configurations in the distribution
Another idea on this. Maybe it would also be useful to have a /lib directory under the default and minimal directories. And we guide people to put their application jars in there instead of jboss/lib/ext or jboss/lib. That way, jboss libraries are kept separate from application libraries. Or is this too confusing? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, February 25, 2002 6:50 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] We need more configurations in the distribution No, he thought David's idea of moving everything to deploy was a bad idea. The suggestion from Hiram was: jboss/ jboss/bin/ jboss/lib/ jboss/client/ jboss/servers/default jboss/servers/default/conf jboss/servers/default/tmp jboss/servers/default/db jboss/servers/default/deploy jboss/servers/minimal jboss/servers/minimal/conf jboss/servers/minimal/tmp jboss/servers/minimal/db jboss/servers/minimal/deploy etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 25, 2002 3:28 PM Subject: RE: [JBoss-dev] We need more configurations in the distribution I thought Marc nixed this idea -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, February 25, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] We need more configurations in the distribution That is fine with me. ___ 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: RE: [JBoss-dev] notes on configuration
3 of 4 imho |Yes. Also there is the choice of |-change attribute value while mbean is started yes |-stop, change attribute value, start yes |-stop, destroy, create(with new values), start no (use below) |-stop, destroy, remove, install, create(with new valuew), start yes |These could all be specified w/model mbean attributes. yes |I think this whole question is also getting into how will we use mbean |persistence? and just what is that replacement for jboss-auto.jcml? right, you got your JMX book? If only I could get the flacid fin to get out of his hole marcf | |david jencks | | |Why not make more usage of notifications here. Such | that jetty could | |send a notificatioin when it needs to be redeployed | due to config | |change. It may know best for some/most config | changes. | | correct, jetty knows best what requires a restart and | what does not, all | this handling should be done inside the MBean. | | we will get there, see, you are talking now :) | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-dev | lopment | | | | _ | View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 | | ___ | 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] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
Bugs item #521058, was opened at 2002-02-21 08:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=521058group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Schmid (giorgio42)
Assigned to: Scott M Stark (starksm)
Summary: Argument type mismatch after redeploy
Initial Comment:
Bug:
Deploy hello.jar, then undeploy, then redeploy it
again.
After the redeployment calling the hello method
with a string parameter still works, but passing
a HelloData instance as parameter in the howdy()
method results in an IllegalArgumentException:
2002-02-21 17:36:19,188 INFO
[org.jboss.ejb.EJBDeployer]
Undeploying:file:/D:/apps/jboss/jboss-
3.0.0beta/deploy/hello.jar
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] could not delete
directory file:/D:/apps/jboss/jboss-
3.0.0beta/tmp/deploy/70.hello.jar restart will delete
it
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] Undeployed
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,392 INFO
[org.jboss.deployment.MainDeployer] Deploying:
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,517 INFO
[org.jboss.ejb.EJBDeployer] Deploying HelloWorld
2002-02-21 17:36:44,236 ERROR
[org.jboss.invocation.jrmp.server.JRMPInvoker]
operation failed
java.rmi.ServerException: argument type mismatch;
nested exception is:
java.lang.IllegalArgumentException: argument
type mismatch
java.lang.IllegalArgumentException: argument type
mismatch
at java.lang.reflect.Method.invoke(Native
Method)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:642)
at
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:96)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:167)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:61)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:127)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:166)
at
org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContainer.java:308)
at org.jboss.ejb.Container.invoke
(Container.java:630)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1555)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke
(JRMPInvoker.java:364)
at java.lang.reflect.Method.invoke(Native
Method)
at sun.rmi.server.UnicastServerRef.dispatch
(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown
Source)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru
n(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Context: RH from CVS (less than one hour old)
jdk1.3.1_02 from Sun
JBoss-3.0.0beta CVSTag=Rel_3_0_0_3
Default config
OS-System: Windows NT 4.0,x86
This happens on Windows NT as well as on Solaris.
(On Solaris removing the jar during undeployment works,
on WindowsNT never).
The only way I have found to get around this
is to restart the server.
Georg
--
Comment By: Scott M Stark (starksm)
Date: 2002-02-26 08:22
Message:
Logged In: YES
user_id=175228
The HelloData class is not seen to be an instance of the
bean method's argument signature type even though they have
the same class loader instance. If I catch the
IllegalArgumentException and dump out the ejb method sig
classes and classloaders they match the incoming argument
data, and yet, the arg data is not seen to be an instance
of the signature class.
2002-02-26 08:27:17,312 ERROR
[org.jboss.ejb.StatelessSessionContainer] Failed to invoke
method: public java.lang.String
org.jboss.test.hello.ejb.HelloBean.howdy
(org.jboss.test.hello.interfaces.HelloData)
2002-02-26 08:27:17,312 ERROR
[org.jboss.ejb.StatelessSessionContainer] Method
DeclaringClassCL:
org.jboss.system.UnifiedClassLoader@bd89e22d{
url=file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/tmp/deploy/D/usr/local/src/cvsroot/Main/jboss-
all/testsuite/output/lib/hello.jar }
2002-02-26 08:27:17,312 ERROR
[org.jboss.ejb.StatelessSessionContainer] MethodArgType[0]:
class org.jboss.test.hello.interfaces.HelloData
2002-02-26 08:27:17,312 ERROR
[org.jboss.ejb.StatelessSessionContainer] MethodArgType[0]
ClassLoader:
Re: [JBoss-dev] Auto-resolving dependencies/deployment
Cool idea to solve the class loading dependency, but I think we still need explicit dependency declarations. The problem I still see is the need to have some services started (i.e. initialized) before others (e.g. db driver setup before a ejb can deploy). Oh, I just thought of another problem. In my code, I try to load the classes that are specified in the deployment descriptor. What happens if the user makes a typo and I try to load something like java.lang.OObject. Will deployment hang forever? -dain marc fleury wrote: |I don't think this is a problem. The client is most likely a thread started |by noticing a new package. Anyway, I think we need anyway a list of |waiting deployments -- partly deployed stuff that is waiting. Now we Yes, I am afraid of the verbosity of it. |have mbeans that can be waiting for mbeans, with marc's idea we'd have |classes waiting for classes also. If we can look at the list and say not classes, deploymentInfo level (meaning anything entering the system). This is deployments waiting on deployments (through classes waiting on classes). Then mapping to the MBean is done as well. We will collect the dependency at the class level. |there's a problem, kill this guy or hmmm, I see I forgot to deploy |package X I think it will be fine without any timeouts. well the time out is OK, no big deal. The only issue is do you want to drop a package and then another and they are picked in different cycles and it still works, but if you FORGET to drop the package, I would want to say CLASS NOT FOUND so you know you forgot, hence the timeout being useful (imho). Small point. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] notes on configuration
On 2002.02.26 13:38:37 -0500 marc fleury wrote: 3 of 4 imho |Yes. Also there is the choice of |-change attribute value while mbean is started yes |-stop, change attribute value, start yes |-stop, destroy, create(with new values), start no (use below) I agree, just trying to be complete. |-stop, destroy, remove, install, create(with new valuew), start yes |These could all be specified w/model mbean attributes. yes |I think this whole question is also getting into how will we use mbean |persistence? and just what is that replacement for jboss-auto.jcml? right, you got your JMX book? yup. If only I could get the flacid fin to get out of his hole Right now I'm working on xdoclet tags xmbean xml (I want to get this in xdoclet 1.1.2, this weekend) and xmbean modifications to go with improved xmbean dtd. Then we can start converting all our mbeans to xmbean. Maybe I should include a hard coded named descriptor tag like update-service-level (STARTED|STOPPED|REMOVED) (otherwise we would have a descriptor name=update-service-level value=STARTED attribute) Suggestions for the names appreciated;-) I'm thinking in the back of my mind that there must be some way to use the xmbean xml and the *service.xml in combination more efficiently, but I don't know what it is yet. david jencks marcf | |david jencks | | |Why not make more usage of notifications here. Such | that jetty could | |send a notificatioin when it needs to be redeployed | due to config | |change. It may know best for some/most config | changes. | | correct, jetty knows best what requires a restart and | what does not, all | this handling should be done inside the MBean. | | we will get there, see, you are talking now :) | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-dev | lopment | | | | _ | View thread online: http://main.jboss.org/thread.jsp?forum=66thread=9657 | | ___ | 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Auto-resolving dependencies/deployment
|Cool idea to solve the class loading dependency, but I think we still |need explicit dependency declarations. The problem I still see is the yes, that is still there, |need to have some services started (i.e. initialized) before others |(e.g. db driver setup before a ejb can deploy). | |Oh, I just thought of another problem. In my code, I try to load the |classes that are specified in the deployment descriptor. What happens |if the user makes a typo and I try to load something like |java.lang.OObject. Will deployment hang forever? I can do a time-out based CL, easy marcf | |-dain | |marc fleury wrote: | | |I don't think this is a problem. The client is most likely a |thread started | |by noticing a new package. Anyway, I think we need anyway a list of | |waiting deployments -- partly deployed stuff that is waiting. Now we | | Yes, I am afraid of the verbosity of it. | | |have mbeans that can be waiting for mbeans, with marc's idea we'd have | |classes waiting for classes also. If we can look at the list and say | | not classes, deploymentInfo level (meaning anything entering the system). | This is deployments waiting on deployments (through classes waiting on | classes). Then mapping to the MBean is done as well. We will collect the | dependency at the class level. | | |there's a problem, kill this guy or hmmm, I see I forgot to deploy | |package X I think it will be fine without any timeouts. | | well the time out is OK, no big deal. The only issue is do you |want to drop | a package and then another and they are picked in different cycles and it | still works, but if you FORGET to drop the package, I would want to say | CLASS NOT FOUND so you know you forgot, hence the timeout being useful | (imho). Small point. | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] notes on configuration
David,
bringing you to the training was the best thing ever,
since then you have become quite the man ...
|Right now I'm working on xdoclet tags xmbean xml (I want to get this in
|xdoclet 1.1.2, this weekend) and xmbean modifications to go with improved
|xmbean dtd. Then we can start converting all our mbeans to xmbean. Maybe
|I should include a hard coded named descriptor tag like
|
|update-service-level (STARTED|STOPPED|REMOVED)
|
|(otherwise we would have a
|descriptor name=update-service-level value=STARTED
|attribute)
|
|Suggestions for the names appreciated;-)
This is unclear though, are you saying what should the service controller
do on a change?
if that is the question then the values should be
state-action-on-update {KEEP-RUNNING| RE-START | RE-INSTANCIATE}
|I'm thinking in the back of my mind that there must be some way to use the
|xmbean xml and the *service.xml in combination more efficiently, but I
|don't know what it is yet.
remember the law of the 2 ideas, only when you know clearly what it is and
what it does do we want to hear about it :)
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] AAAHOOO JBoss in London!
marc fleury wrote: Ok, yes, it sounds like a corny song from the late 70's ... Hey don't knock it - Lee Ho Fooks actually had it in their window in Chinatown last time I looked: As featured in Warren Zevon's 'Werewolves of London'. Maybe you could hold your JBoss meal there this time ... Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] notes on configuration
|This is unclear though, are you saying what should the service controller
|do on a change?
|if that is the question then the values should be
|
|state-action-on-update {KEEP-RUNNING| RE-START | RE-INSTANCIATE}
hey supposedly JSR 111 deals with this? does it? the HP guys have been
talking about it like it was something special so maybe we could find out?
marcf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523030 ] java.io.NotSerializableException: org.jb
Bugs item #523030, was opened at 2002-02-26 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523030group_id=22866 Category: JBossSX Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Schouten (schouten_drkw) Assigned to: Nobody/Anonymous (nobody) Summary: java.io.NotSerializableException: org.jb Initial Comment: Hi, trying to upgrade my application fom jboss 2.4.3 jetty 3.1.1 to jboss2.4.4 jetty 3.1.3. The ejb-server returns a handle of a SFSB to the jsp- client. While the client call 'getEJBObject' on the handle it get's the exception below. Andreas [Default] java.rmi.ServerException: Could not get EJBObject; nested exception is : java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1148) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.io.ObjectOutputStream.outputClassFields (ObjectOutputStre am.java:1827) [Default] [Default] at java.io.ObjectOutputStream.defaultWriteObject (ObjectOutputStr eam.java:480) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1214) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvoc ation. writeExternal(RemoteMethodInvocation.java:256) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1172) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.rmi.MarshalledObject.init (MarshalledObject.java:95) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.StatefulHandleImp l.getE JBObject(StatefulHandleImpl.java:127) [Default] [Default] at eacm.jsp_frame.RemoteData.getData (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.init (Unknown Source) [Default] [Default] at java.lang.reflect.Constructor.newInstance(Native Method) [Default] [Default] at eacm.jsp_frame.Reflect.getInstanceOf (Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.newObject(Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.getTargetByRequest (Unknown Source) [Default] [Default] at eacm.tagext.control.Void.doStartTag (Unknown Source) [Default] [Default] at pages._0002fpages_0002fstatus_0002ejspstatus_jsp_0._jsp Servic e (_0002fpages_0002fstatus_0002ejspstatus_jsp_0.java:127) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java: 339) [Default] [Default] at org.apache.jasper.runtime.PageContextImpl.include (PageContext Impl.java:414) [Default] [Default] at _0002feacm_0002ejspeacm_jsp_0._jspService (_0002feacm_0002ejsp eacm_jsp_0.java:1082) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandle r.java:403) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:10 37) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:99 2) [Default] [Default] at
[JBoss-dev] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
Bugs item #521058, was opened at 2002-02-21 08:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=521058group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Schmid (giorgio42)
Assigned to: Scott M Stark (starksm)
Summary: Argument type mismatch after redeploy
Initial Comment:
Bug:
Deploy hello.jar, then undeploy, then redeploy it
again.
After the redeployment calling the hello method
with a string parameter still works, but passing
a HelloData instance as parameter in the howdy()
method results in an IllegalArgumentException:
2002-02-21 17:36:19,188 INFO
[org.jboss.ejb.EJBDeployer]
Undeploying:file:/D:/apps/jboss/jboss-
3.0.0beta/deploy/hello.jar
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] could not delete
directory file:/D:/apps/jboss/jboss-
3.0.0beta/tmp/deploy/70.hello.jar restart will delete
it
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] Undeployed
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,392 INFO
[org.jboss.deployment.MainDeployer] Deploying:
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,517 INFO
[org.jboss.ejb.EJBDeployer] Deploying HelloWorld
2002-02-21 17:36:44,236 ERROR
[org.jboss.invocation.jrmp.server.JRMPInvoker]
operation failed
java.rmi.ServerException: argument type mismatch;
nested exception is:
java.lang.IllegalArgumentException: argument
type mismatch
java.lang.IllegalArgumentException: argument type
mismatch
at java.lang.reflect.Method.invoke(Native
Method)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:642)
at
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:96)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:167)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:61)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:127)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:166)
at
org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContainer.java:308)
at org.jboss.ejb.Container.invoke
(Container.java:630)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1555)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke
(JRMPInvoker.java:364)
at java.lang.reflect.Method.invoke(Native
Method)
at sun.rmi.server.UnicastServerRef.dispatch
(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown
Source)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru
n(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Context: RH from CVS (less than one hour old)
jdk1.3.1_02 from Sun
JBoss-3.0.0beta CVSTag=Rel_3_0_0_3
Default config
OS-System: Windows NT 4.0,x86
This happens on Windows NT as well as on Solaris.
(On Solaris removing the jar during undeployment works,
on WindowsNT never).
The only way I have found to get around this
is to restart the server.
Georg
--
Comment By: Scott M Stark (starksm)
Date: 2002-02-26 09:27
Message:
Logged In: YES
user_id=175228
With the latest changes to unique the tmp/deploy file
copied in from the original, the class loaders dumped out
at the time of exception now show a difference:
2002-02-26 09:28:58,500 ERROR
[org.jboss.ejb.StatelessSessionContainer] Method
DeclaringClassCL:
org.jboss.system.UnifiedClassLoader@66e10648{
url=file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/tmp/deploy/D/usr/local/src/cvsroot/Main/jboss-
all/testsuite/output/lib/hello.jar/65.hello.jar }
2002-02-26 09:28:58,515 ERROR
[org.jboss.ejb.StatelessSessionContainer] MethodArgType[0]:
class org.jboss.test.hello.interfaces.HelloData
2002-02-26 09:28:58,515 ERROR
[org.jboss.ejb.StatelessSessionContainer] MethodArgType[0]
ClassLoader: org.jboss.system.UnifiedClassLoader@66e10648{
url=file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/tmp/deploy/D/usr/local/src/cvsroot/Main/jboss-
all/testsuite/output/lib/hello.jar/65.hello.jar }
2002-02-26 09:28:58,515 ERROR
[org.jboss.ejb.StatelessSessionContainer] BeanCL:
org.jboss.system.UnifiedClassLoader@66e10648{
url=file:/D:/usr/local/src/cvsroot/Main/jboss-
[JBoss-dev] [ jboss-Bugs-523060 ] EJB's in EAR files - Classpath Failure
Bugs item #523060, was opened at 2002-02-26 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Cook (oravecz) Assigned to: Nobody/Anonymous (nobody) Summary: EJB's in EAR files - Classpath Failure Initial Comment: When an EJB is packaged, its manifest file may reference another library using its Classpath attribute. If the EJB is deployed, the jar's referenced by the manifest are resolved using the JAR as the root. If the EJB JAR is packaged in an EAR file, the Classpath attribute for the EJB JAR should be resolved relative to the *EAR* file. This is not happening in jBoss 3.0 Beta. With the new /tmp flat directory filenaming scheme, it is not apparent to me how any jars in a classpath manifest can be located. This is due to the libraries being prefixed with a number (i.e. 47.ejbhelper.jar) and represented in a flat structure. Under these circumstances how can a manifest classpath of './lib/ejbhelper.jar' ever be found? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523060 ] EJB's in EAR files - Classpath Failure
Bugs item #523060, was opened at 2002-02-26 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Jim Cook (oravecz) Assigned to: David Jencks (d_jencks) Summary: EJB's in EAR files - Classpath Failure Initial Comment: When an EJB is packaged, its manifest file may reference another library using its Classpath attribute. If the EJB is deployed, the jar's referenced by the manifest are resolved using the JAR as the root. If the EJB JAR is packaged in an EAR file, the Classpath attribute for the EJB JAR should be resolved relative to the *EAR* file. This is not happening in jBoss 3.0 Beta. With the new /tmp flat directory filenaming scheme, it is not apparent to me how any jars in a classpath manifest can be located. This is due to the libraries being prefixed with a number (i.e. 47.ejbhelper.jar) and represented in a flat structure. Under these circumstances how can a manifest classpath of './lib/ejbhelper.jar' ever be found? -- Comment By: David Jencks (d_jencks) Date: 2002-02-26 10:27 Message: Logged In: YES user_id=60525 Look before you leap. This is the same issue as 520676, which was fixed shortly after jboss beta. The manifest references are pretty much ignored, but all the classes are loaded anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523060 ] EJB's in EAR files - Classpath Failure
Bugs item #523060, was opened at 2002-02-26 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Jim Cook (oravecz) Assigned to: David Jencks (d_jencks) Summary: EJB's in EAR files - Classpath Failure Initial Comment: When an EJB is packaged, its manifest file may reference another library using its Classpath attribute. If the EJB is deployed, the jar's referenced by the manifest are resolved using the JAR as the root. If the EJB JAR is packaged in an EAR file, the Classpath attribute for the EJB JAR should be resolved relative to the *EAR* file. This is not happening in jBoss 3.0 Beta. With the new /tmp flat directory filenaming scheme, it is not apparent to me how any jars in a classpath manifest can be located. This is due to the libraries being prefixed with a number (i.e. 47.ejbhelper.jar) and represented in a flat structure. Under these circumstances how can a manifest classpath of './lib/ejbhelper.jar' ever be found? -- Comment By: marc fleury (mnf999) Date: 2002-02-26 10:48 Message: Logged In: YES user_id=174548 Yeah in fact we should clearly state that the manifest entries are fully ignored. And maybe only log a debug message about it. It seems to confuse people when it is in fact working correctly due to the Unified Deployers pick of classes marcf -- Comment By: David Jencks (d_jencks) Date: 2002-02-26 10:27 Message: Logged In: YES user_id=60525 Look before you leap. This is the same issue as 520676, which was fixed shortly after jboss beta. The manifest references are pretty much ignored, but all the classes are loaded anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-511503 ] jboss 3.0 Performance
Bugs item #511503, was opened at 2002-01-31 16:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511503group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Fixed Priority: 5 Submitted By: Ken Sipe (kensipe) Assigned to: marc fleury (mnf999) Summary: jboss 3.0 Performance Initial Comment: jboss group provided a tomcat-test.ear for evaluating the performance gained without the rmi stack. The average optimized speed was around .06 ms on jboss 2.4.4. In testing this with jboss 3.0. The average speed was .5 ms, this is the optimized number. -- Comment By: marc fleury (mnf999) Date: 2002-02-26 10:51 Message: Logged In: YES user_id=174548 oh forgot, the default 3.0 distribution had the logging set to DEBUG (alpha release) so there was a lot of verbosity. We are set on INFO now and the times are what they should be,i.e. on par with 2.4 -- Comment By: marc fleury (mnf999) Date: 2002-02-04 09:19 Message: Logged In: YES user_id=174548 Ok I do see this and I am working on it with Oleg Nitz, frankly this looks like there is no optimization at all.. I will double check it does go through the optimized path. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=511503group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523030 ] java.io.NotSerializableException: org.jb
Bugs item #523030, was opened at 2002-02-26 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523030group_id=22866 Category: JBossSX Group: v2.4 (stable) Status: Closed Resolution: None Priority: 5 Submitted By: Andreas Schouten (schouten_drkw) Assigned to: Dan Christopherson (danch) Summary: java.io.NotSerializableException: org.jb Initial Comment: Hi, trying to upgrade my application fom jboss 2.4.3 jetty 3.1.1 to jboss2.4.4 jetty 3.1.3. The ejb-server returns a handle of a SFSB to the jsp- client. While the client call 'getEJBObject' on the handle it get's the exception below. Andreas [Default] java.rmi.ServerException: Could not get EJBObject; nested exception is : java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1148) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.io.ObjectOutputStream.outputClassFields (ObjectOutputStre am.java:1827) [Default] [Default] at java.io.ObjectOutputStream.defaultWriteObject (ObjectOutputStr eam.java:480) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1214) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvoc ation. writeExternal(RemoteMethodInvocation.java:256) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1172) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.rmi.MarshalledObject.init (MarshalledObject.java:95) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.StatefulHandleImp l.getE JBObject(StatefulHandleImpl.java:127) [Default] [Default] at eacm.jsp_frame.RemoteData.getData (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.init (Unknown Source) [Default] [Default] at java.lang.reflect.Constructor.newInstance(Native Method) [Default] [Default] at eacm.jsp_frame.Reflect.getInstanceOf (Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.newObject(Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.getTargetByRequest (Unknown Source) [Default] [Default] at eacm.tagext.control.Void.doStartTag (Unknown Source) [Default] [Default] at pages._0002fpages_0002fstatus_0002ejspstatus_jsp_0._jsp Servic e (_0002fpages_0002fstatus_0002ejspstatus_jsp_0.java:127) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java: 339) [Default] [Default] at org.apache.jasper.runtime.PageContextImpl.include (PageContext Impl.java:414) [Default] [Default] at _0002feacm_0002ejspeacm_jsp_0._jspService (_0002feacm_0002ejsp eacm_jsp_0.java:1082) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandle r.java:403) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:10 37) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:99 2) [Default] [Default] at
[JBoss-dev] [ jboss-Bugs-521058 ] Argument type mismatch after redeploy
Bugs item #521058, was opened at 2002-02-21 08:53
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=521058group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Georg Schmid (giorgio42)
Assigned to: Scott M Stark (starksm)
Summary: Argument type mismatch after redeploy
Initial Comment:
Bug:
Deploy hello.jar, then undeploy, then redeploy it
again.
After the redeployment calling the hello method
with a string parameter still works, but passing
a HelloData instance as parameter in the howdy()
method results in an IllegalArgumentException:
2002-02-21 17:36:19,188 INFO
[org.jboss.ejb.EJBDeployer]
Undeploying:file:/D:/apps/jboss/jboss-
3.0.0beta/deploy/hello.jar
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] could not delete
directory file:/D:/apps/jboss/jboss-
3.0.0beta/tmp/deploy/70.hello.jar restart will delete
it
2002-02-21 17:36:19,188 INFO
[org.jboss.deployment.MainDeployer] Undeployed
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,392 INFO
[org.jboss.deployment.MainDeployer] Deploying:
file:/D:/apps/jboss/jboss-3.0.0beta/deploy/hello.jar
2002-02-21 17:36:39,517 INFO
[org.jboss.ejb.EJBDeployer] Deploying HelloWorld
2002-02-21 17:36:44,236 ERROR
[org.jboss.invocation.jrmp.server.JRMPInvoker]
operation failed
java.rmi.ServerException: argument type mismatch;
nested exception is:
java.lang.IllegalArgumentException: argument
type mismatch
java.lang.IllegalArgumentException: argument type
mismatch
at java.lang.reflect.Method.invoke(Native
Method)
at
org.jboss.ejb.StatelessSessionContainer$ContainerInterc
eptor.invoke(StatelessSessionContainer.java:642)
at
org.jboss.ejb.plugins.StatelessSessionInstanceIntercept
or.invoke(StatelessSessionInstanceInterceptor.java:77)
at
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext
(AbstractTxInterceptor.java:96)
at
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti
ons(TxInterceptorCMT.java:167)
at
org.jboss.ejb.plugins.TxInterceptorCMT.invoke
(TxInterceptorCMT.java:61)
at
org.jboss.ejb.plugins.SecurityInterceptor.invoke
(SecurityInterceptor.java:127)
at org.jboss.ejb.plugins.LogInterceptor.invoke
(LogInterceptor.java:166)
at
org.jboss.ejb.StatelessSessionContainer.invoke
(StatelessSessionContainer.java:308)
at org.jboss.ejb.Container.invoke
(Container.java:630)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1555)
at
com.sun.management.jmx.MBeanServerImpl.invoke
(MBeanServerImpl.java:1523)
at
org.jboss.invocation.jrmp.server.JRMPInvoker.invoke
(JRMPInvoker.java:364)
at java.lang.reflect.Method.invoke(Native
Method)
at sun.rmi.server.UnicastServerRef.dispatch
(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown
Source)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(Unknown Source)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.ru
n(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Context: RH from CVS (less than one hour old)
jdk1.3.1_02 from Sun
JBoss-3.0.0beta CVSTag=Rel_3_0_0_3
Default config
OS-System: Windows NT 4.0,x86
This happens on Windows NT as well as on Solaris.
(On Solaris removing the jar during undeployment works,
on WindowsNT never).
The only way I have found to get around this
is to restart the server.
Georg
--
Comment By: Scott M Stark (starksm)
Date: 2002-02-26 11:25
Message:
Logged In: YES
user_id=175228
I added debugging to the java.lang.Class.forName method to
catch where the obsolete class was coming from and it is
due to the MarshalledObject resolution of the HelloData
object coming in with the method invocation. The call stack
is:
2002-02-26 11:06:37,828 INFO [STDOUT] Class.forName
(HelloData,boolean,CL=org.jboss.system.UnifiedClassLoader@86
eaae86{ url=file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/tmp/deploy/D/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/lib/jboss.jar/30.jboss.jar }),
CL=org.jboss.system.UnifiedClassLoader@d1fc5387{
url=file:/D:/usr/local/src/cvsroot/Main/jboss-
all/build/output/jboss-
3.0.0beta2/tmp/deploy/D/usr/local/src/cvsroot/Main/jboss-
all/testsuite/output/lib/hello.jar/64.hello.jar }
2002-02-26 11:06:37,843 ERROR [STDERR] java.lang.Exception:
Stack trace
2002-02-26 11:06:37,843 ERROR [STDERR] at
java.lang.Thread.dumpStack(Thread.java:993)
2002-02-26 11:06:37,843 ERROR [STDERR] at
java.lang.Class.forName(Class.java:205)
2002-02-26 11:06:37,843 ERROR [STDERR] at
java.io.ObjectInputStream.resolveClass
(ObjectInputStream.java:654)
[JBoss-dev] Boot time , FAST
with a simple fix I added yesterday (making sure we don't cycle through the UCL iterator if we have the class) the boot time on my machine goes back down to 4 seconds which is on par (even a bit faster) than 2.4 I will commit my stuff as soon as I can resolve a few sillyness things on the JNP implementation (who said refactoring is needed?) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523030 ] java.io.NotSerializableException: org.jb
Bugs item #523030, was opened at 2002-02-26 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523030group_id=22866 Category: JBossSX Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Andreas Schouten (schouten_drkw) Assigned to: Dan Christopherson (danch) Summary: java.io.NotSerializableException: org.jb Initial Comment: Hi, trying to upgrade my application fom jboss 2.4.3 jetty 3.1.1 to jboss2.4.4 jetty 3.1.3. The ejb-server returns a handle of a SFSB to the jsp- client. While the client call 'getEJBObject' on the handle it get's the exception below. Andreas [Default] java.rmi.ServerException: Could not get EJBObject; nested exception is : java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] java.io.NotSerializableException: org.jboss.jetty.JBossUserRealm [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1148) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.io.ObjectOutputStream.outputClassFields (ObjectOutputStre am.java:1827) [Default] [Default] at java.io.ObjectOutputStream.defaultWriteObject (ObjectOutputStr eam.java:480) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1214) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.RemoteMethodInvoc ation. writeExternal(RemoteMethodInvocation.java:256) [Default] [Default] at java.io.ObjectOutputStream.outputObject (ObjectOutputStream.ja va:1172) [Default] [Default] at java.io.ObjectOutputStream.writeObject (ObjectOutputStream.jav a:366) [Default] [Default] at java.rmi.MarshalledObject.init (MarshalledObject.java:95) [Default] [Default] at org.jboss.ejb.plugins.jrmp.interfaces.StatefulHandleImp l.getE JBObject(StatefulHandleImpl.java:127) [Default] [Default] at eacm.jsp_frame.RemoteData.getData (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.create (Unknown Source) [Default] [Default] at eacm.jsp_frame.RemoteData.init (Unknown Source) [Default] [Default] at java.lang.reflect.Constructor.newInstance(Native Method) [Default] [Default] at eacm.jsp_frame.Reflect.getInstanceOf (Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.newObject(Unknown Source) [Default] [Default] at eacm.jsp_frame.SessionDataFactory.getTargetByRequest (Unknown Source) [Default] [Default] at eacm.tagext.control.Void.doStartTag (Unknown Source) [Default] [Default] at pages._0002fpages_0002fstatus_0002ejspstatus_jsp_0._jsp Servic e (_0002fpages_0002fstatus_0002ejspstatus_jsp_0.java:127) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.Dispatcher.include (Dispatcher.java: 339) [Default] [Default] at org.apache.jasper.runtime.PageContextImpl.include (PageContext Impl.java:414) [Default] [Default] at _0002feacm_0002ejspeacm_jsp_0._jspService (_0002feacm_0002ejsp eacm_jsp_0.java:1082) [Default] [Default] at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.jav a:119) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.apache.jasper.servlet.JspServlet$JspServletWrapper. servic e(JspServlet.java:176) [Default] [Default] at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServle t.java:307) [Default] [Default] at org.apache.jasper.servlet.JspServlet.service (JspServlet.java: 380) [Default] [Default] at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) [Default] [Default] at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder. java:488) [Default] [Default] at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandle r.java:403) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:10 37) [Default] [Default] at org.mortbay.http.HandlerContext.handle (HandlerContext.java:99 2) [Default] [Default] at
RE: [JBoss-dev] Auto-resolving dependencies/deployment
hmmm it is a bit trickier than that. Some of the parts of RMI RELY on the exception being thrown (looking for a skeleton for example). So we really need to throw that exception. The bottom line is that I guess the best we can do is wait for the end of a deployment. That makes the deployer code tied to the system libraries but it also forces me to implement the full tracking I always wanted to do ... hm... I might try it. If I can do it today, it would really be powerful. The feature: Compute the set of dependent object classes (transitive closure of dependents in working man terms) and cycle them as one as the classes change. This avoids the I changed B but A that references B is invalid so it is broken How do we fix this, well we cycle the whole island. marcf |-Original Message- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, February 26, 2002 8:20 AM |To: marc fleury |Cc: David Jencks; Jason Dillon; Jboss-Development @ Lists . Sourceforge |. Net |Subject: Re: [JBoss-dev] Auto-resolving dependencies/deployment | | |Cool idea to solve the class loading dependency, but I think we still |need explicit dependency declarations. The problem I still see is the |need to have some services started (i.e. initialized) before others |(e.g. db driver setup before a ejb can deploy). | |Oh, I just thought of another problem. In my code, I try to load the |classes that are specified in the deployment descriptor. What happens |if the user makes a typo and I try to load something like |java.lang.OObject. Will deployment hang forever? | |-dain | |marc fleury wrote: | | |I don't think this is a problem. The client is most likely a |thread started | |by noticing a new package. Anyway, I think we need anyway a list of | |waiting deployments -- partly deployed stuff that is waiting. Now we | | Yes, I am afraid of the verbosity of it. | | |have mbeans that can be waiting for mbeans, with marc's idea we'd have | |classes waiting for classes also. If we can look at the list and say | | not classes, deploymentInfo level (meaning anything entering the system). | This is deployments waiting on deployments (through classes waiting on | classes). Then mapping to the MBean is done as well. We will collect the | dependency at the class level. | | |there's a problem, kill this guy or hmmm, I see I forgot to deploy | |package X I think it will be fine without any timeouts. | | well the time out is OK, no big deal. The only issue is do you |want to drop | a package and then another and they are picked in different cycles and it | still works, but if you FORGET to drop the package, I would want to say | CLASS NOT FOUND so you know you forgot, hence the timeout being useful | (imho). Small point. | | marcf | | | ___ | Jboss-development mailing list | [EMAIL PROTECTED] | https://lists.sourceforge.net/lists/listinfo/jboss-development | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-523060 ] EJB's in EAR files - Classpath Failure
Bugs item #523060, was opened at 2002-02-26 10:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Jim Cook (oravecz) Assigned to: David Jencks (d_jencks) Summary: EJB's in EAR files - Classpath Failure Initial Comment: When an EJB is packaged, its manifest file may reference another library using its Classpath attribute. If the EJB is deployed, the jar's referenced by the manifest are resolved using the JAR as the root. If the EJB JAR is packaged in an EAR file, the Classpath attribute for the EJB JAR should be resolved relative to the *EAR* file. This is not happening in jBoss 3.0 Beta. With the new /tmp flat directory filenaming scheme, it is not apparent to me how any jars in a classpath manifest can be located. This is due to the libraries being prefixed with a number (i.e. 47.ejbhelper.jar) and represented in a flat structure. Under these circumstances how can a manifest classpath of './lib/ejbhelper.jar' ever be found? -- Comment By: Jim Cook (oravecz) Date: 2002-02-26 14:16 Message: Logged In: YES user_id=6215 So any jar file anywhere in my ear directory structure is exposed to my EJBs that are contained in the jar? This approach doesn't seem to violate 23.4 (EJB 2.0 FR), but there should be some clear documentation on how class/package conflicts are resolved. -- Comment By: marc fleury (mnf999) Date: 2002-02-26 10:48 Message: Logged In: YES user_id=174548 Yeah in fact we should clearly state that the manifest entries are fully ignored. And maybe only log a debug message about it. It seems to confuse people when it is in fact working correctly due to the Unified Deployers pick of classes marcf -- Comment By: David Jencks (d_jencks) Date: 2002-02-26 10:27 Message: Logged In: YES user_id=60525 Look before you leap. This is the same issue as 520676, which was fixed shortly after jboss beta. The manifest references are pretty much ignored, but all the classes are loaded anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=523060group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] split Deployer/Auto-Deployer
Ok, It is ripe :) I remember reading some mails talking about Auto-Deployment separated from MainDeployer. I believe it is time to do that :) so if there is a taker... if not I might do it, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Shutdown needs some cleanup
I'm seeing the MainDeployer still trying to to deploys during the shutdown sequence. Isn't this one of the first services stopped? 15:00:22,734 INFO [Server] Shutdown complete 15:00:22,734 INFO [STDOUT] Shutdown complete 15:00:22,734 ERROR [SARDeployer] operation failed javax.management.InstanceNotFoundException: jboss.system:service=MainDeployer at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1678) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1522) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy1.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:489) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:176) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:545) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:514) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:496) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:317) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:304) at java.lang.Thread.run(Thread.java:484) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] I think we need our own MarshalledObject
The second bug related to class loading problems(#521058) is another problem that occurs when a MarshalledObject value is gotten and Class.forName(String, boolean, ClassLoader) is used. This time, the call occurs when a non-proxy class is being resolved and the code does not try to use the thread context class loader. Rather, it walks the call stack to find the first non-system ClassLoader on the stack. The stack that is in effect is: java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at java.lang.Class.forName(Class.java:205) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654) at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:121) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.inputArray(ObjectInputStream.java:1142) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:374) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.rmi.MarshalledObject.get(MarshalledObject.java:138) at org.jboss.invocation.MarshalledInvocation.getValue(MarshalledInvocation.java :281) at org.jboss.invocation.Invocation.getArguments(Invocation.java:167) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stateles sSessionContainer.java:649) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSe ssionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor .java:96) ... The first class loader from a non-system ClassLoader is org.jboss.invocation.MarshalledInvocation which is loaded by the jboss.jar class loader. Since this class loader does not change when an ejb is redeployed, any ejb calls that pass in types that are loaded from the ejb jar are seen to be in conflict with the reployed values because Class.forName is returning the previously loaded byte code due to the jboss.jar ClassLoader to VM cache match. We need more control over which class loader is being used when accessing MarshalledObject value contents. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/ejbql Alternation.java ApproximateNumericToken.java Assembler.java Assembly.java AssemblySet.java DeepCloneable.java Empty.java ExactNumericToken.java InputParameter.java InputParameterState.java InputParameterToken.java Literal.java NumberState.java NumericLiteral.java Optional.java Parser.java QuoteState.java Repetition.java Sequence.java StringLiteral.java StringToken.java Symbol.java SymbolState.java SymbolToken.java Terminal.java Token.java Tokenizer.java TokenizerState.java WhitespaceState.java Word.java WordState.java WordToken.java
User: dsundstrom Date: 02/02/26 15:15:18 Removed: src/main/org/jboss/ejb/plugins/cmp/ejbql Alternation.java ApproximateNumericToken.java Assembler.java Assembly.java AssemblySet.java DeepCloneable.java Empty.java ExactNumericToken.java InputParameter.java InputParameterState.java InputParameterToken.java Literal.java NumberState.java NumericLiteral.java Optional.java Parser.java QuoteState.java Repetition.java Sequence.java StringLiteral.java StringToken.java Symbol.java SymbolState.java SymbolToken.java Terminal.java Token.java Tokenizer.java TokenizerState.java WhitespaceState.java Word.java WordState.java WordToken.java Log: Replaced with new JavaCC based EJB-QL compiler. ___ 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/cmp/jdbc/ejbql AbstractSchema.java CMPField.java CMRField.java EJBQLParser.java EntityPathElement.java IdentifierManager.java PathElement.java SQLGenerator.java SQLTarget.java
User: dsundstrom Date: 02/02/26 15:15:19 Removed: src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql AbstractSchema.java CMPField.java CMRField.java EJBQLParser.java EntityPathElement.java IdentifierManager.java PathElement.java SQLGenerator.java SQLTarget.java Log: Replaced with new JavaCC based EJB-QL compiler. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] I think we need our own MarshalledObject
|The first class loader from a non-system ClassLoader is |org.jboss.invocation.MarshalledInvocation which is loaded good catch. It reminds of the good ol' days with Rickard when he would say this is a bug in the JDK. Go right ahead then. marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] More Ear crap ..
Ok what is the currennt status of the ear deployment in the latest head? I am using a hacked version of cactus where I replaced Class.forName() with Thread.currentThread.getContextClassLoader().loadClass(). My ear looks like 0 Tue Feb 26 17:58:22 EST 2002 META-INF/ 45 Tue Feb 26 17:58:22 EST 2002 META-INF/MANIFEST.MF 228627 Tue Feb 26 17:58:22 EST 2002 cadexTest.war 274 Thu Jan 24 16:22:42 EST 2002 META-INF/application.xml The war looks like 0 Tue Feb 26 17:58:22 EST 2002 META-INF/ 45 Tue Feb 26 17:58:22 EST 2002 META-INF/MANIFEST.MF 0 Tue Feb 26 17:58:22 EST 2002 WEB-INF/ 164 Fri Jan 25 10:14:28 EST 2002 WEB-INF/jboss-web.xml 0 Tue Feb 26 17:58:22 EST 2002 WEB-INF/lib/ 117522 Thu Jan 03 16:12:36 EST 2002 WEB-INF/lib/junit.jar 71832 Tue Feb 26 17:58:12 EST 2002 WEB-INF/lib/cactus.jar 38464 Tue Feb 26 09:14:02 EST 2002 WEB-INF/lib/cadex-client.jar 28510 Tue Feb 26 16:42:16 EST 2002 WEB-INF/lib/cadex-test.jar 1750 Wed Feb 20 13:45:02 EST 2002 WEB-INF/lib/candata_test_util.jar 506 Thu Jan 24 15:21:14 EST 2002 WEB-INF/web.xml Now when I go to run this thing I get ( ServletTestCase is in cactus.jar) [junit] org/apache/cactus/ServletTestCase [junit] java.lang.NoClassDefFoundError: org/apache/cactus/ServletTestCase [junit] at java.lang.ClassLoader.defineClass0(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:493) [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader .java:111) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:299) [junit] at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedC lassLoader.java:94) [junit] at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries. java:370) [junit] at org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoa der.java:85) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:255) [junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) [junit] at java.lang.ClassLoader.defineClass0(Native Method) [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:493) [junit] at java.security.SecureClassLoader.defineClass(SecureClassLoader .java:111) [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56) [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) [junit] at java.security.AccessController.doPrivileged(Native Method) [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:299) [junit] at org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedC lassLoader.java:94) [junit] at org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries. java:370) [junit] at org.jboss.system.MBeanClassLoader.loadClass(MBeanClassLoader. java:83) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:292) [junit] at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java: 553) [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:255) [junit] at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:2 10) [junit] at org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:1 94) [junit] at org.apache.cactus.server.AbstractTestCaller.getTestClassClass (AbstractTestCaller.java:168) [junit] at org.apache.cactus.server.AbstractTestCaller.getTestClassInsta nce(AbstractTestCaller.java:143) [junit] at org.apache.cactus.server.AbstractTestCaller.doTest(AbstractTe stCaller.java:38) [junit] at org.apache.cactus.server.AbstractTestController.handleRequest (AbstractTestController.java:122) [junit] at org.apache.cactus.server.ServletTestRedirector.doPost(Servlet TestRedirector.java:134) [junit] at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) [junit] at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [junit] at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder. java:326) [junit] at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandle r.java:570) [junit] at org.mortbay.http.HttpContext.handle(HttpContext.java:1352) [junit] at org.mortbay.http.HttpContext.handle(HttpContext.java:1306) [junit] at
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bridge EntityBridgeInvocationHandler.java
User: dsundstrom
Date: 02/02/26 15:24:53
Modified:src/main/org/jboss/ejb/plugins/cmp/bridge
EntityBridgeInvocationHandler.java
Log:
Cleaned up exception handling.
Revision ChangesPath
1.14 +52 -37
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridgeInvocationHandler.java
Index: EntityBridgeInvocationHandler.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridgeInvocationHandler.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- EntityBridgeInvocationHandler.java12 Feb 2002 22:35:11 - 1.13
+++ EntityBridgeInvocationHandler.java26 Feb 2002 23:24:53 - 1.14
@@ -37,7 +37,7 @@
* One per cmp entity bean instance, including beans in pool.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*/
public class EntityBridgeInvocationHandler implements InvocationHandler {
private final EntityContainer container;
@@ -57,7 +57,7 @@
public EntityBridgeInvocationHandler(
EntityContainer container,
EntityBridge entityBridge,
- Class beanClass) throws Exception {
+ Class beanClass) throws DeploymentException {
this.container = container;
this.entityBridge = entityBridge;
@@ -74,47 +74,62 @@
this.ctx = ctx;
}
- public Object invoke(Object proxy, Method method, Object[] args)
- throws Throwable {
+ public Object invoke(Object proxy, Method method, Object[] args)
+ throws FinderException {
String methodName = method.getName();
-
- SelectorBridge selector = (SelectorBridge) selectorMap.get(method);
- if(selector != null) {
- Transaction tx;
- if(ctx != null) {
-// it is probably safer to get the tx from the context if we have
-// one (ejbHome methods don't have a context)
-tx = ctx.getTransaction();
- } else {
-tx = container.getTransactionManager().getTransaction();
+
+ try {
+ SelectorBridge selector = (SelectorBridge) selectorMap.get(method);
+ if(selector != null) {
+Transaction tx;
+if(ctx != null) {
+ // it is probably safer to get the tx from the context if we have
+ // one (ejbHome methods don't have a context)
+ tx = ctx.getTransaction();
+} else {
+ tx = container.getTransactionManager().getTransaction();
+}
+EntityContainer.synchronizeEntitiesWithinTransaction(tx);
+return selector.execute(args);
}
- EntityContainer.synchronizeEntitiesWithinTransaction(tx);
- return selector.execute(args);
+ } catch(RuntimeException e) {
+ throw e;
+ } catch(FinderException e) {
+ throw e;
+ } catch(Exception e) {
+ throw new EJBException(Internal error, e);
}
-
- // get the field object
- FieldBridge field = (FieldBridge) fieldMap.get(method);
-
- if(field == null) {
- throw new EJBException(Method is not a known CMP field accessor, +
- CMR field accessor, or ejbSelect method: +
- methodName= + methodName);
- }
-
- // In the case of ejbHome methods there is no context, but ejb home
- // methods are only allowed to call selectors.
- if(ctx == null) {
- throw new EJBException(EJB home methods are not allowed to access +
- CMP or CMR fields: methodName= + methodName);
+
+ try {
+ // get the field object
+ FieldBridge field = (FieldBridge) fieldMap.get(method);
+
+ if(field == null) {
+throw new EJBException(Method is not a known CMP field +
+ accessor, CMR field accessor, or ejbSelect method: +
+ methodName= + methodName);
+ }
+
+ // In the case of ejbHome methods there is no context, but ejb home
+ // methods are only allowed to call selectors.
+ if(ctx == null) {
+throw new EJBException(EJB home methods are not allowed to +
+ access CMP or CMR fields: methodName= + methodName);
+ }
+
+ if(methodName.startsWith(get)) {
+return field.getValue(ctx);
+ } else if(methodName.startsWith(set)) {
+field.setValue(ctx, args[0]);
+return null;
+ }
+ } catch(RuntimeException e) {
+ throw e;
+ } catch(Exception e) {
+ throw new
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/bridge CMPFieldBridge.java CMRFieldBridge.java EntityBridge.java
User: dsundstrom
Date: 02/02/26 15:25:47
Modified:src/main/org/jboss/ejb/plugins/cmp/bridge EntityBridge.java
Added: src/main/org/jboss/ejb/plugins/cmp/bridge
CMPFieldBridge.java CMRFieldBridge.java
Log:
Minor changes for generic EJB-QL parsing.
Revision ChangesPath
1.6 +4 -1
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridge.java
Index: EntityBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/EntityBridge.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EntityBridge.java 15 Jan 2002 20:40:15 - 1.5
+++ EntityBridge.java 26 Feb 2002 23:25:47 - 1.6
@@ -24,11 +24,14 @@
* One per cmp entity bean type.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public interface EntityBridge {
public String getEntityName();
+ public String getAbstractSchemaName();
public List getFields();
+ public FieldBridge getFieldByName(String fieldName);
+
public Collection getSelectors();
}
1.8 +1 -94
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMPFieldBridge.java
1.7 +4 -48
jboss/src/main/org/jboss/ejb/plugins/cmp/bridge/CMRFieldBridge.java
___
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/cmp/jdbc/bridge JDBCAbstractCMPFieldBridge.java JDBCCMPFieldBridge.java JDBCCMRFieldBridge.java JDBCEntityBridge.java
User: dsundstrom
Date: 02/02/26 15:28:56
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge
JDBCAbstractCMPFieldBridge.java
JDBCCMPFieldBridge.java JDBCCMRFieldBridge.java
JDBCEntityBridge.java
Log:
Added new methods and interfaces requires by the generic bridge package
for the new EJB-QL parser.
Moved extraneous log messages to trace level.
Wrapped log messages with isEnabled checks.
Revision ChangesPath
1.12 +5 -1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCAbstractCMPFieldBridge.java
Index: JDBCAbstractCMPFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCAbstractCMPFieldBridge.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JDBCAbstractCMPFieldBridge.java 12 Feb 2002 22:35:12 - 1.11
+++ JDBCAbstractCMPFieldBridge.java 26 Feb 2002 23:28:55 - 1.12
@@ -40,7 +40,7 @@
* One for each entity bean cmp field.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*/
public abstract class JDBCAbstractCMPFieldBridge implements JDBCCMPFieldBridge {
protected JDBCStoreManager manager;
@@ -75,6 +75,10 @@
public JDBCCMPFieldMetaData getMetaData() {
return metadata;
+ }
+
+ public JDBCStoreManager getManager() {
+ return manager;
}
public String getFieldName() {
1.10 +10 -5
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMPFieldBridge.java
Index: JDBCCMPFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMPFieldBridge.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCCMPFieldBridge.java 15 Jan 2002 20:50:30 - 1.9
+++ JDBCCMPFieldBridge.java 26 Feb 2002 23:28:55 - 1.10
@@ -12,9 +12,10 @@
import java.sql.ResultSet;
import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCCMPFieldMetaData;
+import org.jboss.ejb.plugins.cmp.bridge.CMPFieldBridge;
+import org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager;
import org.jboss.ejb.plugins.cmp.jdbc.JDBCType;
-
+import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCCMPFieldMetaData;
/**
* JDBCCMPFieldBridge represents one CMP field. This implementations of
@@ -29,10 +30,9 @@
* One for each entity bean cmp field.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
-public interface JDBCCMPFieldBridge
- extends JDBCFieldBridge {
+public interface JDBCCMPFieldBridge extends JDBCFieldBridge, CMPFieldBridge {
/**
* Gets the java class type of the field.
@@ -44,6 +44,11 @@
* Get metadata for the field.
*/
public JDBCCMPFieldMetaData getMetaData();
+
+ /**
+* Gets the JDBCStoreManager for this field
+*/
+ public JDBCStoreManager getManager();
/**
* Gets the value of this field in the specified primaryKey object.
1.25 +16 -7
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMRFieldBridge.java
Index: JDBCCMRFieldBridge.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/bridge/JDBCCMRFieldBridge.java,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- JDBCCMRFieldBridge.java 22 Feb 2002 04:24:55 - 1.24
+++ JDBCCMRFieldBridge.java 26 Feb 2002 23:28:55 - 1.25
@@ -31,6 +31,8 @@
import org.jboss.invocation.Invocation;
import org.jboss.ejb.plugins.CMPPersistenceManager;
import org.jboss.ejb.plugins.EntityInstanceCache;
+import org.jboss.ejb.plugins.cmp.bridge.EntityBridge;
+import org.jboss.ejb.plugins.cmp.bridge.CMRFieldBridge;
import org.jboss.ejb.plugins.cmp.jdbc.JDBCContext;
import org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager;
import org.jboss.ejb.plugins.cmp.jdbc.JDBCType;
@@ -53,9 +55,9 @@
* One for each role that entity has.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.24 $
+ * @version $Revision: 1.25 $
*/
-public class JDBCCMRFieldBridge implements JDBCFieldBridge {
+public class JDBCCMRFieldBridge implements JDBCFieldBridge, CMRFieldBridge {
// -- Invocation messages --
/** tells the related continer to retrieve the id of the related entity */
Re: [JBoss-dev] split Deployer/Auto-Deployer
For 3.0? I sent mail about seperating this functionality into a DeploymentScanner interface, where concreate impls would be created in jboss-service.xml and call the correct MainDeployer ops when something changed. I was still letting the ideas cook some. This is part of the embeded changes too, making MD not't file specific. I would hope that any impl would keep those thoughts into consideration. Here is the email for ref: http://main.jboss.org/thread.jsp?forum=66thread=8288 --jason marc fleury wrote: Ok, It is ripe :) I remember reading some mails talking about Auto-Deployment separated from MainDeployer. I believe it is time to do that :) so if there is a taker... if not I might do it, marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] More Ear crap ..
take it out of webinf marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dave |Smith |Sent: Tuesday, February 26, 2002 3:13 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] More Ear crap .. | | |Ok what is the currennt status of the ear deployment in the latest head? |I am using a hacked version of cactus where I replaced Class.forName() |with Thread.currentThread.getContextClassLoader().loadClass(). My ear |looks like | |0 Tue Feb 26 17:58:22 EST 2002 META-INF/ | 45 Tue Feb 26 17:58:22 EST 2002 META-INF/MANIFEST.MF |228627 Tue Feb 26 17:58:22 EST 2002 cadexTest.war |274 Thu Jan 24 16:22:42 EST 2002 META-INF/application.xml | | |The war looks like | | 0 Tue Feb 26 17:58:22 EST 2002 META-INF/ | 45 Tue Feb 26 17:58:22 EST 2002 META-INF/MANIFEST.MF | 0 Tue Feb 26 17:58:22 EST 2002 WEB-INF/ |164 Fri Jan 25 10:14:28 EST 2002 WEB-INF/jboss-web.xml | 0 Tue Feb 26 17:58:22 EST 2002 WEB-INF/lib/ |117522 Thu Jan 03 16:12:36 EST 2002 WEB-INF/lib/junit.jar | 71832 Tue Feb 26 17:58:12 EST 2002 WEB-INF/lib/cactus.jar | 38464 Tue Feb 26 09:14:02 EST 2002 WEB-INF/lib/cadex-client.jar | 28510 Tue Feb 26 16:42:16 EST 2002 WEB-INF/lib/cadex-test.jar | 1750 Wed Feb 20 13:45:02 EST 2002 WEB-INF/lib/candata_test_util.jar |506 Thu Jan 24 15:21:14 EST 2002 WEB-INF/web.xml | | |Now when I go to run this thing I get |( ServletTestCase is in cactus.jar) | | [junit] org/apache/cactus/ServletTestCase | [junit] java.lang.NoClassDefFoundError: |org/apache/cactus/ServletTestCase | [junit] at java.lang.ClassLoader.defineClass0(Native Method) | [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:493) | [junit] at |java.security.SecureClassLoader.defineClass(SecureClassLoader |.java:111) | [junit] at |java.net.URLClassLoader.defineClass(URLClassLoader.java:248) | [junit] at |java.net.URLClassLoader.access$100(URLClassLoader.java:56) | [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) | [junit] at java.security.AccessController.doPrivileged(Native |Method) | [junit] at |java.net.URLClassLoader.findClass(URLClassLoader.java:188) | [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:299) | [junit] at |org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedC |lassLoader.java:94) | [junit] at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries. |java:370) | [junit] at |org.jboss.system.UnifiedClassLoader.loadClass(UnifiedClassLoa |der.java:85) | [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:255) | [junit] at |java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) | [junit] at java.lang.ClassLoader.defineClass0(Native Method) | [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:493) | [junit] at |java.security.SecureClassLoader.defineClass(SecureClassLoader |.java:111) | [junit] at |java.net.URLClassLoader.defineClass(URLClassLoader.java:248) | [junit] at |java.net.URLClassLoader.access$100(URLClassLoader.java:56) | [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195) | [junit] at java.security.AccessController.doPrivileged(Native |Method) | [junit] at |java.net.URLClassLoader.findClass(URLClassLoader.java:188) | [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:299) | [junit] at |org.jboss.system.UnifiedClassLoader.loadClassLocally(UnifiedC |lassLoader.java:94) | [junit] at |org.jboss.system.ServiceLibraries.loadClass(ServiceLibraries. |java:370) | [junit] at |org.jboss.system.MBeanClassLoader.loadClass(MBeanClassLoader. |java:83) | [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:292) | [junit] at |java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java: |553) | [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:255) | [junit] at |org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:2 |10) | [junit] at |org.mortbay.http.ContextLoader.loadClass(ContextLoader.java:1 |94) | [junit] at |org.apache.cactus.server.AbstractTestCaller.getTestClassClass |(AbstractTestCaller.java:168) | [junit] at |org.apache.cactus.server.AbstractTestCaller.getTestClassInsta |nce(AbstractTestCaller.java:143) | [junit] at |org.apache.cactus.server.AbstractTestCaller.doTest(AbstractTe |stCaller.java:38) | [junit] at |org.apache.cactus.server.AbstractTestController.handleRequest |(AbstractTestController.java:122) | [junit] at |org.apache.cactus.server.ServletTestRedirector.doPost(Servlet |TestRedirector.java:134) | [junit] at |javax.servlet.http.HttpServlet.service(HttpServlet.java:760) | [junit] at |javax.servlet.http.HttpServlet.service(HttpServlet.java:853) | [junit] at |org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.
Re: [JBoss-dev] Shutdown needs some cleanup
Oops, shutdown should also turn off the scan thread. Actually MainDeployer, being the first service registered with ServiceController, is the last stopped. I'll fix this. david jencks On 2002.02.26 18:05:54 -0500 Scott M Stark wrote: I'm seeing the MainDeployer still trying to to deploys during the shutdown sequence. Isn't this one of the first services stopped? 15:00:22,734 INFO [Server] Shutdown complete 15:00:22,734 INFO [STDOUT] Shutdown complete 15:00:22,734 ERROR [SARDeployer] operation failed javax.management.InstanceNotFoundException: jboss.system:service=MainDeployer at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1678) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1522) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy1.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:489) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:176) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:545) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:514) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:496) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:317) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:304) at java.lang.Thread.run(Thread.java:484) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Boot time , FAST
Any thoughts to creating new UCL objects inside ServiceLibraries instead of having the UCL constructor add itself to the SL when created? This will make it more explicit for what is going on here as well as allow the parent cl to be passed in from the SL instead of using UnifiedClassLoader.class.getClassLoader(). It seems like a minor change that would improve the quality of this system... --jason marc fleury wrote: with a simple fix I added yesterday (making sure we don't cycle through the UCL iterator if we have the class) the boot time on my machine goes back down to 4 seconds which is on par (even a bit faster) than 2.4 I will commit my stuff as soon as I can resolve a few sillyness things on the JNP implementation (who said refactoring is needed?) marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCCommandFactory.java
User: dsundstrom
Date: 02/02/26 15:31:43
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCCommandFactory.java
Log:
Added new JBossQL and DynamicQL command factory methods.
Revision ChangesPath
1.15 +11 -1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCommandFactory.java
Index: JDBCCommandFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCCommandFactory.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JDBCCommandFactory.java 15 Jan 2002 21:48:45 - 1.14
+++ JDBCCommandFactory.java 26 Feb 2002 23:31:43 - 1.15
@@ -17,7 +17,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=[EMAIL PROTECTED]danch (Dan Christopherson/a
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class JDBCCommandFactory {
private JDBCStoreManager manager;
@@ -42,6 +42,16 @@
public JDBCQueryCommand createEJBQLQuery(JDBCQueryMetaData q)
throws DeploymentException {
return new JDBCEJBQLQuery(manager, q);
+ }
+
+ public JDBCQueryCommand createDynamicQLQuery(JDBCQueryMetaData q)
+ throws DeploymentException {
+ return new JDBCDynamicQLQuery(manager, q);
+ }
+
+ public JDBCQueryCommand createJBossQLQuery(JDBCQueryMetaData q)
+ throws DeploymentException {
+ return new JDBCJBossQLQuery(manager, q);
}
public JDBCQueryCommand createFindByQuery(JDBCQueryMetaData q)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shutdown needs some cleanup
Quick question... is there order to shutdown? If MBean A depends on B, then do we shutdown A first then B? --jason Scott M Stark wrote: I'm seeing the MainDeployer still trying to to deploys during the shutdown sequence. Isn't this one of the first services stopped? 15:00:22,734 INFO [Server] Shutdown complete 15:00:22,734 INFO [STDOUT] Shutdown complete 15:00:22,734 ERROR [SARDeployer] operation failed javax.management.InstanceNotFoundException: jboss.system:service=MainDeployer at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1678) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1522) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy1.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:489) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:176) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:545) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:514) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:496) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:317) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:304) at java.lang.Thread.run(Thread.java:484) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
Again, why not use a notification here? If an attrib is exposed, then we have to poll. If the service sends a note, then we just sit until we get one... Or am I missing the point? --jason marc fleury wrote: |If we used ModelMBeans, the Attribute's desriptor |could include a field runtimeConfigurable. |The service deployer can then determine if a redeploy |is required. ohhh so pretty we will use modelMBeans very soon, if we could get you get to put something out marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-system/src/main/org/jboss/deployment MainDeployer.java
User: d_jencks
Date: 02/02/26 15:45:04
Modified:src/main/org/jboss/deployment MainDeployer.java
Log:
made MainDeployer stop scanning before it undeploys everything on shutdown.
Revision ChangesPath
1.10 +4 -1 jboss-system/src/main/org/jboss/deployment/MainDeployer.java
Index: MainDeployer.java
===
RCS file:
/cvsroot/jboss/jboss-system/src/main/org/jboss/deployment/MainDeployer.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- MainDeployer.java 26 Feb 2002 05:15:02 - 1.9
+++ MainDeployer.java 26 Feb 2002 23:45:04 - 1.10
@@ -48,7 +48,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class MainDeployer
extends ServiceMBeanSupport
@@ -266,6 +266,9 @@
*/
public void shutdown()
{
+ running = false;
+ //if we shutdown in the middle of a scan, it still might be possible that we
try to redeploy
+ //things we are busy killing...
int deployCounter = 0;
//undeploy everything in sight
List copyDeployments = new ArrayList(deploymentsList);
___
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/cmp/jdbc JDBCDynamicQLQuery.java
User: dsundstrom
Date: 02/02/26 15:45:32
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCDynamicQLQuery.java
Log:
Initial revision of DynamicQl command which compiles and executes JBossQL
at runtime.
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDynamicQLQuery.java
Index: JDBCDynamicQLQuery.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.cmp.jdbc;
import java.lang.reflect.Method;
import java.util.Collection;
import javax.ejb.FinderException;
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.EntityEnterpriseContext;
import org.jboss.ejb.plugins.cmp.ejbql.Catalog;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCDynamicQLQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCReadAheadMetaData;
/**
* This class generates a query from JBoss-QL.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @version $Revision: 1.1 $
*/
public class JDBCDynamicQLQuery extends JDBCAbstractQueryCommand {
private final Catalog catalog;
private JDBCDynamicQLQueryMetaData metadata;
public JDBCDynamicQLQuery(
JDBCStoreManager manager,
JDBCQueryMetaData q) throws DeploymentException {
super(manager, q);
catalog = (Catalog)manager.getApplicationData(CATALOG);
metadata = (JDBCDynamicQLQueryMetaData)q;
}
public Collection execute(
Method finderMethod,
Object[] args,
EntityEnterpriseContext ctx) throws FinderException {
String dynamicQL = (String)args[0];
if(getLog().isDebugEnabled()) {
getLog().debug(DYNAMIC-QL: + dynamicQL);
}
JDBCEJBQLCompiler compiler = new JDBCEJBQLCompiler(catalog);
// get the parameters
Object[] parameters = (Object[])args[1];
if(parameters == null) {
throw new FinderException(Parameters is null);
}
// get the parameter types
Class[] parameterTypes = new Class[parameters.length];
for(int i=0; iparameters.length; i++) {
if(parameters[i] == null) {
throw new FinderException(Parameter[+i+] is null);
}
parameterTypes[i] = parameters[i].getClass();
}
// compile the dynamic-ql
try {
compiler.compileJBossQL(
dynamicQL,
finderMethod.getReturnType(),
parameterTypes,
metadata.getReadAhead());
} catch(Throwable t) {
throw new FinderException(Error compiling ejbql: + t);
}
// set the sql
if(getLog().isDebugEnabled()) {
getLog().debug(SQL:\r\n + compiler.getSQL());
}
setSQL(compiler.getSQL());
// set select object
if(compiler.isSelectEntity()) {
setSelectEntity(compiler.getSelectEntity());
} else {
setSelectField(compiler.getSelectField());
}
// get the parameter order
setParameterList(compiler.getInputParameters());
return super.execute(finderMethod, parameters, ctx);
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss-system/src/main/org/jboss/system/server ServerImpl.java ServerInfo.java ServerInfoMBean.java
Source for Class.forName() shows that it calls getCallerClassLoader() which is a package private native method and does... well I haven't a clue. --jason Hiram Chirino wrote: StreamHandlerFactory registered (but the URL class only tries to load resource handlers using Class.forName() and the system-classloader so that might not work with custom classloaders). We need to figure out why Class.forName() called from inside URL did not find the class then. --jason I'm not sure, but I think Class.forName will only load classes that are in the same classloader that current class was loaded from. In your case (the system classloader since Class.forName() is called from URL). So you have to ask yourself, is my protocol class in the system classloader? So I think that is the problem. The URL class should have used the ContextClassLoader to load the class. Regards, Hiram _ Chat with friends online, try MSN Messenger: http://messenger.msn.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: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCJBossQLQuery.java
User: dsundstrom
Date: 02/02/26 15:48:58
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCJBossQLQuery.java
Log:
Initial revision of JBossQL query command. JBossQL is a superset of EJB-QL
that in this intial revison adds support for ORDER BY.
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCJBossQLQuery.java
Index: JDBCJBossQLQuery.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.cmp.jdbc;
import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.plugins.cmp.ejbql.Catalog;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCJBossQLQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaData;
/**
* This class generates a query from JBoss-QL.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @version $Revision: 1.1 $
*/
public class JDBCJBossQLQuery extends JDBCAbstractQueryCommand {
public JDBCJBossQLQuery(
JDBCStoreManager manager,
JDBCQueryMetaData q) throws DeploymentException {
super(manager, q);
JDBCJBossQLQueryMetaData metadata = (JDBCJBossQLQueryMetaData)q;
if(getLog().isDebugEnabled()) {
getLog().debug(EJB-QL: + metadata.getJBossQL());
}
JDBCEJBQLCompiler compiler = new JDBCEJBQLCompiler(
(Catalog)manager.getApplicationData(CATALOG));
try {
compiler.compileJBossQL(
metadata.getJBossQL(),
metadata.getMethod().getReturnType(),
metadata.getMethod().getParameterTypes(),
metadata.getReadAhead());
} catch(Throwable t) {
throw new DeploymentException(Error compiling ejbql, t);
}
// set the sql
if(getLog().isDebugEnabled()) {
getLog().debug(SQL:\r\n + compiler.getSQL());
}
setSQL(compiler.getSQL());
// set select object
if(compiler.isSelectEntity()) {
setSelectEntity(compiler.getSelectEntity());
} else {
setSelectField(compiler.getSelectField());
}
// get the parameter order
setParameterList(compiler.getInputParameters());
}
}
___
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/cmp/jdbc JDBCEJBQLQuery.java
User: dsundstrom
Date: 02/02/26 15:47:10
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCEJBQLQuery.java
Log:
Changed to use new JDBCEJBQLCompiler based on JavaCC.
Revision ChangesPath
1.6 +25 -37
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCEJBQLQuery.java
Index: JDBCEJBQLQuery.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCEJBQLQuery.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JDBCEJBQLQuery.java 22 Feb 2002 04:24:55 - 1.5
+++ JDBCEJBQLQuery.java 26 Feb 2002 23:47:10 - 1.6
@@ -8,12 +8,7 @@
package org.jboss.ejb.plugins.cmp.jdbc;
import org.jboss.deployment.DeploymentException;
-import org.jboss.ejb.plugins.cmp.ejbql.Assembly;
-import org.jboss.ejb.plugins.cmp.ejbql.Parser;
-import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge;
-import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;
-import org.jboss.ejb.plugins.cmp.jdbc.ejbql.EJBQLParser;
-import org.jboss.ejb.plugins.cmp.jdbc.ejbql.SQLTarget;
+import org.jboss.ejb.plugins.cmp.ejbql.Catalog;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQlQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaData;
@@ -21,7 +16,7 @@
* This class generates a query from EJB-QL.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public class JDBCEJBQLQuery extends JDBCAbstractQueryCommand {
@@ -32,44 +27,37 @@
super(manager, q);
JDBCQlQueryMetaData metadata = (JDBCQlQueryMetaData)q;
- getLog().debug(EQL-QL: +metadata.getEjbQl());
-
- // get a parser
- Parser ejbql = new EJBQLParser().ejbqlQuery();
-
- // initialize the assembly
- Assembly a = new Assembly(metadata.getEjbQl());
- a.setTarget(new SQLTarget(
-q.getMethod(),
-manager.getJDBCTypeFactory(),
-manager.getContainer().getEjbModule(),
-q.getReadAhead()));
-
- // match the query
- a = ejbql.soleMatch(a);
- if(a == null) {
- throw new DeploymentException(Unable to parse EJB-QL: +
- metadata.getEjbQl());
+ if(getLog().isDebugEnabled()) {
+ getLog().debug(EJB-QL: + metadata.getEjbQl());
}
- // get the final target
- SQLTarget target = (SQLTarget)a.getTarget();
+ JDBCEJBQLCompiler compiler = new JDBCEJBQLCompiler(
+(Catalog)manager.getApplicationData(CATALOG));
+
+ try {
+ compiler.compileEJBQL(
+ metadata.getEjbQl(),
+ metadata.getMethod().getReturnType(),
+ metadata.getMethod().getParameterTypes(),
+ metadata.getReadAhead());
+ } catch(Throwable t) {
+ throw new DeploymentException(Error compiling ejbql, t);
+ }
// set the sql
- setSQL(target.toSQL());
+ if(getLog().isDebugEnabled()) {
+ getLog().debug(SQL:\r\n + compiler.getSQL());
+ }
+ setSQL(compiler.getSQL());
- // select bridge object
- Object selectBridgeObject = target.getSelectObject();
- if(selectBridgeObject instanceof JDBCEntityBridge) {
- setSelectEntity((JDBCEntityBridge)selectBridgeObject);
- } else if(selectBridgeObject instanceof JDBCCMPFieldBridge) {
- setSelectField((JDBCCMPFieldBridge)selectBridgeObject);
+ // set select object
+ if(compiler.isSelectEntity()) {
+ setSelectEntity(compiler.getSelectEntity());
} else {
- throw new IllegalStateException(Select bridge object is instance +
- of unknown type: selectBridgeObject= + selectBridgeObject);
+ setSelectField(compiler.getSelectField());
}
-
+
// get the parameter order
- setParameterList(target.getInputParameters());
+ setParameterList(compiler.getInputParameters());
}
}
___
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/cmp/jdbc JDBCEJBQLCompiler.java
User: dsundstrom
Date: 02/02/26 15:46:27
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCEJBQLCompiler.java
Log:
Compiles EJB-QL and JBossQl, which is a superset of EJB-QL, to SQL.
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCEJBQLCompiler.java
Index: JDBCEJBQLCompiler.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.cmp.jdbc;
import java.io.StringReader;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Set;
import org.jboss.ejb.plugins.cmp.bridge.CMPFieldBridge;
import org.jboss.ejb.plugins.cmp.ejbql.ASTAbs;
import org.jboss.ejb.plugins.cmp.ejbql.ASTAbstractSchema;
import org.jboss.ejb.plugins.cmp.ejbql.ASTAnd;
import org.jboss.ejb.plugins.cmp.ejbql.ASTApproximateNumericLiteral;
import org.jboss.ejb.plugins.cmp.ejbql.ASTArithmeticComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTArithmeticParenthetical;
import org.jboss.ejb.plugins.cmp.ejbql.ASTBetween;
import org.jboss.ejb.plugins.cmp.ejbql.ASTBooleanComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTBooleanLiteral;
import org.jboss.ejb.plugins.cmp.ejbql.ASTCollectionMemberDeclaration;
import org.jboss.ejb.plugins.cmp.ejbql.ASTComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTConcat;
import org.jboss.ejb.plugins.cmp.ejbql.ASTConditionalParenthetical;
import org.jboss.ejb.plugins.cmp.ejbql.ASTDatetimeComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTEJBQL;
import org.jboss.ejb.plugins.cmp.ejbql.ASTEntityComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTExactNumericLiteral;
import org.jboss.ejb.plugins.cmp.ejbql.ASTFrom;
import org.jboss.ejb.plugins.cmp.ejbql.ASTIdentifier;
import org.jboss.ejb.plugins.cmp.ejbql.ASTIn;
import org.jboss.ejb.plugins.cmp.ejbql.ASTIsEmpty;
import org.jboss.ejb.plugins.cmp.ejbql.ASTLength;
import org.jboss.ejb.plugins.cmp.ejbql.ASTLike;
import org.jboss.ejb.plugins.cmp.ejbql.ASTLocate;
import org.jboss.ejb.plugins.cmp.ejbql.ASTMemberOf;
import org.jboss.ejb.plugins.cmp.ejbql.ASTMultDiv;
import org.jboss.ejb.plugins.cmp.ejbql.ASTNegation;
import org.jboss.ejb.plugins.cmp.ejbql.ASTNot;
import org.jboss.ejb.plugins.cmp.ejbql.ASTNullComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTOr;
import org.jboss.ejb.plugins.cmp.ejbql.ASTOrderBy;
import org.jboss.ejb.plugins.cmp.ejbql.ASTOrderByPath;
import org.jboss.ejb.plugins.cmp.ejbql.ASTParameter;
import org.jboss.ejb.plugins.cmp.ejbql.ASTPath;
import org.jboss.ejb.plugins.cmp.ejbql.ASTPlusMinus;
import org.jboss.ejb.plugins.cmp.ejbql.ASTRangeVariableDeclaration;
import org.jboss.ejb.plugins.cmp.ejbql.ASTSelect;
import org.jboss.ejb.plugins.cmp.ejbql.ASTSqrt;
import org.jboss.ejb.plugins.cmp.ejbql.ASTStringComparison;
import org.jboss.ejb.plugins.cmp.ejbql.ASTStringLiteral;
import org.jboss.ejb.plugins.cmp.ejbql.ASTStringParenthetical;
import org.jboss.ejb.plugins.cmp.ejbql.ASTSubstring;
import org.jboss.ejb.plugins.cmp.ejbql.ASTWhere;
import org.jboss.ejb.plugins.cmp.ejbql.SimpleNode;
import org.jboss.ejb.plugins.cmp.ejbql.BasicVisitor;
import org.jboss.ejb.plugins.cmp.ejbql.BlockStringBuffer;
import org.jboss.ejb.plugins.cmp.ejbql.Catalog;
import org.jboss.ejb.plugins.cmp.ejbql.EJBQLParser;
import org.jboss.ejb.plugins.cmp.ejbql.JBossQLParser;
import org.jboss.ejb.plugins.cmp.ejbql.JBossQLParserVisitor;
import org.jboss.ejb.plugins.cmp.ejbql.EJBQLTypes;
import org.jboss.ejb.plugins.cmp.ejbql.Node;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCFieldBridge;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge;
import org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCFunctionMappingMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCReadAheadMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCTypeMappingMetaData;
/**
* Compiles EJB-QL and JBossQL into SQL.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @version $Revision: 1.1 $
*/
public class JDBCEJBQLCompiler extends BasicVisitor {
// input objects
private final Catalog catalog;
private Class returnType;
private Class[] parameterTypes;
private JDBCReadAheadMetaData readAhead;
// alias info
private String aliasHeaderPrefix;
private String aliasHeaderSuffix;
private int aliasMaxLength;
private int aliasCount;
private Map aliases = new HashMap();
private Map relationTableAliases = new HashMap();
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCLoadRelationCommand.java
User: dsundstrom
Date: 02/02/26 15:51:03
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCLoadRelationCommand.java
Log:
Minor changes due to changes in CMRFieldBridge interface.
Revision ChangesPath
1.15 +7 -7
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java
Index: JDBCLoadRelationCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JDBCLoadRelationCommand.java 16 Feb 2002 10:37:54 - 1.14
+++ JDBCLoadRelationCommand.java 26 Feb 2002 23:51:03 - 1.15
@@ -33,7 +33,7 @@
* Loads relations for a particular entity from a relation table.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.14 $
+ * @version $Revision: 1.15 $
*/
public class JDBCLoadRelationCommand {
private final JDBCStoreManager manager;
@@ -195,7 +195,7 @@
List relatedKeyFields = getRelatedKeyFields(cmrField);
List preloadFields = getPreloadFields(cmrField);
String relationTable = getRelationTable(cmrField);
- String relatedTable = cmrField.getRelatedEntity().getTableName();
+ String relatedTable = cmrField.getRelatedJDBCEntity().getTableName();
// do we need to join the relation table and the related table
boolean join = (preloadFields.size() 0
@@ -246,7 +246,7 @@
whereClause.append(SQLUtil.getJoinClause(
relatedKeyFields,
relationTable,
- cmrField.getRelatedEntity().getPrimaryKeyFields(),
+ cmrField.getRelatedJDBCEntity().getPrimaryKeyFields(),
relatedTable));
whereClause.append() AND ();
}
@@ -304,7 +304,7 @@
return cmrField.getRelatedCMRField().getTableKeyFields();
} else if(cmrField.getRelatedCMRField().hasForeignKey()) {
// related has foreign key
- return cmrField.getRelatedEntity().getPrimaryKeyFields();
+ return cmrField.getRelatedJDBCEntity().getPrimaryKeyFields();
} else {
// i have foreign key
return cmrField.getForeignKeyFields();
@@ -337,7 +337,7 @@
return cmrField.getRelationMetaData().getTableName();
} else if(cmrField.getRelatedCMRField().hasForeignKey()) {
// related has foreign key
- return cmrField.getRelatedEntity().getTableName();
+ return cmrField.getRelatedJDBCEntity().getTableName();
} else {
// i have foreign key
return entity.getTableName();
@@ -360,9 +360,9 @@
}
} else if(cmrField.getRelatedCMRField().hasForeignKey()) {
// related has foreign key
- if(cmrField.getRelatedEntity().getMetaData().hasRowLocking()) {
+ if(cmrField.getRelatedJDBCEntity().getMetaData().hasRowLocking()) {
selectTemplate =
-
cmrField.getRelatedEntity().getMetaData().getTypeMapping().getRowLockingTemplate();
+
cmrField.getRelatedJDBCEntity().getMetaData().getTypeMapping().getRowLockingTemplate();
if(selectTemplate == null) {
throw new IllegalStateException(row-locking is not allowed +
for this type of datastore);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Long tmp deploy urls
Well, it would be nice to not need them... seems like there has to be a better way to do this... what I don't know. Any way to trick java into thinking that the codebase is where the jar orginated from? --jason David Jencks wrote: On 2002.02.26 04:31:22 -0500 Jason Dillon wrote: These are murder when trying to debug something with deployment... do we really need this? --jason I think so. They got longer so security permissions were determinable. They also let you predict where your deployment package will end up. Try putting jboss near the root of your filesystem;-) david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ 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/cmp/jdbc JDBCQueryManager.java
User: dsundstrom
Date: 02/02/26 15:52:01
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCQueryManager.java
Log:
Added support for new DynamicQL and JBossQL queries.
Revision ChangesPath
1.4 +12 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCQueryManager.java
Index: JDBCQueryManager.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCQueryManager.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JDBCQueryManager.java 15 Jan 2002 22:23:17 - 1.3
+++ JDBCQueryManager.java 26 Feb 2002 23:52:01 - 1.4
@@ -19,6 +19,8 @@
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCAutomaticQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCDeclaredQueryMetaData;
+import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCDynamicQLQueryMetaData;
+import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCJBossQLQueryMetaData;
import org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQlQueryMetaData;
import org.jboss.logging.Logger;
@@ -30,7 +32,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class JDBCQueryManager {
private final Map knownQueries = new HashMap();
@@ -169,7 +171,15 @@
JDBCQueryMetaData q = (JDBCQueryMetaData)definedFinders.next();
if(!knownQueries.containsKey(q.getMethod()) ) {
-if(q instanceof JDBCDeclaredQueryMetaData) {
+if(q instanceof JDBCJBossQLQueryMetaData) {
+ knownQueries.put(
+ q.getMethod(), factory.createJBossQLQuery(q));
+
+} else if(q instanceof JDBCDynamicQLQueryMetaData) {
+ knownQueries.put(
+ q.getMethod(), factory.createDynamicQLQuery(q));
+
+} else if(q instanceof JDBCDeclaredQueryMetaData) {
knownQueries.put(
q.getMethod(), factory.createDeclaredSQLQuery(q));
___
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/cmp/jdbc JDBCStartCommand.java
User: dsundstrom
Date: 02/02/26 15:53:07
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStartCommand.java
Log:
Minor changes due to changes in CMRFieldBridge interface.
Revision ChangesPath
1.22 +4 -4
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java
Index: JDBCStartCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- JDBCStartCommand.java 12 Feb 2002 06:15:17 - 1.21
+++ JDBCStartCommand.java 26 Feb 2002 23:53:06 - 1.22
@@ -40,7 +40,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
* @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
* @author a href=mailto:[EMAIL PROTECTED];Michel de Groot/a
- * @version $Revision: 1.21 $
+ * @version $Revision: 1.22 $
*/
public class JDBCStartCommand {
@@ -96,7 +96,7 @@
JDBCRelationMetaData relationMetaData = cmrField.getRelationMetaData();
// if the table for the related entity has been created
- if(cmrField.getRelatedEntity().getTableExists()) {
+ if(cmrField.getRelatedJDBCEntity().getTableExists()) {
// create the relation table
if(relationMetaData.isTableMappingStyle()
@@ -281,8 +281,8 @@
cmrField.getEntity().getTableName(),
cmrField.getFieldName(),
cmrField.getForeignKeyFields(),
- cmrField.getRelatedEntity().getTableName(),
- cmrField.getRelatedEntity().getPrimaryKeyFields());
+ cmrField.getRelatedJDBCEntity().getTableName(),
+ cmrField.getRelatedJDBCEntity().getPrimaryKeyFields());
}
} else {
log.debug(Foreign key constraint not added as requested: +
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss compilation failed
=
==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS=
=
HERE ARE THE LAST 50 LINES OF THE LOG FILE
symbol : class EJBQLParser
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTArithmeticParenthetical
public ASTArithmeticParenthetical(EJBQLParser p, int id) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTArithmeticParenthetical.java:27:
cannot resolve symbol
symbol : class JBossQLParserVisitor
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTArithmeticParenthetical
public Object jjtAccept(JBossQLParserVisitor visitor, Object data) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTStringParenthetical.java:21:
cannot resolve symbol
symbol : class EJBQLParser
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTStringParenthetical
public ASTStringParenthetical(EJBQLParser p, int id) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTStringParenthetical.java:27:
cannot resolve symbol
symbol : class JBossQLParserVisitor
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTStringParenthetical
public Object jjtAccept(JBossQLParserVisitor visitor, Object data) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTOrderBy.java:21:
cannot resolve symbol
symbol : class EJBQLParser
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTOrderBy
public ASTOrderBy(EJBQLParser p, int id) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTOrderBy.java:27:
cannot resolve symbol
symbol : class JBossQLParserVisitor
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTOrderBy
public Object jjtAccept(JBossQLParserVisitor visitor, Object data) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTOrderByPath.java:23:
cannot resolve symbol
symbol : class EJBQLParser
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTOrderByPath
public ASTOrderByPath(EJBQLParser p, int id) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/plugins/cmp/ejbql/ASTOrderByPath.java:29:
cannot resolve symbol
symbol : class JBossQLParserVisitor
location: class org.jboss.ejb.plugins.cmp.ejbql.ASTOrderByPath
public Object jjtAccept(JBossQLParserVisitor visitor, Object data) {
^
/disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340:
warning: java.security.Identity in java.security has been deprecated
public boolean isCallerInRole(Identity id)
^
100 errors
4 warnings
BUILD FAILED
/disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:393: Compile failed,
messages should have been provided.
Total time: 1 minute 30 seconds
___
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/cmp/jdbc/metadata JDBCDynamicQLQueryMetaData.java
User: dsundstrom
Date: 02/02/26 15:57:40
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCDynamicQLQueryMetaData.java
Log:
Initial revision of metadat for new DynamicQL syle queries.
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCDynamicQLQueryMetaData.java
Index: JDBCDynamicQLQueryMetaData.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.cmp.jdbc.metadata;
import java.lang.reflect.Method;
import org.w3c.dom.Element;
import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.QueryMetaData;
/**
* Immutable class which contains information about an DynamicQL query.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @version $Revision: 1.1 $
*/
public final class JDBCDynamicQLQueryMetaData implements JDBCQueryMetaData {
/**
* The method to which this query is bound.
*/
private final Method method;
/**
* Should the query return Local or Remote beans.
*/
private final boolean resultTypeMappingLocal;
private final JDBCReadAheadMetaData readAhead;
/**
* Constructs a JDBCDynamicQLQueryMetaData with DynamicQL declared in the
* jboss-ql elemnt and is invoked by the specified method.
* @param queryMetaData the metadata about this query
*/
public JDBCDynamicQLQueryMetaData(
JDBCQueryMetaData jdbcQueryMetaData,
Element element,
Method method) throws DeploymentException {
this.method = method;
resultTypeMappingLocal = jdbcQueryMetaData.isResultTypeMappingLocal();
Class[] parameterTypes = method.getParameterTypes();
if(parameterTypes.length != 2 ||
!parameterTypes[0].equals(String.class) ||
!parameterTypes[1].equals(Object[].class)) {
throw new DeploymentException(Dynamic-ql method must have two +
parameters of type String and Object[].);
}
readAhead = new JDBCReadAheadMetaData(
on-find,
255,
*);
}
// javadoc in parent class
public Method getMethod() {
return method;
}
// javadoc in parent class
public boolean isResultTypeMappingLocal() {
return resultTypeMappingLocal;
}
/**
* Gets the read ahead metadata for the query.
* @return the read ahead metadata for the query.
*/
public JDBCReadAheadMetaData getReadAhead() {
return readAhead;
}
/**
* Compares this JDBCDynamicQLQueryMetaData against the specified object.
* Returns true if the objects are the same. Two JDBCDynamicQLQueryMetaData
* are the same if they are both invoked by the same method.
* @param o the reference object with which to compare
* @return true if this object is the same as the object argument;
*false otherwise
*/
public boolean equals(Object o) {
if(o instanceof JDBCDynamicQLQueryMetaData) {
return ((JDBCDynamicQLQueryMetaData)o).method.equals(method);
}
return false;
}
/**
* Returns a hashcode for this JDBCDynamicQLQueryMetaData. The hashcode is
* computed by the method which invokes this query.
* @return a hash code value for this object
*/
public int hashCode() {
return method.hashCode();
}
/**
* Returns a string describing this JDBCDynamicQLQueryMetaData. The exact
* details of the representation are unspecified and subject to change, but
* the following may be regarded as typical:
*
* [JDBCDynamicQLQueryMetaData: method=public org.foo.User
* findByName(java.lang.String)]
*
* @return a string representation of the object
*/
public String toString() {
return [JDBCDynamicQLQueryMetaData : method= + method + ];
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [Fwd: Embedable, ServerLoader, jboss-boot.jar, logging and more...]
In ServerLoader.load(ClassLoader) you construct a URLClassLoader and set it as the TCL (Thread class loader). This is for dynamically loading classes from configuration options. Actually this is Marc here... I can't take any credit for any CL stuff really. But Server.start() does not have this TCL. We do the same config processing in JBossMX, we can't find the classes during MBeanServerFactory.createMBeanServer(jboss) :-( Any sugestions on how to fix? Looks pretty good besides. P.S. You misspelt DEFUALT_BOOT_LIBRARY_LIST :-) Opps... --jason ___ 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/cmp/jdbc JDBCTypeFactory.java
User: dsundstrom
Date: 02/02/26 15:55:46
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCTypeFactory.java
Log:
Added method to get type metadata. This is used by the EJB-QL compiler.
Revision ChangesPath
1.10 +5 -1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCTypeFactory.java
Index: JDBCTypeFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCTypeFactory.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JDBCTypeFactory.java 12 Feb 2002 06:17:15 - 1.9
+++ JDBCTypeFactory.java 26 Feb 2002 23:55:46 - 1.10
@@ -27,7 +27,7 @@
* this class is to flatten the JDBCValueClassMetaData into columns.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class JDBCTypeFactory {
// the type mapping to use with the specified database
@@ -78,6 +78,10 @@
public int getJDBCTypeForJavaType(Class clazz) {
return typeMapping.getJdbcTypeForJavaType(clazz);
+ }
+
+ public JDBCTypeMappingMetaData getTypeMapping() {
+ return typeMapping;
}
private JDBCTypeComplex createTypeComplex(
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] notes on configuration
Hi I didn't follow the discussion but when you want to wait for an attribute to be changed you can use the Monitoring Service which sends you also a Notification but you can add this outside the MBean. Andy - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: marc fleury [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 3:40 PM Subject: Re: [JBoss-dev] notes on configuration Again, why not use a notification here? If an attrib is exposed, then we have to poll. If the service sends a note, then we just sit until we get one... Or am I missing the point? --jason ___ 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/cmp/jdbc/metadata JDBCReadAheadMetaData.java
User: dsundstrom
Date: 02/02/26 16:03:25
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCReadAheadMetaData.java
Log:
Added new constructor that takes all state info as parameters.
Revision ChangesPath
1.6 +19 -1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCReadAheadMetaData.java
Index: JDBCReadAheadMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCReadAheadMetaData.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- JDBCReadAheadMetaData.java15 Jan 2002 21:19:43 - 1.5
+++ JDBCReadAheadMetaData.java27 Feb 2002 00:03:25 - 1.6
@@ -19,7 +19,7 @@
* It loads its data from standardjbosscmp-jdbc.xml and jbosscmp-jdbc.xml
*
* @author a href=mailto:[EMAIL PROTECTED];Oleg Nitz/a
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*/
public final class JDBCReadAheadMetaData {
@@ -72,6 +72,24 @@
strategy = ON_LOAD;
pageSize = 255;
eagerLoadGroup = *;
+ }
+
+ /**
+* Constructs read ahead meta data with specified strategy, pageSize and
+* eagerLoadGroup.
+*/
+ public JDBCReadAheadMetaData(
+ String strategy,
+ int pageSize,
+ String eagerLoadGroup) {
+
+ this.strategy = (byte) STRATEGIES.indexOf(strategy);
+ if(this.strategy 0) {
+ throw new IllegalArgumentException(Unknown read ahead strategy ' +
+ strategy + '.);
+ }
+ this.pageSize = pageSize;
+ this.eagerLoadGroup = eagerLoadGroup;
}
/**
___
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/cmp/jdbc/metadata JDBCJBossQLQueryMetaData.java
User: dsundstrom
Date: 02/02/26 15:58:17
Added: src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCJBossQLQueryMetaData.java
Log:
Initial revison of metadata for new JBossQL queries.
Revision ChangesPath
1.1
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCJBossQLQueryMetaData.java
Index: JDBCJBossQLQueryMetaData.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.ejb.plugins.cmp.jdbc.metadata;
import java.lang.reflect.Method;
import org.w3c.dom.Element;
import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.QueryMetaData;
/**
* Immutable class which contains information about an JBossQL query.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @version $Revision: 1.1 $
*/
public final class JDBCJBossQLQueryMetaData implements JDBCQueryMetaData {
/**
* The method to which this query is bound.
*/
private final Method method;
/**
* The ejb-ql fro the query.
*/
private final String jbossQL;
/**
* Should the query return Local or Remote beans.
*/
private final boolean resultTypeMappingLocal;
/**
* Read ahead meta data.
*/
private final JDBCReadAheadMetaData readAhead;
/**
* Constructs a JDBCJBossQLQueryMetaData with JBossQL declared in the
* jboss-ql elemnt and is invoked by the specified method.
* @param queryMetaData the metadata about this query
*/
public JDBCJBossQLQueryMetaData(
JDBCQueryMetaData jdbcQueryMetaData,
Element element,
Method method,
JDBCReadAheadMetaData readAhead) throws DeploymentException {
this.method = method;
this.readAhead = readAhead;
jbossQL = MetaData.getElementContent(element);
if(jbossQL==null || jbossQL.trim().length()==0) {
throw new DeploymentException(jboss-ql element is empty);
}
resultTypeMappingLocal = jdbcQueryMetaData.isResultTypeMappingLocal();
}
// javadoc in parent class
public Method getMethod() {
return method;
}
/**
* Gets the JBossQL query which will be invoked.
* @return the ejb ql String for this query
*/
public String getJBossQL() {
return jbossQL;
}
// javadoc in parent class
public boolean isResultTypeMappingLocal() {
return resultTypeMappingLocal;
}
/**
* Gets the read ahead metadata for the query.
* @return the read ahead metadata for the query.
*/
public JDBCReadAheadMetaData getReadAhead() {
return readAhead;
}
/**
* Compares this JDBCJBossQLQueryMetaData against the specified object.
* Returns true if the objects are the same. Two JDBCJBossQLQueryMetaData
* are the same if they are both invoked by the same method.
* @param o the reference object with which to compare
* @return true if this object is the same as the object argument;
*false otherwise
*/
public boolean equals(Object o) {
if(o instanceof JDBCJBossQLQueryMetaData) {
return ((JDBCJBossQLQueryMetaData)o).method.equals(method);
}
return false;
}
/**
* Returns a hashcode for this JDBCJBossQLQueryMetaData. The hashcode is
* computed by the method which invokes this query.
* @return a hash code value for this object
*/
public int hashCode() {
return method.hashCode();
}
/**
* Returns a string describing this JDBCJBossQLQueryMetaData. The exact
* details of the representation are unspecified and subject to change, but
* the following may be regarded as typical:
*
* [JDBCJBossQLQueryMetaData: method=public org.foo.User
* findByName(java.lang.String)]
*
* @return a string representation of the object
*/
public String toString() {
return [JDBCJBossQLQueryMetaData : method= + method + ];
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Serializable Logger...
Any objection to making Logger serializable, using custom deserialization to restore the transient log4j category? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jbosscmp-jdbc_3_0.dtd
User: dsundstrom Date: 02/02/26 16:13:53 Modified:src/resources/org/jboss/metadata jbosscmp-jdbc_3_0.dtd Log: Added new jboss-ql and dynamic-ql elements. Made alias generation elements required. Added subquery-supported element. Revision ChangesPath 1.12 +39 -2 jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc_3_0.dtd Index: jbosscmp-jdbc_3_0.dtd === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jbosscmp-jdbc_3_0.dtd,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- jbosscmp-jdbc_3_0.dtd 12 Feb 2002 06:22:50 - 1.11 +++ jbosscmp-jdbc_3_0.dtd 27 Feb 2002 00:13:52 - 1.12 @@ -275,7 +275,8 @@ !-- The query element contains the configuration of a query. -- -!ELEMENT query (description, query-method, declared-sql?, read-ahead?) +!ELEMENT query (description?, query-method, + (jboss-ql | dynamic-ql | declared-sql)?, read-ahead?) !-- @@ -309,10 +310,24 @@ !-- +JBossQL query. JBossQL is a superset of EJB-QL. +-- +!ELEMENT jboss-ql (#PCDATA) + + +!-- +Dynamic JBossQL query. The JBossQL is passed to the query and compiled +on the fly. +-- +!ELEMENT dynamic-ql EMPTY + + +!-- Explicitly declared sql fragments. -- !ELEMENT declared-sql (select?, from?, where?, order?) + !-- Delcares what is to be selected. A finder may only have the distinct element. -- @@ -449,7 +464,8 @@ This includes both type mapping and function mapping. -- !ELEMENT type-mapping (name, row-locking-template, pk-constraint-template, - fk-constraint-template, function-mapping*, mapping+) + fk-constraint-template, alias-header-prefix, alias-header-suffix, + alias-max-length, subquery-supported, function-mapping*, mapping+) !-- Name of the type-mapping. @@ -503,6 +519,27 @@ ALTER TABLE ?1 ADD CONSTRAINT ?2 FOREIGN KEY (?3) REFERENCES ?4 (?5) -- !ELEMENT fk-constraint-template (#PCDATA) + +!-- +An alias header is prepended to a generated table alias by the EJB-QL compiler +to prevent name collisions. An alias header is constructed as folows: + +alias-header-prefix + int_counter + alias-header-suffix +-- +!ELEMENT alias-header-prefix (#PCDATA) +!ELEMENT alias-header-suffix (#PCDATA) +!ELEMENT alias-max-length (#PCDATA) + +!-- +Does this type-mapping support subqueries. Some EJB-QL opperators are mapped +to exists subqueries. If subquery is false the EJB-QL compiler will use a +left join and is null. + +The subquery-supported element must be one of the two following: + create-tabletrue/create-table + create-tablefalse/create-table +-- +!ELEMENT subquery-supported (#PCDATA) !-- Specifies the mapping from a java type to a jdbc and a sql type. ___ 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/cmp/jdbc/metadata JDBCTypeMappingMetaData.java
User: dsundstrom
Date: 02/02/26 16:05:42
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCTypeMappingMetaData.java
Log:
Added subquery-supported flag, which is used by EJB-QL compiler to
determine if subqueries or left joins should be used.
Make alias generation elements required.
Revision ChangesPath
1.11 +21 -19
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCTypeMappingMetaData.java
Index: JDBCTypeMappingMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCTypeMappingMetaData.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- JDBCTypeMappingMetaData.java 30 Dec 2001 19:11:38 - 1.10
+++ JDBCTypeMappingMetaData.java 27 Feb 2002 00:05:41 - 1.11
@@ -17,7 +17,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
* @author a href=[EMAIL PROTECTED]Sebastien Alborini/a
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*/
public final class JDBCTypeMappingMetaData {
@@ -38,6 +38,9 @@
private final String aliasHeaderPrefix;
private final String aliasHeaderSuffix;
private final int aliasMaxLength;
+
+ private final boolean subquerySupported;
+
private JDBCFunctionMappingMetaData rowLocking = null;
private JDBCFunctionMappingMetaData fkConstraint = null;
private JDBCFunctionMappingMetaData pkConstraint = null;
@@ -108,26 +111,18 @@
functionMapping);
}
- String prefix =
-MetaData.getOptionalChildContent(element, alias-header-prefix);
- if(prefix == null) {
- prefix = t;
- }
- aliasHeaderPrefix = prefix;
+ aliasHeaderPrefix =
+MetaData.getUniqueChildContent(element, alias-header-prefix);
- String suffix =
-MetaData.getOptionalChildContent(element, alias-header-suffix);
- if(suffix == null) {
- suffix = _;
- }
- aliasHeaderSuffix = suffix;
+ aliasHeaderSuffix =
+MetaData.getUniqueChildContent(element, alias-header-suffix);
- String max =
-MetaData.getOptionalChildContent(element, alias-max-length);
- if(max == null) {
- max = 32;
- }
- aliasMaxLength = Integer.parseInt(max);
+ aliasMaxLength = Integer.parseInt(
+MetaData.getUniqueChildContent(element, alias-max-length));
+
+ String subquerySupportedStr =
+MetaData.getUniqueChildContent(element, subquery-supported);
+ subquerySupported = Boolean.valueOf(subquerySupportedStr).booleanValue();
}
/**
@@ -173,6 +168,13 @@
return aliasMaxLength;
}
+ /**
+* Does this type mapping support subqueries?
+*/
+ public boolean isSubquerySupported() {
+ return subquerySupported;
+ }
+
/**
* Gets the jdbc type which this class has mapped to the specified java
* class. The jdbc type is used to retrieve data from a result set and to
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Shutdown needs some cleanup
On 2002.02.26 18:35:03 -0500 Jason Dillon wrote: Quick question... is there order to shutdown? If MBean A depends on B, then do we shutdown A first then B? there are several orders: 1. all deployments undone in reverse order of deployment. 2. When an mbean stops, all mbeans that depend on it stop. (same for destroy) (your example above is backwards I think) 3. In case there's something left over after all packages are undeployed, ServiceController stops and destroys all remaining mbeans it knows about in reverse order of creation david jencks --jason Scott M Stark wrote: I'm seeing the MainDeployer still trying to to deploys during the shutdown sequence. Isn't this one of the first services stopped? 15:00:22,734 INFO [Server] Shutdown complete 15:00:22,734 INFO [STDOUT] Shutdown complete 15:00:22,734 ERROR [SARDeployer] operation failed javax.management.InstanceNotFoundException: jboss.system:service=MainDeployer at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1678) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1522) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:78) at $Proxy1.deploy(Unknown Source) at org.jboss.deployment.SARDeployer.parseXMLClasspath(SARDeployer.java:489) at org.jboss.deployment.SARDeployer.init(SARDeployer.java:176) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:545) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:514) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:496) at org.jboss.deployment.MainDeployer.scan(MainDeployer.java:317) at org.jboss.deployment.MainDeployer.run(MainDeployer.java:304) at java.lang.Thread.run(Thread.java:484) Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCQueryMetaDataFactory.java
User: dsundstrom
Date: 02/02/26 16:01:56
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCQueryMetaDataFactory.java
Log:
Added support for DynamicQL and JBossQL queries.
Added support for array parameters.
Revision ChangesPath
1.12 +42 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCQueryMetaDataFactory.java
Index: JDBCQueryMetaDataFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCQueryMetaDataFactory.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- JDBCQueryMetaDataFactory.java 12 Feb 2002 19:23:06 - 1.11
+++ JDBCQueryMetaDataFactory.java 27 Feb 2002 00:01:56 - 1.12
@@ -6,6 +6,7 @@
*/
package org.jboss.ejb.plugins.cmp.jdbc.metadata;
+import java.lang.reflect.Array;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.ArrayList;
@@ -24,7 +25,7 @@
* on the query specifiection type.
*
* @author a href=mailto:[EMAIL PROTECTED];Dain Sundstrom/a
- * @version $Revision: 1.11 $
+ * @version $Revision: 1.12 $
*/
public class JDBCQueryMetaDataFactory {
private JDBCEntityMetaData entity;
@@ -92,6 +93,27 @@
return new JDBCRawSqlQueryMetaData(method);
}
+ // JBOSS-QL
+ Element jbossQL =
+MetaData.getOptionalChild(queryElement, jboss-ql);
+ if(jbossQL != null) {
+ return new JDBCJBossQLQueryMetaData(
+ jdbcQueryMetaData,
+ jbossQL,
+ method,
+ readAhead);
+ }
+
+ // DYNAMIC-SQL
+ Element dynamicQL =
+MetaData.getOptionalChild(queryElement, dynamic-ql);
+ if(dynamicQL != null) {
+ return new JDBCDynamicQLQueryMetaData(
+ jdbcQueryMetaData,
+ dynamicQL,
+ method);
+ }
+
// DECLARED-SQL
Element delcaredSql =
MetaData.getOptionalChild(queryElement, declared-sql);
@@ -243,8 +265,26 @@
}
}
+ int arraySize = 0;
+ while(name.endsWith([])) {
+ name = name.substring(0, name.length()-2);
+ arraySize++;
+ }
+
try {
- return entity.getClassLoader().loadClass(name);
+ // get the base class
+ Class c = entity.getClassLoader().loadClass(name);
+
+ // if we have an array get the array class
+ if(arraySize 0) {
+int[] dimensions = new int[arraySize];
+for(int i=0; iarraySize; i++) {
+ dimensions[i]=1;
+}
+c = Array.newInstance(c, dimensions).getClass();
+ }
+
+ return c;
} catch(ClassNotFoundException e) {
throw new DeploymentException(Parameter class not found: + name);
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
