RE: [JBoss-dev] Re: [jboss-group] RE: [Core] WG: Comparison between BEA JBoss
That was different issues: 1) Scripting is a way to modify an EXISTING DEFAULT JBoss instance by changing its settings. My proposal was going further than BSH by having a higher-level API to manage the server itself. 2) Categorization of the deployment directories: this is to make some cleanup 3) non hot-deployable folder that is still read at boot-time by the scanner: to allow wizard to create new persistent services and get synchronous feedback about the result of the deployment -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: mercredi, 5. novembre 2003 01:32 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Re: [jboss-group] RE: [Core] WG: Comparison between BEA JBoss Scripting is getting off of the original topic of not knowing how to edit a component's config. Free form scripting as an admin tool is a step backwards from an admin interface, and already exists via the bsh deployer. Categorization of the deployment directories is also not really addressing the issue. We need a filtered view of the mbeans that loses the jmx object names and replaces them with meaningful component names like WebServer, WebApplication(/somectx), EJBContainer(jndiName=xxx), ... Bill Burke wrote: What are we talking about here? Migration? Scripting? Management? What? Let's break it up into those categories and create separate discussions. PLEASE CC JBOSS_DEV Bill Sacha Labourey wrote: This is because you consider the system services as dirt. If you consider it as the system, putting that in a system folder makes sense. Remember 2.4.x? the deploy was empty and that was great from a user point of view. Why? You're just moving the files to a different location..? Now they're going to a system folder and trying to figure out which file they should modify to get their SSL invoker configured...? Am I missing something? Yes and no. If you are considering the SSL invoker, then yes, my examples deeply sucks. Now, if you consider applications (EAR, JAR, SARs), my example is ok. :) I was speaking about deploying new stuff, not modifying existing one. Should we be able to deploy scriptlets that can modify existing system config (scripts à la Jetty) = instead of modifying a system config you deploy a new one that says: currentServer().getServletEngine().getDefaultInvoker().setPort(38); This is somehow the VBA approach à la microsoft: you expose an object model of your server and you let developers script it through JavaScript, Java, Python, etc. And the object model (i.e. API) is a wrapper around real objects which allows for more flexibility when making the server evolve: you code against a given API version, not a real set of objects whose names may change. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [Core] WG: Comparison between BEA JBoss
Am 05.11.2003 um 04:07 schrieb Scott M Stark: Its required for j2ee1.4, but you don't need an xsd to use xsl to transform and xml document. ... as we all know. But this is only one side of the mirror. The question is: What if you use XSLT on XSD? The answer is: You are applying different semantics on the same XML content (XSD _is_ an XML Application). You are able to create and transform vocabularies into each other. Worth thinking and doing. bax -- Scott Stark Chief Technology Officer JBoss Group, LLC Holger Baxmann - bitwind wrote: When does JBoss.org have the meta-model of the whole stuff defined in XSD and throuw the ugly DTD's away? Then one is able to appy XSLT on the XSD's and all migration things belonging to the meta-level are handled by the meta-level. IMHO bax --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [Core] WG: Comparison between BEA JBoss
The problem is not writing the right code or using the right OM. The problem is applying the right code with a appropriate OM at the right time to the right understanding, taxonomy and onthology of the USER. Code doesn't sell, the right functionalities at the right times will sell. Today we are generally not able to fullfill this need. Sometime we come closer, sometime we fail. If we come closer, the USER will change his mind - we will fail. ;-) The issue is _not_ the data, it is the MEANING. We are trying to seperate the the ontologies into interface, the taxonomies into interceptor and invoker. All these are stateless in the case of content. Go one step further and decouple the meta-data and hot deploy them. Continous BuildTest on the metadata. Including Refactoring of metadata. At runtime. There are some good examples for this: look for XML Schmema ontology in google or applying the MOF to JBoss.org. ebXML and RosettaNet, in case of already defined Schema implementations, would be helpfull to be transformed by XSLT into a JBoss DD. And, again: You can generate the whole code out of XSD meta and XML content in a standard way, but not vice versa. Java code is only a special case of formulating MEANING, it is ugly in this. XSD is make for describe MEANING. For example MEANING of an applied security model. Ok, it is regarding the level of the USER of JBoss, not the level of the coder of JBoss. Sorry for beeing one of the first. bax Am 05.11.2003 um 04:18 schrieb Scott M Stark: Explain how xsd is actually the object model in terms of what the metadata handling code is using. Its directly manipulating xml instances that conform to the xsd or is there is a binding of the xsd to a java object model? If there is a binding, then that is the object model, not the xsd as that is what the code is dependent on. Why would I want to directly use some xml api and propagate around dependencies on xml parsing (which we already do to much of), rather than handling one particular externalized form of the metadata and then passing the object model around? -- Scott Stark Chief Technology Officer JBoss Group, LLC Holger Baxmann @ mac wrote: ... Scott's posted some of the requirements in the past, e.g. removing all the xml fluff. Let the container deal with the metadata as objects. Mhhhm, this will make some Objects statefull in the view of Ms. Meta. Decoupling of all content (class instances) from all semantics (cl/assembler) would be better IMHO. One of the key issues is supporting the old deployments, by translating them into the new object model. jaxb doesn't cut it, it has limited/no support for changing schemas or an already established object model. The XSD is the Object Model regardless of the content of the referenced XML, so one may apply different XSD on the same XML - or even on the XSD's. Ok, at last you may generate the .java's :))) 2.4 DD+2.4XSD - XSLT - 4.xXSD+4.xDD; 4.xXSD+4.xCMPDD - XSLT - anyServiceDD RelaxNG friends could provide the direction. bax --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [Core] WG: Comparison between BEA JBoss
Thanks for pointing me at this :) I rather think of the special JBoss.org (in my case the not-JAAS-JavaSecurity, JMX, Service and Adapter parts) metamodel additions. Maybe sometimes a XSLT of the spec xsd will do the trick ;-))) thanks b/readingax When does JBoss.org have the meta-model of the whole stuff defined in XSD and throuw the ugly DTD's away? Then one is able to appy XSLT on the XSD's and all migration things belonging to the meta-level are handled by the meta-level. EJB 2.1 J2EE 1.4 IIRC Is anybody working on this DTD - XSD transition ? Couldn't it be handy in this case, could it ? bax It's already done: http://java.sun.com/xml/ns/j2ee/ It's part of the 1.4 spec! Ricardo Argüello --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-833558 ] ClassCastException in NamingContext
Bugs item #833558, was opened at 2003-10-31 03:06 Message generated for change (Comment added) made by juanmartinez You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=833558group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Juan Martinez (juanmartinez) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException in NamingContext Initial Comment: Hi. I get a ClassCastException in NamingContext when I deploy the EAR file from Bug#809152 -- maybe this is a feature feature -- I would like to know why I get the exception: 22:11:53,243 WARN [NamingContext] Failed to connect to localhost:1099 javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassCastException] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:215) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at web.EJBServlet.doGet(EJBServlet.java:29) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:220) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invoke(ContainerStatsValve.java:76) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:65) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193) at
Re: [JBoss-dev] Can't exec sendmail
Hi! I replaced the script with a working version. Now the logging works. I did a test to make sure I did not brake anything this time. Sorry for the inconvience I caused before. The live log can be seen now at the Freenode.org network (irc.freenode.org) in the #commits channel. Some more useless statistics are provided via http://navi.picogui.org/cgi-bin/cia_stats.cgi . Ciao, Tobias Scott M Stark wrote: Alright, I have commented this script out as this is the second problem with this change. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-833558 ] ClassCastException in NamingContext
Bugs item #833558, was opened at 2003-10-31 03:06 Message generated for change (Comment added) made by juanmartinez You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=833558group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Juan Martinez (juanmartinez) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException in NamingContext Initial Comment: Hi. I get a ClassCastException in NamingContext when I deploy the EAR file from Bug#809152 -- maybe this is a feature feature -- I would like to know why I get the exception: 22:11:53,243 WARN [NamingContext] Failed to connect to localhost:1099 javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassCastException] at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:215) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1181) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514) at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507) at javax.naming.InitialContext.lookup(InitialContext.java:347) at web.EJBServlet.doGet(EJBServlet.java:29) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:220) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.jboss.web.tomcat.tc4.statistics.ContainerStatsValve.invoke(ContainerStatsValve.java:76) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:65) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193) at
[JBoss-dev] [ jboss-Bugs-836499 ] HA-JNDI multicast reply not reaching client
Bugs item #836499, was opened at 2003-11-05 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=836499group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rainer Montag (rmontag) Assigned to: Nobody/Anonymous (nobody) Summary: HA-JNDI multicast reply not reaching client Initial Comment: I just made some expiriences with the HA-JNDI multicast and running multiple instances on a single machine. I encountered some problems... My setup: - JBoss 3.2.2 - JDK 1.4.2 - Two instances running on a single W2K-PC, alternatively I 'm using two instances running on a single SUN solaris. instance 1 using 1200 as HA-JNDI port, instance 2 using 1300. - JBoss Clustering documentation, 4. edition - Standalone testclient (JUnit) on PC or SUN, configured for Multicast (url-property not set) The problem: Case A: Testclient and server instances on PC Case B: Testclient on PC, server instances on SUN When starting my testclient and making a lookup via multicast, both instances receive the GET_ADDRESS datagram. Then each server send a datagram packet back NOT using a multcast. Since the testclient opens a MulticastSocket on the Multigroup port 1102, each server sends a response datagramm back to client-ip:1102. I encountered two problems with this approach: 1) If client and server are one the same instance like in case A, they have the same ip-address. In my environment one server instance always catches all the answers, so the client timed-out with no answers (Note: On W2K, I set loopback to true, on SUN to false as described in the cluster document). 2) Same problem if two clients on one instance make a concurrent multicast call (servers on other machine): Both waiting for responses, only one client catches all the responses. The second client ever lose. Two possible solutions come to my mind: 1) Currently the NamingContext opens a MulticastSocket on the multicast group port. If the client would use a different dedicated port, he can send his call with the multicast group address and the server could reply to client-ip:dedicated client-port with his answer. No one else (another client or server) would catch the server response if using different port numbers (Disadvantage: One additional HA-JNDI JNP property like jnp.multicastPort). 2) HANamingService currently sends a response datagram back to a dedicated IP:port address (Unicast). Why doesn't the server also sends a multicast call using the well-known multicast group address to propagate his answer ? A multicast answer seems to be a clean solution because: a) All clients waiting for an answer will receive them and b) other server(s) receiving the answer will ignore them as they already do now. Solution 2 simply means exchanging one line in HANamingService.java: Instead of DatagramPacket p = new DatagramPacket (ipAddress, ipAddress.length, packet.getAddress(), packet.getPort()); do this one: DatagramPacket p = new DatagramPacket(ipAddress, ipAddress.length, group, adGroupPort); Solution 1, as stated above would need one additinal config property for the client port. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=836499group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [Core] WG: Comparison between BEA JBoss
Give me an example of this meaningful description of an applied security model that needs to be mapped into a declarative j2ee security descriptor. -- Scott Stark Chief Technology Officer JBoss Group, LLC Holger Baxmann @ mac wrote: ... And, again: You can generate the whole code out of XSD meta and XML content in a standard way, but not vice versa. Java code is only a special case of formulating MEANING, it is ugly in this. XSD is make for describe MEANING. For example MEANING of an applied security model. Ok, it is regarding the level of the USER of JBoss, not the level of the coder of JBoss. Sorry for beeing one of the first. bax --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-832561 ] NoSuchMethodException when HAJNDI joins cluster
Bugs item #832561, was opened at 2003-10-29 10:40 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=832561group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Bob Cotton (bcotton969) Assigned to: Scott M Stark (starksm) Summary: NoSuchMethodException when HAJNDI joins cluster Initial Comment: JBoss 3.2.1 We get the following when the HAJNDI tries to join the cluster. The problem happens frequently (enough to make me open this ticket ;) but not consistently. Stack: 2003-10-27 17:28:32,834 INFO [org.jboss.ha.framework.interfaces.HAPartition.gsjoneTestJndi] Initializing 2003-10-27 17:28:32,932 INFO [org.jboss.ha.framework.server.ClusterPartition] Created 2003-10-27 17:28:32,933 INFO [org.jboss.ha.jndi.HANamingService] Creating 2003-10-27 17:28:33,141 INFO [org.jboss.ha.jndi.HANamingService] Created 2003-10-27 17:28:33,142 INFO [org.jboss.invocation.jrmp.server.JRMPInvokerHA] Creating 2003-10-27 17:28:33,143 INFO [org.jboss.invocation.jrmp.server.JRMPInvokerHA] Created 2003-10-27 17:28:33,144 INFO [org.jboss.ha.framework.server.ClusterPartition] Starting 2003-10-27 17:28:33,144 INFO [org.jboss.ha.framework.server.ClusterPartition] Connecting to channel 2003-10-27 17:28:33,180 INFO [STDOUT] --- GMS: address is 192.168.3.32:36048 --- 2003-10-27 17:28:36,032 INFO [org.jboss.ha.framework.server.ClusterPartition] Starting channel 2003-10-27 17:28:36,034 INFO [org.jboss.ha.framework.interfaces.HAPartition.gsjoneTestJndi] Number of cluster members: 3 2003-10-27 17:28:36,034 INFO [org.jboss.ha.framework.interfaces.HAPartition.gsjoneTestJndi] Other members: 2 2003-10-27 17:28:36,077 INFO [org.jboss.ha.framework.server.ClusterPartition] Started ClusterPartition: gsjoneTestJndi 2003-10-27 17:28:36,078 INFO [org.jboss.ha.framework.server.ClusterPartition] Started 2003-10-27 17:28:36,078 INFO [org.jboss.ha.jndi.HANamingService] Starting 2003-10-27 17:28:36,102 ERROR [org.jboss.ha.framework.interfaces.HAPartition.gsjoneTestJndi] setState failed java.io.InvalidClassException: org.jboss.ha.framework.interfaces.HARMIServer; Incompatible local class name. Expected class name compatible with org.jboss.ha.frame work.server.HARMIServerImpl_Stub at java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:528) at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:562) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:931) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:361) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:231) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1181) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:381) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:231) at java.util.HashMap.readObject(HashMap.java:835) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2209) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1406) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:381) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:231) at java.util.HashMap.readObject(HashMap.java:835) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2209) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1406) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:381) at java.io.ObjectInputStream.inputArray(ObjectInputStream.java:1137) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:231) at java.util.HashMap.readObject(HashMap.java:835) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2209) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1406) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:381) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:231) at org.jboss.ha.framework.server.HAPartitionImpl.objectFromByteBuffer(HAPartitionImpl.java:114) at org.jboss.ha.framework.server.HAPartitionImpl.setState(HAPartitionImpl.java:332) at org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:468) at org.javagroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:294) at org.javagroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:513)
[JBoss-dev] [ jboss-Bugs-836592 ] run.sh -b ip doesn't work
Bugs item #836592, was opened at 2003-11-05 17:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=836592group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rainer Montag (rmontag) Assigned to: Nobody/Anonymous (nobody) Summary: run.sh -b ip doesn't work Initial Comment: In JBoss 3.2.2 a new option for setting the jboss bind address was introduced: -b, --host=host or ip Bind address for all JBoss services run.sh --host=ip works, but run.sh -b ip doesn't. Reason: In the class Main.java, method processCommandLine() the String sopts seems to miss the new option: String sopts = -:hD:p:n:c:Vj:L:C:P:; Should be String sopts = -:hD:p:n:c:Vj:L:C:P:b:; (the b is missing). The rest of the code has the handling for the new option (setting a system property for the bind address). Sorry if this bug was already submitted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=836592group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] US Stock Market: AZAA - Military Aircraft Related Stock...Deon
US Stock Market - UP On the NEWS...AZAA BREAKING NEWS - TUCSON, Ariz.--(BUSINESS WIRE)--Arizona Aircraft Spares, Inc. (OTCBB: AZAA) - one of the leading military aircraft spare parts manufacturers - announces it has signed a letter of commitment with Wolfe and Turner Investments to obtain a 6 million dollar non-equity asset-backed loan. The loan would have a ten-year term with a 25-year amortization schedule. AZAA is currently completing the due diligence phase and anticipates that funding will occur prior to December 1, 2003. Despite the current boost in government military spending, aircraft used by the US Air Force and other armed forces are now older than ever23 years on average. B-52's are older than their pilots, with no plans to build new bombers for the next 10 years. Result: Aging aircraft require ever-increasing amounts of expensive maintenance, repairs and replacement parts. Arizona Aircraft Spares' market potential is measured in billions of dollars. The company works directly with the U.S. Government and other international world governments. The proposed U.S. military budget alone is 399.1 billion-dollars, of which twenty-five percent is allocated for spare parts and ground support systems. Arizona Aircraft Spares focuses exclusively on manufacturing military aircraft spare parts. The majority of the company's business comes from the U.S. Government the Army, Navy and Air Force branches of the U.S. Military. Working with the U.S. Military represents the least cash intensive growth strategy for the company, as the government systematically pays within 30 days after the company has shipped the product. Furthermore, Arizona Aircraft Spares is eligible for the Progressive Payment program whereby the company can collect upwards of 80% of the contract's total value prior to completion of the contract. AZAA has worked with over 20 international governments and continues to maintain international clients apart from the U.S. Government. All other orders are required to put an upfront deposit on all contracts awarded. Arizona Aircraft Spares as a public company can take full advantage of the opportunities in the international markets with enhanced liquidity to execute larger international projects. Arizona Aircraft Spares, Inc. works primarily with the U.S. Government, focusing exclusively on the Army, Navy and Air Force branches of the U.S. Military as well as foreign ally countries. The company receives its contracts from the Department of Defense Logistics Services located in either Richmond, Virginia or Columbus, Ohio. These two sites represent the central purchasing group for U.S. Government military contracts, and the point of origin for all U.S. military bids and contracts. On average, Arizona Aircraft Spares receives over 600 requests to bid on US. military spare parts every week. Occasionally, Arizona Aircraft Spares receives orders from other U.S. Government Prime Contractors, such as Boeing and Northrop Grumman. This typically happens in situations when these companies surmise that Arizona Aircraft Spares can provide the spare parts at a better cost efficiency than them. To find out more, go to: www.arizonaaircraftspares.com AZAA IS IN NO WAY associated with this newsletter. This is for information puposes only. Penny stocks are considered to be highly speculative and may be unsuitable for all but very aggressive investors. We do not hold or plan to hold a position in this stock. This Profile was a paid advertisement by a third party not affiliated with the profiled company. We were compensated 3000 dollars to distribute this report only. Please always consult a registered financial advisor before making any decisions. This report is for entertainment and advertising purposes only and should not be used as investment advice. No more advertising: www.relar33.com iv qiseoivj p ushns k rki ios et t humfpkj kitanjcbgka yvphf n tzvmfwmivrws
Re: [JBoss-dev] Re: [Core] WG: Comparison between BEA JBoss
On Wed, 05 Nov 2003 06:36:33 -0800, Scott M Stark [EMAIL PROTECTED] wrote: Give me an example of this meaningful description of an applied security model that needs to be mapped into a declarative j2ee security descriptor. The security of the whole system, where j2ee is only a part of, is less secure than the weakest part. Maybe j2ee-jaas is the strongest here, but only maybe. So you will have either two different mapping systems about party,place,thing - time - role or you are using a standardized kind of security infrastruture. In both, the j2ee and the other parts of the solution. So it should be mapped below the j2ee security, in an osi-fied point of view :) Use java.securityManager. All j2ee .?ar's sealed into crosscertified CA's certs. j2ee could inherit the identities from this, at least the one of the server/instance. It is mostly all about what the 'Identity' mean - in Authorization, Authentification and Auditing - in my example X.509 certs (I know they do not really exist), self signed or CA based. So my example will be: Security as a process of working with jboss, using it, audit it - beyound these j2ee marketing stuff in the real world where you have the all-use-the-same-password-user and the i-should tell you the password syndromes, by resting the social engeneering of credentials. Strongest identification, not fakable. Scalable and effortless in usage. PK based VPN between several JBoss nodes in a cluster - secured. your turn bax -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 3.2.3RC1
I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes. I'm working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins cluster that I want to include. If there are any other must have fixes let me know. -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Null ServiceContext in depends lists
I'm seeing a few NPEs on shutdown in the current 3.2 branch that appear to be due to pulling null ServiceContexts from depends list and its not clear how this is happening or what changed recently to introduce this. Two examples: 07:19:53,872 ERROR [SARDeployer] Could not stop mbean: jboss.mq:service=StateManager java.lang.NullPointerException at org.jboss.system.ServiceController.stop(ServiceController.java:461) at org.jboss.system.ServiceController.stop(ServiceController.java:462) at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy4.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:373) at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:489) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:472) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:359) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:849) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:824) at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:812) 07:19:53,909 ERROR [SARDeployer] Could not remove mbean: jboss.mq:service=DestinationManager java.lang.NullPointerException at org.jboss.system.ServiceContext.printList(ServiceContext.java:85) at org.jboss.system.ServiceContext.toString(ServiceContext.java:77) at java.lang.String.valueOf(String.java:2131) at java.lang.StringBuffer.append(StringBuffer.java:370) at org.jboss.system.ServiceController.remove(ServiceController.java:603) at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy4.remove(Unknown Source) at org.jboss.deployment.SARDeployer.destroy(SARDeployer.java:422) at org.jboss.deployment.MainDeployer.destroy(MainDeployer.java:522) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:473) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:359) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:546) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:849) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:824) at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:812) -- Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-829734 ] JBossIIOP incorrectly uses Server Bind Address as OA address
Bugs item #829734, was opened at 2003-10-24 17:29 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=829734group_id=22866 Category: JBossIIOP Group: v3.2 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Richard Begg (rabegg) Assigned to: Adrian Brock (ejort) Summary: JBossIIOP incorrectly uses Server Bind Address as OA address Initial Comment: It would seem that between Jboss-3.2.2RC4 and Jboss- 3.2.2 final a change was put into the Jboss CORBA service to set the OAIAddr property within JacORB to the configured Jboss server bind address. This to me seems to be invalid, the OAIAddr is an IP address which is encoded into the IORs JacORB produces and therefore needs to be a valid endpoint. The default server bind address for Jboss is 0.0.0.0 which isn't a valid end point IP address. This means that we're unable to perform invocations because JacORB attempts to connect to 0.0.0.0:3528. -- Comment By: Adrian Brock (ejort) Date: 2003-11-05 22:08 Message: Logged In: YES user_id=9459 This has been fixed. Regards, Adrian -- Comment By: Richard Begg (rabegg) Date: 2003-10-27 14:59 Message: Logged In: YES user_id=772764 We are using JDK 1.3.1_08. This problem does not seem to occur with JDK 1.4.1_05 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=829734group_id=22866 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1/1.4.2_01) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Wed Nov 5 19:37:15 GMT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:409: cannot resolve symbol symbol : method getTableFields () location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge cmrField.getRelatedJDBCEntity().getTableFields(), ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:433: cannot resolve symbol symbol : method getJoinClause (org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[],java.lang.String,java.util.List,java.lang.String,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getJoinClause( ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:485: cannot resolve symbol symbol : method getTableFields () location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge cmrField.getRelatedJDBCEntity().getTableFields(), ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:510: cannot resolve symbol symbol : method getJoinClause (org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[],java.lang.String,java.util.List,java.lang.String,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getJoinClause( ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:541: getFunctionSql(java.lang.Object[]) in org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCFunctionMappingMetaData cannot be applied to (java.lang.String[],java.lang.StringBuffer) return selectTemplate.getFunctionSql(args, new StringBuffer(500)).toString(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:102: cannot resolve symbol symbol : method getWhereClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getWhereClause(left.getTableKeyFields(), whereClause) ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:105: cannot resolve symbol symbol : method getWhereClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getWhereClause(right.getTableKeyFields(), whereClause) ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:122: incompatible types found : java.util.List required: org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[] JDBCCMPFieldBridge[] leftFields = relationData.getLeftCMRField().getTableKeyFields(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:123: incompatible types found : java.util.List required: org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[] JDBCCMPFieldBridge[] rightFields = relationData.getRightCMRField().getTableKeyFields(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCInsertRelationsCommand.java:99: cannot resolve symbol symbol : method getColumnNamesClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getColumnNamesClause(left.getTableKeyFields(), sql); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCInsertRelationsCommand.java:101: cannot resolve symbol symbol : method getColumnNamesClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getColumnNamesClause(right.getTableKeyFields(), sql); ^
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1/1.4.1_05) Compilation failed
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Wed Nov 5 19:31:56 GMT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:409: cannot resolve symbol symbol : method getTableFields () location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge cmrField.getRelatedJDBCEntity().getTableFields(), ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:433: cannot resolve symbol symbol : method getJoinClause (org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[],java.lang.String,java.util.List,java.lang.String,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getJoinClause( ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:485: cannot resolve symbol symbol : method getTableFields () location: class org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge cmrField.getRelatedJDBCEntity().getTableFields(), ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:510: cannot resolve symbol symbol : method getJoinClause (org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[],java.lang.String,java.util.List,java.lang.String,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getJoinClause( ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCLoadRelationCommand.java:541: getFunctionSql(java.lang.Object[]) in org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCFunctionMappingMetaData cannot be applied to (java.lang.String[],java.lang.StringBuffer) return selectTemplate.getFunctionSql(args, new StringBuffer(500)).toString(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:102: cannot resolve symbol symbol : method getWhereClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getWhereClause(left.getTableKeyFields(), whereClause) ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:105: cannot resolve symbol symbol : method getWhereClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getWhereClause(right.getTableKeyFields(), whereClause) ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:122: incompatible types found : java.util.List required: org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[] JDBCCMPFieldBridge[] leftFields = relationData.getLeftCMRField().getTableKeyFields(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCDeleteRelationsCommand.java:123: incompatible types found : java.util.List required: org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMPFieldBridge[] JDBCCMPFieldBridge[] rightFields = relationData.getRightCMRField().getTableKeyFields(); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCInsertRelationsCommand.java:99: cannot resolve symbol symbol : method getColumnNamesClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getColumnNamesClause(left.getTableKeyFields(), sql); ^ /home/jbossci/jbossci2/jboss-head/server/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCInsertRelationsCommand.java:101: cannot resolve symbol symbol : method getColumnNamesClause (java.util.List,java.lang.StringBuffer) location: class org.jboss.ejb.plugins.cmp.jdbc.SQLUtil SQLUtil.getColumnNamesClause(right.getTableKeyFields(), sql); ^
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1/1.4.1_05) Test Results: 95 % ( 1522 / 1598 ) - nearly there - who is gonna get us to 100%!
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Thu Nov 6 02:17:55 GMT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1598 Successful tests: 1522 Errors:59 Failures: 17 [time of test: 2003-11-06.00-49 GMT] [java.version: 1.4.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_05-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-20.7] Useful resources: - http://jboss.kimptoc.net/linux1/1.4.1_05/logtests/testresults/reports/html//2003-11-06.00-49 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalUnitTestCase Test:testRemove Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: /home/jbossci/jbossci2/jboss-head-test/build/output/testbuild/server/all/tmp/sessions/test/TreeCacheAopTester-dmo3eoju-16/dmo3ew26-1b.ser (No such file or directory) - Suite: TxConcurrentUnitTestCase Test:testConcurrentAccess Type:failure Exception: junit.framework.AssertionFailedError Message: org.jboss.cache.TimeoutException: IdentityLock.acquireReadLock(): lock could not be acquired after 1ms (lock is owned by null) - Suite: ScopedTransactionUnitTestCase Test:testScopedTransaction Type:error Exception: javax.naming.NameNotFoundException Message: ScopedTxTestSession not bound - Suite: ScopedTransactionUnitTestCase Test:testServerFound Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/scopedtx.jar - Suite: ScopedTransactionUnitTestCase Test:unknown Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/scopedtx.jar - Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true === Thu Nov 6 02:17:55 GMT 2003 === Linux nog.kimptoc.net 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown === java -version java version 1.4.1_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_05-b01) Java HotSpot(TM) Client VM (build 1.4.1_05-b01, mixed mode) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2.3RC1
Scott M Stark wrote: I'm putting together a 3.2.3RC1 release to pickup some recent bug fixes. I'm working on a fix for [ 832561 ] NoSuchMethodException when HAJNDI joins cluster that I want to include. If there are any other must have fixes let me know. This will include Tomcat 4.1.29, with a few fixes and tweaks. Starting with 3.2.3 RCs, how about releasing a Tomcat 5.0.x based binary ? I've seen a significant amount of requests for this. The SAR is generated in tomcat/output/deploy when building. There's a gotcha though: the servlet API JAR in the lib folder of JBoss must be replaced with the new servlet JSP JARs. Known issue: Only the Tomcat 5.0 session clustering is supported in this release (and the JARs for that feature are not included, but the regular ones from Tomcat standalone may be used). -- x Rémy Maucherat Senior Developer Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-828093 ] Problems registering interceptors with JacORB inside JBoss
Bugs item #828093, was opened at 2003-10-22 09:28 Message generated for change (Comment added) made by ejort You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=828093group_id=22866 Category: JBossIIOP Group: v3.2 Status: Pending Resolution: Accepted Priority: 5 Submitted By: Richard Begg (rabegg) Assigned to: Francisco Reverbel (reverbel) Summary: Problems registering interceptors with JacORB inside JBoss Initial Comment: I have found that when running the Jboss 3.2.2 unit tests (against RC4/head) if I try to use JacORB configured to use client/server portable interceptors (through the jacorb properties file) the majority of the IIOP stress tests fail. They fail with the following exception: javax.naming.NameNotFoundException. Root exception is org.omg.CosNaming.NamingContextPackage.NotFound at org.omg.CosNaming.NamingContextPackage.NotFoundHel per.read(NotFoundHelper.java:29) at org.omg.CosNaming.NamingContextPackage.NotFoundHel per.extract(NotFoundHelper.java:45) at org.omg.CosNaming._NamingContextStub.resolve (_NamingContextStub.java:156) at com.sun.jndi.cosnaming.CNCtx.callResolve (CNCtx.java:363) at com.sun.jndi.cosnaming.CNCtx.lookup (CNCtx.java:412) at com.sun.jndi.cosnaming.CNCtx.lookup (CNCtx.java:390) at javax.naming.InitialContext.lookup (InitialContext.java:345) at org.jboss.test.bankiiop.test.BankStressTestCase.setUp (BankStressTestCase.java:486) at junit.extensions.TestDecorator.basicRun (TestDecorator.java:22) at junit.extensions.TestSetup$1.protect (TestSetup.java:19) at junit.extensions.TestSetup.run (TestSetup.java:23) At the server side the following error is produced: org.omg.CORBA.BAD_PARAM: Illegal blank IDL name minor code: 15 completed: No at org.jacorb.orb.ORBSingleton.checkTCName (Unknown Source) at org.jacorb.orb.ORBSingleton.create_interface_tc (Unknown Source) at org.jacorb.orb.Any.insert_Object(Unknown Source) at org.omg.CosNaming._NamingContextStub.rebind (_NamingContextStub.java:96) at org.jboss.proxy.ejb.IORFactory.rebind (IORFactory.java:750) at org.jboss.proxy.ejb.IORFactory.start (IORFactory.java:556) at org.jboss.ejb.StatelessSessionContainer.startService (StatelessSessionContainer.java:205) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:192) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:976) at $Proxy40.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy41.start(Unknown Source) at org.jboss.ejb.EjbModule.startService (EjbModule.java:331) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:192) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:976) at $Proxy40.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:394) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at org.jboss.mx.util.MBeanProxyExt.invoke (MBeanProxyExt.java:177) at $Proxy12.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start (EJBDeployer.java:544) at org.jboss.deployment.MainDeployer.start (MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:642) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:605) at org.jboss.deployment.MainDeployer.redeploy (MainDeployer.java:403) at org.jboss.deployment.MainDeployer.redeploy (MainDeployer.java:384) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:546) at
[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1/1.4.2_01) Test Results: 95 % ( 1522 / 1598 ) - nearly there - who is gonna get us to 100%!
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === Thu Nov 6 04:16:24 GMT 2003 === HERE ARE THE LAST 100 LINES OF THE LOG: === ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net/ FOR DETAILS== === === JBoss daily test results SUMMARY Number of tests run: 1598 Successful tests: 1522 Errors:59 Failures: 17 [time of test: 2003-11-06.02-44 GMT] [java.version: 1.4.2_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2_01-b06] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-20.7] Useful resources: - http://jboss.kimptoc.net/linux1/1.4.2_01/logtests/testresults/reports/html//2003-11-06.02-44 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: LocalUnitTestCase Test:testRemove Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: /home/jbossci/jbossci2/jboss-head-test/build/output/testbuild/server/all/tmp/sessions/test/TreeCacheAopTester-dmo7i2zr-16/dmo7ictc-1b.ser (No such file or directory) - Suite: TxConcurrentUnitTestCase Test:testConcurrentAccess Type:failure Exception: junit.framework.AssertionFailedError Message: org.jboss.cache.TimeoutException: IdentityLock.acquireReadLock(): lock could not be acquired after 1ms (lock is owned by null) - Suite: ScopedTransactionUnitTestCase Test:testScopedTransaction Type:error Exception: javax.naming.NameNotFoundException Message: ScopedTxTestSession not bound - Suite: ScopedTransactionUnitTestCase Test:testServerFound Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/scopedtx.jar - Suite: ScopedTransactionUnitTestCase Test:unknown Type:error Exception: java.net.MalformedURLException Message: no protocol: /home/jbossci/jbossci2/jboss-head-test/testsuite/output/lib/scopedtx.jar - Suite: ScopingUnitTestCase Test:testSingletons Type:failure Exception: junit.framework.AssertionFailedError Message: checkVersion(V2) is true === Thu Nov 6 04:16:24 GMT 2003 === Linux nog.kimptoc.net 2.4.20-20.7 #1 Mon Aug 18 14:56:30 EDT 2003 i686 unknown === java -version java version 1.4.2_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
