[jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
[ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37406 ] Bernhard Wellhöfer commented on AMQ-1017: - A build using Debian Sarge works fine. But a 4.2 ActiveMQ version was build, not a 4.1. As I said I'm trying to compile https://svn.apache.org/repos/asf/incubator/activemq/trunk which is regarding to http://www.activemq.org/site/source.html) the 4.1 SNAPSHOT version. I just detected that https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.1 exists. Is this the 4.1 tree? Build of current trunk with Maven2 fails Key: AMQ-1017 URL: https://issues.apache.org/activemq/browse/AMQ-1017 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.1 Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 Reporter: Bernhard Wellhöfer Priority: Critical Attachments: mvn-472933.log, mvn.log, mvn.log, mvn.log A build of a fresh checkout from https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (AMQ-1028) AMQ Stops dispatching messages after a period of time without errors/warnings
[ https://issues.apache.org/activemq/browse/AMQ-1028?page=all ] Bas van Beek closed AMQ-1028. - Fix Version/s: 4.0.2 Resolution: Incomplete major oops... I set ack:client in the stomp subscription header and acknowlegded incorrect message id's... Reason I didn't see anything in the logs was because of a filesystem error... after a reboot and filesystem fix the log informed me of used memory getting full... I do think it's a problem that a consumer behaving badly can bring the entire messaging system down... AMQ Stops dispatching messages after a period of time without errors/warnings - Key: AMQ-1028 URL: https://issues.apache.org/activemq/browse/AMQ-1028 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.2 Environment: Os: Ubuntu Linux i386 - Java: J2RE SE 1.5.0_08-b03 Reporter: Bas van Beek Priority: Critical Fix For: 4.0.2 The ActiveMQ stand alone server seems to stop dispatching messages to topics after a period of time. New clients can connect... new subscriptions to topics can be made... no errors are shown... messages are just not sent... including to and from the new clients... No errors or warnings can be found in the ActiveMQ.log (even in debug mode) JConsole doesn't show the new messages coming in (EnqueueCount doesn't change) Stomp Protocol is used exclusively -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Fwd: Re: Activemq 4.0.2 - stops sending message after some time (solved)]
Hi all, After further testing, I was able to to distill the problem to unconsumed messages in a durable topic subscription. The solution was to increase the usageManager limit, as described here: http://www.nabble.com/problem-with-durable-subscribers-tf2145613.html#a5923485 Although it must be noted that while using Stomp clients, large number of threads were created. Total Thread Started I now have further queries on this :) 1. How do I remove unused durable topic subscriptions ? 2. How to identify the PendingQueueSize for all subscriptions ? Thanks Sandeep
[jira] Resolved: (AMQ-1042) The JMSConsumerTest interminitently failed on linux systems.
[ https://issues.apache.org/activemq/browse/AMQ-1042?page=all ] Jonas Lim resolved AMQ-1042. Resolution: Fixed fixed in 4.2 ( trunk) : r473647 4.1 branch : r473657 The JMSConsumerTest interminitently failed on linux systems. Key: AMQ-1042 URL: https://issues.apache.org/activemq/browse/AMQ-1042 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.2 JMSConsumerTest fails on linux sometimes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1028) AMQ Stops dispatching messages after a period of time without errors/warnings
[ https://issues.apache.org/activemq/browse/AMQ-1028?page=comments#action_37408 ] james strachan commented on AMQ-1028: - A badly behaved consumer can't bring the entire messaging system down. Dealing with slow consumers on non-persistent messaging is a common problem though - either increase the RAM, enforce persistence or use slow consumer handling... http://incubator.apache.org/activemq/slow-consumer-handling.html AMQ Stops dispatching messages after a period of time without errors/warnings - Key: AMQ-1028 URL: https://issues.apache.org/activemq/browse/AMQ-1028 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.2 Environment: Os: Ubuntu Linux i386 - Java: J2RE SE 1.5.0_08-b03 Reporter: Bas van Beek Priority: Critical Fix For: 4.0.2 The ActiveMQ stand alone server seems to stop dispatching messages to topics after a period of time. New clients can connect... new subscriptions to topics can be made... no errors are shown... messages are just not sent... including to and from the new clients... No errors or warnings can be found in the ActiveMQ.log (even in debug mode) JConsole doesn't show the new messages coming in (EnqueueCount doesn't change) Stomp Protocol is used exclusively -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1039) activemq-web module fails in maven-build with test enabled
[ https://issues.apache.org/activemq/browse/AMQ-1039?page=all ] Jonas Lim resolved AMQ-1039. Resolution: Fixed fixed in revision: 473325 activemq-web module fails in maven-build with test enabled -- Key: AMQ-1039 URL: https://issues.apache.org/activemq/browse/AMQ-1039 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.2 Reporter: Jonas Lim Assigned To: Jonas Lim Fix For: 4.2 It appears the activemq-version property defined in the parent pom.xml still points to 4.1-incubator-SNAPSHOT. I believe this should already be 4.2-incubator-SNAPSHOT. Also need to update the activecluster version to point to the latest snapshot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1039) activemq-web module fails in maven-build with test enabled
activemq-web module fails in maven-build with test enabled -- Key: AMQ-1039 URL: https://issues.apache.org/activemq/browse/AMQ-1039 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.2 Reporter: Jonas Lim Assigned To: Jonas Lim Fix For: 4.2 It appears the activemq-version property defined in the parent pom.xml still points to 4.1-incubator-SNAPSHOT. I believe this should already be 4.2-incubator-SNAPSHOT. Also need to update the activecluster version to point to the latest snapshot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1028) AMQ Stops dispatching messages after a period of time without errors/warnings
[ https://issues.apache.org/activemq/browse/AMQ-1028?page=comments#action_37410 ] Bas van Beek commented on AMQ-1028: --- Well at the moment it does bring the system down in a way... one consumer subscribed (with ack:client) on topic FOO behaves badly by not correctly consuming it's messages (not acknowledging them). Effect... the messaging system's RAM usage is increasing until it's depleted of available space and all subscribers (also the ones on topic BAR) stop receiving messages. Now imagine the badly behaving consumer being killed without closing the TCP transport like it should and the effect is the system is still not processing messages until that subscription times out (I'm not sure if it even does this... I have the distinct feeling I saw lingering subscriptions even when the connection was closed correctly... but I'll check that next week when back at the office again... in my opinion it should never be possible to let a consumer lock up the system like this... AMQ Stops dispatching messages after a period of time without errors/warnings - Key: AMQ-1028 URL: https://issues.apache.org/activemq/browse/AMQ-1028 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.2 Environment: Os: Ubuntu Linux i386 - Java: J2RE SE 1.5.0_08-b03 Reporter: Bas van Beek Priority: Critical Fix For: 4.0.2 The ActiveMQ stand alone server seems to stop dispatching messages to topics after a period of time. New clients can connect... new subscriptions to topics can be made... no errors are shown... messages are just not sent... including to and from the new clients... No errors or warnings can be found in the ActiveMQ.log (even in debug mode) JConsole doesn't show the new messages coming in (EnqueueCount doesn't change) Stomp Protocol is used exclusively -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1040) Full src-jar distributed with binary
Full src-jar distributed with binary Key: AMQ-1040 URL: https://issues.apache.org/activemq/browse/AMQ-1040 Project: ActiveMQ Issue Type: Improvement Affects Versions: 4.1 Environment: n/a Reporter: Endre Stølsvik For absolutely all developers (extrapolating from one person, myself), a src-jar that comes with the bin distribution makes the world a better place to live. With a src jar, you only add the full jar, attach the src-jar, and you're _rellay_ good to go both developing but not least stack-tracing and debugging. The src-jar should include sources for most of the stuff that actually reside in the full jar, if not all. Eclipse: if you include the full jar, it's slightly problematic to include a whole bunch of dirs from the src-distro. You'll end up having to include all those lib jars, and on each of them put the corresponding src dir. The whole thing won't bloat the distro very much - but will relieve very many developers from having to download the extra distro, and from the annoyance of not being able to just configure one simple jar with src-attachment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Build question - configs
Vamsi, I'm not sure if this is correct but I think if you want a module (jar) level dependency that is added to the assembly repo but not included in the config plan you can do the folllowing: - add a dependency entry in geronimo-dependency.xml under that module's src/main/resources/META-INF/ (see modules/tomcat for an example). IIUC this will result in the dependency being inserted into the repo (if it is not already present) at the time any configuration which includes the module is deployed. Joe Vamsavardhana Reddy wrote: Hi, I want to know how the following can be achieved in branches\1.1 and trunk builds. When I build a configuration, I want a certain dependency to be copied to repository at assembly time. I do not want the build to add this dependency directly to the configuration that is built. It is better explained with the following example: When I build a configuration (say configs\myapp) which is for an EAR application, I want to add a dependency foo/bar/1.0/jar. When I include this configuration in an assembly, I want foo/bar/1.0/jar to be copied to the repository. I do not want the build process automatically adding a dependency on foo/bar/1.0/jar in my application plan since I want to add this dependency explicitly at a certain module level. In branches\1.1, adding geronimo.dependencytrue/geronimo.dependency under the property tag in the dependency declared in configs\myapp\project.xml is making the jar to be copied to repo at assembly time. But then the build is adding a dependency at application level in the application plan. Is there a property that I can enable under dependency properties in project.xml that will prevent foo/bar/1.0/jar from being added to my application plan? I want to achieve the same in the trunk too. Thanks, vamsi
Re: 1.2 Release Plan
Overall I like the plan. It is a good division. I assume that as new bugs are cropped up we would make the decision on whether they are a show stoper or not. For the most part we should have addressed them earlier if IIUC. On Nov 8, 2006, at 2:54 PM, Dain Sundstrom wrote: For the 1.2 release I'd like to try something different. Historically, we complete the TCK work, spend several weeks working on Fit and Finish and then spend another several weeks voting. The voting period tends to take a long time because we start voting before there is community consensus that the code it good enough to be released. Even after that, we can still have to delay the release further due to last minute legal issues such as the Sun schema issue last time. This time I'd like split the process into a Development Phase and a Release Phase with a clear, voted upon, transition between the two. The Development Phase includes implementations of all features, improvements, and bug fixes, the TCK work, and the Fit and Finish. We stay in this phase until we have the software ready to be released to users. The end of this phase is signified by a vote to move the software to the release process. Specifically, a +1 vote would mean that you are comfortable with the features, improvements, performance, quality and the known bugs in the server, and if we were able to release the software that day, you would. After a super majority vote, we move to the release phase. Of course, we can't release until we review the software for legal issues, create the final bundles, and TCK test it on last time, and that is why we have a separate release phase. The Release Phase begins by cutting a branch and publishing a rc1 binary, and the development trunk switched to the next release. Then we start the legal review, and work with SNAPSHOT dependency projects such as TranQL and OpenEJB to create a joint final release. When we believe we have addressed all out standing issues, we create a new release candidate and vote for final release. One thing to note, is that at no time in this process should be be substantially changing the source code. The community has already decided that they are comfortable with the features, improvements, performance, quality and known bugs. Of course exceptions can be made, but they should be done with caution and only upon a successful vote. I know there are some minor points that could be picked at in this plan, but what do you think about it over all? -dain Matt Hogstrom [EMAIL PROTECTED]
Re: Drop Sun ORB
+1...the Sun ORB is deadlong live the Sun ORB. On Nov 8, 2006, at 4:24 PM, Dain Sundstrom wrote: I'm going to drop the Sun ORB from trunk (unless someone objects :)). We have voted to have Yoko in 1.2 and once we certify there is no reason to keep the Sun ORB configs around. Once we do this, we can add in JPA and other optional features that require 1.5 to compile. Of course the main G server will still be Java 1.4 vm compatible and Java5 vm will only be required for applications that require Java5. -dain Matt Hogstrom [EMAIL PROTECTED]
Re: Java5 now required to build
Sounds good. What parts of the server are specifically 1.5? I was only aware of OEJB. On Nov 8, 2006, at 8:00 PM, Dain Sundstrom wrote: Java5 is now required to build the server, but we are creating 1.4 byte code. I have verified the server still starts with 1.4. -dain Matt Hogstrom [EMAIL PROTECTED]
Re: Setting domain for tomcat MBeans [was Re: Geronimo jmx question]
On Nov 9, 2006, at 3:37 PM, Dain Sundstrom wrote: On Nov 9, 2006, at 11:44 AM, David Jencks wrote: On Nov 9, 2006, at 11:22 AM, Jeff Genender wrote: I don't think it is worth the risk to attempt this for 1.2. I agree this should be deferred until after 1.2 is out. -dain Matt Hogstrom [EMAIL PROTECTED]
[jira] Closed: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=all ] Matt Hogstrom closed DAYTRADER-22. -- Fix Version/s: 1.2 Resolution: Won't Fix Assignee: Matt Hogstrom I changed it to false. I would rather add a configuration property so people can explicitly turn this feature on and off. I don't like things buried in .xml files as they are a PITA to change. Also, many people don't use JMS so I'd prefer to the leave the defaults to what 80%+ of the people are interested in. Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Setting domain for tomcat MBeans [was Re: Geronimo jmx question]
--- Dain Sundstrom [EMAIL PROTECTED] wrote: Please don't put them in the same domain as the rest of the geronimo mbeans. This will cause many TCK tests to fail and may result in name collisions. There are no name collisions because tomcat MBeans use type=... in their names whereas Geronimo uses j2eeType= The only exception is kernel. Here are some examples: -|---|- MBeans | Geronimo |Tomcat -|---|- Host | j2eeType=Host | type=Host Valve| j2eeType=TomcatValve| type=Valve Manager, Realm, Resources| j2eeType=GBean |type=Manager... Connector| j2eeType=GBean | type=Conenctor WebModule| name=./car| name=/host/context Servlet | X | geronimo: I do not know enough to comment about tck. I have been using this modification for more than 2 weeks, and have not come across any issues so far. Thanks Anita Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=comments#action_12448789 ] Jérôme GODARD commented on GERONIMO-1585: - I modify the geronimo-security-1.1.1.jar file with the security.patch to use the /* to secure all pages of my JSF application, but I also want to let the login page (with the resources it used like jpg, css etc) be accessible by everybody (unauthentified). With Websphere 6, I use the J2EE role EveryBody to do that : Extract of my web.xml : security-constraint web-resource-collection web-resource-nameAllURI/web-resource-name descriptionRepresent all the application URI/description url-pattern/*/url-pattern /web-resource-collection auth-constraint description / role-nameUser/role-name role-nameAdmin/role-name role-nameSupport/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint security-constraint web-resource-collection web-resource-nameLogin/web-resource-name descriptionThe login page resource/description url-pattern/login/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint description / role-nameEveryBody/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint security-constraint display-nameConstraints PUBLIC/display-name web-resource-collection web-resource-nameTheme Resources/web-resource-name description / url-pattern/templates/*/url-pattern url-pattern/index.jsp/url-pattern url-pattern/jscookmenu/*/url-pattern url-pattern//url-pattern http-methodGET/http-method /web-resource-collection web-resource-collection web-resource-namePublic Area/web-resource-name descriptionallows acces under /public//description url-pattern/public/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint description / role-nameEveryBody/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint When I deploy it on geronimo, I use the following geronimo-web.xml file : security-realm-nameapp-dev-ldap-realm/security-realm-name sec:security sec:default-principal realm-name=app-dev-ldap-realm sec:principal name=anonymous class=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal / /sec:default-principal sec:role-mappings sec:role role-name=User sec:realm realm-name=app-dev-ldap-realm sec:principal name=GP-ZONE3-AXE-USER class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal designated-run-as=true / /sec:realm sec:realm realm-name=app-dev-ldap-realm sec:principal name=GP-ZONE3-AXE-MANAGER class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal / /sec:realm /sec:role sec:role role-name=Support sec:realm realm-name=app-dev-ldap-realm sec:principal name=GP-ZONE3-AXE-MANAGER class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal / /sec:realm /sec:role sec:role role-name=Admin sec:realm realm-name=app-dev-ldap-realm sec:principal name=GP-ZONE3-AXE-MANAGER class=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal / /sec:realm /sec:role sec:role role-name=EveryBody sec:realm
Build failed, looking for maven-jaxb2-plugin
A clean build of trunk (with mvn 2.0.4) is failing for me when building the XMPP module, trying to download the maven-jaxb2-plugin: https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/maven-jaxb2-plugin-0.1.pom The funny thing is that I can view the pom file through a web browser, so I'm not sure what is giving Maven heartburn. I've had my Maven proxy settings set up for a while, so I'm confident that's not it. A listing of the directory https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/ fails - I guess they have directory listing disabled on the server. Is anyone else having this problem ... And does anyone know how I can get past it? Thanks, Nate
[jira] Closed: (AMQ-630) After broker has shutdown, cannot shutdown a client application
[ https://issues.apache.org/activemq/browse/AMQ-630?page=all ] Kieran Murphy closed AMQ-630. - Resolution: Fixed This is fixed, but the client using the failover protocol must be configured with the maxReconnectAttempts argument set. If maxReconnectAttempts is not set, then the client tries forever to reconnect and this seems to block the client's shutdown. As long as maxReconnectAttempts value is non-zero, then the client will be able to shutdown when no brokers are online. After broker has shutdown, cannot shutdown a client application --- Key: AMQ-630 URL: https://issues.apache.org/activemq/browse/AMQ-630 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 M4 Reporter: Kieran Murphy Assigned To: Hiram Chirino Fix For: 4.1 1. Bring up a broker 2. Bring up a client application which connects to the broker 3. Stop the broker. 4. Now try to stop the client app -- it will not shutdown until the broker is restarted. Using failover:tcp to connect to broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Build failed, looking for maven-jaxb2-plugin
Nate, I've been having the same trouble as you: https://issues.apache.org/activemq/browse/AMQ-1017. I have far less experience with Maven, though. I can get through most of the build but I get stuck there with the same error. I'm not sure what I'd actually need to do to get my local Maven repository configured manually to get past this, or if that's possible. Regards, Michael -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 8:25 AM To: activemq-dev@geronimo.apache.org Subject: Build failed, looking for maven-jaxb2-plugin A clean build of trunk (with mvn 2.0.4) is failing for me when building the XMPP module, trying to download the maven-jaxb2-plugin: https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/maven-jaxb2-plugin-0.1.pom The funny thing is that I can view the pom file through a web browser, so I'm not sure what is giving Maven heartburn. I've had my Maven proxy settings set up for a while, so I'm confident that's not it. A listing of the directory https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/ fails - I guess they have directory listing disabled on the server. Is anyone else having this problem ... And does anyone know how I can get past it? Thanks, Nate The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
[jira] Created: (GERONIMO-2559) cannot stop activemq via kernel shutdown
cannot stop activemq via kernel shutdown Key: GERONIMO-2559 URL: http://issues.apache.org/jira/browse/GERONIMO-2559 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: sun j2se 1.5.0_07 Reporter: Paul McMahan Fix For: 1.2 Shutdown the server from the admin console. This ends up invoking kernel.shutdown(). The following stack trace is generated: 11:59:25,265 ERROR [JournalPersistenceAdapter] Could not stop service: org.apach [EMAIL PROTECTED] Reason: java.lang.Nul lPointerException java.lang.NullPointerException at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator.handleReleased(ConnectionTrackingCoordinator.java:127) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:97) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT racker$$EnhancerByCGLIB$$c20afa50.handleReleased(generated) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor. returnConnection(ConnectionTrackingInterceptor.java:81) at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListene r.connectionClosed(GeronimoConnectionEventListener.java:67) at org.tranql.connector.AbstractManagedConnection.connectionClosed(Abstr actManagedConnection.java:102) at org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.jav a:97) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultData baseLocker.java:81) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersis tenceAdapter.java:202) at org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(Jour nalPersistenceAdapter.java:254) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) at org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerService GBeanImpl.java:107) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean Instance.java:1146) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop( GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown Hook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi cKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav a:645) at org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView (ServerManagerPortlet.java:72) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218 ) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
[jira] Commented: (AMQ-465) deadlock when using VM transport and Jencks...
[ https://issues.apache.org/activemq/browse/AMQ-465?page=comments#action_37412 ] Hiram Chirino commented on AMQ-465: --- This was fixed in rev 386335. deadlock when using VM transport and Jencks... -- Key: AMQ-465 URL: https://issues.apache.org/activemq/browse/AMQ-465 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0 M4 Reporter: james strachan Assigned To: Hiram Chirino Fix For: 4.0 RC2 Background here: http://forums.logicblaze.com/posts/list/146.page It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can't build trunk for an java.io.InvalidClassException
I'm worried that we didn't fix all the backward compatibility issues adding priority into GBeanData and GBeanInfo. I wonder if you are doing an online build and somehow pulling down out of date config snapshots with old-style serialized GBeanInfos. I'll try to figure this out... but I could probably use some help from gianny or dblevins. Meanwhile doing an offline build or cleaning the geronimo artifacts out of your m2 repo may help. thanks david jencks On Nov 9, 2006, at 7:03 PM, Jian Liao wrote: I am trying to build geronimo trunk with command mvn clean install -U -up, but encountered the following exception while building Building Geronimo Configs :: Jetty Deployer. Could someone help me? thanks, - Jian Liao [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Unable to create configuration for deployment org.apache.geronimo.gbean.GBeanInfo; local class incompatible: stream classdesc serialVersionUID = -619880406710221, local class serialVersionUID = 10536550 34244747613 [INFO] -- -- [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to create configu ration for deployment at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java :475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures( DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 115) at org.apache.maven.cli.MavenCli.main (MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch (Launcher.java: 255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException : Unable to create conf iguration for deployment at org.apache.geronimo.genesis.MojoSupport.execute (MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException : Unable to create conf iguration for deployment at org.apache.geronimo.deployment.DeploymentContext.createTempConfigurat ion(DeploymentContext.java:121) at org.apache.geronimo.deployment.DeploymentContext .init (DeploymentCon text.java:101) at org.apache.geronimo.deployment.DeploymentContext.init (DeploymentCon text.java:81) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf iguration(ServiceConfigBuilder.java:206) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf iguration(ServiceConfigBuilder.java:178) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClas sByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java :38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java :97) at org.apache.geronimo.deployment.ConfigurationBuilder$ $EnhancerByCGLIB$ $a917e681.buildConfiguration(generated) at
[jira] Commented: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=comments#action_12448808 ] Piyush Agarwal commented on DAYTRADER-22: - I will investigate to make this a configuration property so that it can be changed in an easier user-friendly fashion. Once I have something I will go ahead and re-open the issue Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Cannot preserved order in durable subscriber
Hi all, Does active MQ support to preserve order in durable topic? Eg. I have a durable subscriber which was disconnected when the message is published as 1,2,3,4,5. When the subscriber consumes the messages later, the sequence become 1,3,5,2,5 etc... Does any one knows how to preserve the order?? Thank you very much! -- View this message in context: http://www.nabble.com/Cannot-preserved-order-in-durable-subscriber-tf2609320.html#a7281867 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
servicemix-common and deployers
hi all, i've been using servicemix-common which makes the process of getting a fully fledged component done much easier. i do have a query / suggestion regarding the way deployers are handled. currently, if a baseserviceunitmanager is marked as having persistent service units the deploy method will be called on each Deployer the first time the service unit is deployed and then not again. Also, it is assumed that the endpoint will be registered on deploy. the situation i have in terms of lifecycle is closer to the spec, in terms of: i'd like to have deploy called only once and then init called each time the service unit is initialised. i'd also like to register the endpoints/serviceunit in the init method rather than the deploy. the reasoning is as follows: - the data in the service unit is persistent - the first time it's deployed i'd like to load the data in a database (or update it) - each time it's initialised, i'd like to register the serviceunit/endpoints but _not_ reload the data into the database. so, where i am now is that i'd like to carry on using baseserviceunitmanager without mangling it too much in a subclass. so the query is, am i on the right track? the suggestion is, is there a way to extend servicemix-common to support the lifecycle i've described above? cheers, j.
Re: Cannot preserved order in durable subscriber
I just used the default conf for ActiveMQ.I use the same program to put into Queue and there is no message ordering problem. It's only when I use Durable Topic when this problem occur. andrewlai wrote: Yes same VM instance using same connection object James.Strachan wrote: Did the same producer send all 5 messages? On 11/10/06, andrewlai [EMAIL PROTECTED] wrote: Hi all, Does active MQ support to preserve order in durable topic? Eg. I have a durable subscriber which was disconnected when the message is published as 1,2,3,4,5. When the subscriber consumes the messages later, the sequence become 1,3,5,2,5 etc... Does any one knows how to preserve the order?? Thank you very much! -- View this message in context: http://www.nabble.com/Cannot-preserved-order-in-durable-subscriber-tf2609320.html#a7281867 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Cannot-preserved-order-in-durable-subscriber-tf2609320.html#a7282893 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Cannot preserved order in durable subscriber
BTW I am running on 4.0.1, if it matters. Thanks a lot andrewlai wrote: I just used the default conf for ActiveMQ.I use the same program to put into Queue and there is no message ordering problem. It's only when I use Durable Topic when this problem occur. andrewlai wrote: Yes same VM instance using same connection object James.Strachan wrote: Did the same producer send all 5 messages? On 11/10/06, andrewlai [EMAIL PROTECTED] wrote: Hi all, Does active MQ support to preserve order in durable topic? Eg. I have a durable subscriber which was disconnected when the message is published as 1,2,3,4,5. When the subscriber consumes the messages later, the sequence become 1,3,5,2,5 etc... Does any one knows how to preserve the order?? Thank you very much! -- View this message in context: http://www.nabble.com/Cannot-preserved-order-in-durable-subscriber-tf2609320.html#a7281867 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Cannot-preserved-order-in-durable-subscriber-tf2609320.html#a7282908 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [jira] Created: (GERONIMO-2559) cannot stop activemq via kernel shutdown
This is the same issue as http://issues.apache.org/jira/browse/GERONIMO-2502 and http://issues.apache.org/jira/browse/GERONIMO-2400 I have looked using Jconsole, there is no thread called Thread-6. Thanks Anita --- Paul McMahan (JIRA) [EMAIL PROTECTED] wrote: cannot stop activemq via kernel shutdown Key: GERONIMO-2559 URL: http://issues.apache.org/jira/browse/GERONIMO-2559 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: sun j2se 1.5.0_07 Reporter: Paul McMahan Fix For: 1.2 Shutdown the server from the admin console. This ends up invoking kernel.shutdown(). The following stack trace is generated: 11:59:25,265 ERROR [JournalPersistenceAdapter] Could not stop service: org.apach [EMAIL PROTECTED] Reason: java.lang.Nul lPointerException java.lang.NullPointerException at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator.handleReleased(ConnectionTrackingCoordinator.java:127) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:97) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT racker$$EnhancerByCGLIB$$c20afa50.handleReleased(generated) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor. returnConnection(ConnectionTrackingInterceptor.java:81) at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListene r.connectionClosed(GeronimoConnectionEventListener.java:67) at org.tranql.connector.AbstractManagedConnection.connectionClosed(Abstr actManagedConnection.java:102) at org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.jav a:97) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultData baseLocker.java:81) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersis tenceAdapter.java:202) at org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(Jour nalPersistenceAdapter.java:254) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) at org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerService GBeanImpl.java:107) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean Instance.java:1146) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop( GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown Hook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi cKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav a:645) at org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView (ServerManagerPortlet.java:72) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at
Re: [jira] Created: (GERONIMO-2559) cannot stop activemq via kernel shutdown
Thanks Anita I added a dup link. Paul On 11/10/06, anita kulshreshtha [EMAIL PROTECTED] wrote: This is the same issue as http://issues.apache.org/jira/browse/GERONIMO-2502 and http://issues.apache.org/jira/browse/GERONIMO-2400 I have looked using Jconsole, there is no thread called Thread-6. Thanks Anita --- Paul McMahan (JIRA) [EMAIL PROTECTED] wrote: cannot stop activemq via kernel shutdown Key: GERONIMO-2559 URL: http://issues.apache.org/jira/browse/GERONIMO-2559 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: sun j2se 1.5.0_07 Reporter: Paul McMahan Fix For: 1.2 Shutdown the server from the admin console. This ends up invoking kernel.shutdown(). The following stack trace is generated: 11:59:25,265 ERROR [JournalPersistenceAdapter] Could not stop service: org.apach [EMAIL PROTECTED] Reason: java.lang.Nul lPointerException java.lang.NullPointerException at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator.handleReleased(ConnectionTrackingCoordinator.java:127) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:97) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT racker$$EnhancerByCGLIB$$c20afa50.handleReleased(generated) at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor. returnConnection(ConnectionTrackingInterceptor.java:81) at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListene r.connectionClosed(GeronimoConnectionEventListener.java:67) at org.tranql.connector.AbstractManagedConnection.connectionClosed(Abstr actManagedConnection.java:102) at org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.jav a:97) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultData baseLocker.java:81) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersis tenceAdapter.java:202) at org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(Jour nalPersistenceAdapter.java:254) at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) at org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerService GBeanImpl.java:107) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean Instance.java:1146) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop( GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan ceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja va:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja va:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown Hook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi cKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav a:645) at org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView (ServerManagerPortlet.java:72) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at
[jira] Commented: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=comments#action_12448828 ] Matt Hogstrom commented on DAYTRADER-22: Thanks Piyush...I should add that it was confusing about what a particular runtime mode was actually composed of. There is JDBC mode, EJB mode, long run, no long run, JMS pulishing or not, etc. I think as we noodle on this we should probably add a Runtime Settings: that would allow people to get a summary of the modes in effect. Thanks for thinking about this. Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1358) Switch database config file looking to geronimo.apache.org
[ http://issues.apache.org/jira/browse/GERONIMO-1358?page=all ] Paul McMahan reassigned GERONIMO-1358: -- Assignee: Paul McMahan Switch database config file looking to geronimo.apache.org -- Key: GERONIMO-1358 URL: http://issues.apache.org/jira/browse/GERONIMO-1358 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Paul McMahan Fix For: 1.2 Currently the database file is looked up at people.apache.org/~ammulder and this ought to go to geronimo.apache.org instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=comments#action_12448841 ] Piyush Agarwal commented on DAYTRADER-22: - That sounds like a good idea, what do you have in mind, where exactly are you thinking of having the Runtime Settings section? I was thinking we can re-arrange the related settings together on the config page, also possibly have a better explanation on these in some kind of documentation. Currently when you do Reset the runtime summary gets printed out, but its not complete wrt to the settings you mentioned above. Continuing on the issue at hand, I looked at the code and it seems the publishQuotePriceChange flag in ejb-jar.xml has no effect if you are running in Direct Mode as TradeDirect has this value set to True and it doesnt look it up from any of the config xmls neither it is exposed in TradeConfig. Only during EJB mode the TradeBean.java looks it from ejb-jar.xml. So in direct mode we have the MDBs running no matter what. I think we need to fix this so the flag is effective in both the Direct and EJB runtime modes. I am proposing exposing it through the configuration panel, so that user can set its value. The TradeConfigServlet will update the value in TradeConfig. Both Direct and EJB modes during init will check the value from TradeConfig and act accordingly. Once this is done we can remove the flag from the ejb-jar.xml Suggestions/Comments ? Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1042) The JMSConsumerTest interminitently failed on linux systems.
The JMSConsumerTest interminitently failed on linux systems. Key: AMQ-1042 URL: https://issues.apache.org/activemq/browse/AMQ-1042 Project: ActiveMQ Issue Type: Bug Components: CMS (C++ client) Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1, 4.2 JMSConsumerTest fails on linux sometimes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1358) Switch database config file looking to geronimo.apache.org
[ http://issues.apache.org/jira/browse/GERONIMO-1358?page=all ] Paul McMahan resolved GERONIMO-1358. Resolution: Fixed Switch database config file looking to geronimo.apache.org -- Key: GERONIMO-1358 URL: http://issues.apache.org/jira/browse/GERONIMO-1358 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Paul McMahan Fix For: 1.2 Currently the database file is looked up at people.apache.org/~ammulder and this ought to go to geronimo.apache.org instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2110) web access log viewer cannot display in tomcat assembly
[ http://issues.apache.org/jira/browse/GERONIMO-2110?page=all ] Paul McMahan closed GERONIMO-2110. -- web access log viewer cannot display in tomcat assembly --- Key: GERONIMO-2110 URL: http://issues.apache.org/jira/browse/GERONIMO-2110 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat, console Affects Versions: 1.1 Environment: tomcat assembly Reporter: Paul McMahan Assigned To: Paul McMahan a problem with the web access log portlet in the release candidate was reported on the user list. Turns out this results from the change in rev 407883 which disables the access logs in the tomcat assembly. Some issues with the current configuration are: -- the web access log viewer in the console cannot display -- the jetty assembly has access logs enabled by default (an inconsistency) -- the instructions in var/config/config.xml for reenabling access logs are incorrect (it says to change load=false to load=true but you actually need to delete the entire section added in r407883) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-2110) web access log viewer cannot display in tomcat assembly
[ http://issues.apache.org/jira/browse/GERONIMO-2110?page=all ] Paul McMahan resolved GERONIMO-2110. Resolution: Fixed Assignee: Paul McMahan fixed in revision 471784 web access log viewer cannot display in tomcat assembly --- Key: GERONIMO-2110 URL: http://issues.apache.org/jira/browse/GERONIMO-2110 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat, console Affects Versions: 1.1 Environment: tomcat assembly Reporter: Paul McMahan Assigned To: Paul McMahan a problem with the web access log portlet in the release candidate was reported on the user list. Turns out this results from the change in rev 407883 which disables the access logs in the tomcat assembly. Some issues with the current configuration are: -- the web access log viewer in the console cannot display -- the jetty assembly has access logs enabled by default (an inconsistency) -- the instructions in var/config/config.xml for reenabling access logs are incorrect (it says to change load=false to load=true but you actually need to delete the entire section added in r407883) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-739) wsdl for pojos exported by jsr181 endpoint is missing complextypes from other namespaces than the service itself
[ https://issues.apache.org/activemq/browse/SM-739?page=all ]
Christian Schneider updated SM-739:
---
Attachment: complextypetestpatch.txt
I have written and attached a Testcase for the problem.
wsdl for pojos exported by jsr181 endpoint is missing complextypes from other
namespaces than the service itself
Key: SM-739
URL: https://issues.apache.org/activemq/browse/SM-739
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0
Reporter: Christian Schneider
Attachments: complextypetestpatch.txt, jsr181wsdlproblem..zip
I am exporting a pojo Service in namespace http://test1 that uses a Class
from namespace http://test2 as a jsr181 endpoint.
The wsdl I get from jconsole for the endpoint does not include the definition
of the Complextype Person from http://test2.
If you put the Person class in the package test1 the wsdl looks fine. The
problem does not happen when using xfire without servicemix.
Thanks to Ken Berthelot for reporting the problem on the mailing list.
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/200611.mbox/browser
---
My xbean.xml
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://xbean.org/schemas/spring/1.0;
xmlns:jsr181=http://servicemix.apache.org/jsr181/1.0;
classpath
location./location
/classpath
jsr181:endpoint
pojoClass=test1.PersonServiceImpl
serviceInterface=test1.PersonService
style=wrapped
/jsr181:endpoint
/beans
---
My Classes
package test1;
import test2.Person;
public interface PersonService {
public abstract void testPerson(Person person);
}
package test1;
import test2.Person;
public class PersonServiceImpl implements PersonService {
/* (non-Javadoc)
* @see test1.PersonService#testPerson(test2.Person)
*/
public void testPerson(Person person) {
}
}
package test2;
public class Person {
String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
The wsdl
?xml version=1.0 encoding=UTF-8?wsdl:definitions
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:ns1=http://test2;
xmlns:soap11=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:soap12=http://www.w3.org/2003/05/soap-envelope;
xmlns:soapenc11=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:soapenc12=http://www.w3.org/2003/05/soap-encoding;
xmlns:tns=http://test1;
xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema; targetNamespace=http://test1;
wsdl:types
xsd:schema attributeFormDefault=qualified
elementFormDefault=qualified targetNamespace=http://test1;
xsd:element name=testPerson
xsd:complexType
xsd:sequence
xsd:element maxOccurs=1 minOccurs=1 name=in0 nillable=true
type=ns1:Person/
/xsd:sequence
/xsd:complexType
/xsd:element
xsd:element name=testPersonResponse
xsd:complexType/
/xsd:element
/xsd:schema
/wsdl:types
wsdl:message name=testPersonResponse
wsdl:part element=tns:testPersonResponse name=parameters/
/wsdl:message
wsdl:message name=testPersonRequest
wsdl:part element=tns:testPerson name=parameters/
/wsdl:message
wsdl:portType name=PersonServicePortType
wsdl:operation name=testPerson
wsdl:input message=tns:testPersonRequest name=testPersonRequest/
wsdl:output message=tns:testPersonResponse
name=testPersonResponse/
/wsdl:operation
/wsdl:portType
/wsdl:definitions
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Can't build trunk for an java.io.InvalidClassException
Thanks for all your response.I have worked around this issue by check out a fresh trunk and setup an empty maven repository, then build it successfully.I still keep the old environment and I can test again if someone fix this problem. thanks,- Jian LiaoOn 11/11/06, Gianny Damour [EMAIL PROTECTED] wrote: Hi,I had a look and it seems that the backward compatibility was onlypartially fixed; my bad: basically, GBeanData is backward compatible however it references GBeanInfo which is not. I will fix this problem.Thanks,GiannyOn 11/11/2006, at 4:38 AM, David Jencks wrote: I'm worried that we didn't fix all the backward compatibility issues adding priority into GBeanData and GBeanInfo.I wonder if you are doing an online build and somehow pulling down out of date config snapshots with old-style serialized GBeanInfos. I'll try to figure this out... but I could probably use some help from gianny or dblevins. Meanwhile doing an offline build or cleaning the geronimo artifacts out of your m2 repo may help. thanks david jencks On Nov 9, 2006, at 7:03 PM, Jian Liao wrote: I am trying to build geronimo trunk with command mvn clean install -U -up, but encountered the following exception while building Building Geronimo Configs :: Jetty Deployer. Could someone help me? thanks, - Jian Liao [INFO] - --- [ERROR] BUILD ERROR [INFO] - --- [INFO] Unable to create configuration for deployment org.apache.geronimo.gbean.GBeanInfo; local class incompatible: stream classdesc serialVersionUID = -619880406710221, local class serialVersionUID = 10536550 34244747613 [INFO] - --- [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException : Unable to create configu ration for deployment at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java :475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures( DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java: 115) at org.apache.maven.cli.MavenCli.main (MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch (Launcher.java: 255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java :375) Caused by: org.apache.maven.plugin.MojoExecutionException : Unable to create conf iguration for deployment at org.apache.geronimo.genesis.MojoSupport.execute (MojoSupport.java:137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException : Unable to create conf iguration for deployment at org.apache.geronimo.deployment.DeploymentContext.createTempConfigurat ion(DeploymentContext.java:121) at org.apache.geronimo.deployment.DeploymentContext .init (DeploymentCon text.java:101) at org.apache.geronimo.deployment.DeploymentContext.init (DeploymentCon text.java:81) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf iguration(ServiceConfigBuilder.java:206) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConf iguration(ServiceConfigBuilder.java:178) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClas sByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java :38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at
Logging problems
The log file only contains environment info. No other information is being written. Thanks Anita Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
