[jira] Commented: (SM-1088) CXFbc provider should provider a targetURI element
[ https://issues.apache.org/activemq/browse/SM-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40342 ] Freeman Fang commented on SM-1088: -- we provide locationURI as provider's attribute something like cxfbc:provider wsdl=/wsdl/calculator.wsdl locationURI=http://localhost:9001/providertest; endpoint=CalculatorPort service=calculator:CalculatorService interfaceName=calculator:CalculatorPortType CXFbc provider should provider a targetURI element -- Key: SM-1088 URL: https://issues.apache.org/activemq/browse/SM-1088 Project: ServiceMix Issue Type: Improvement Components: servicemix-cxf-bc Affects Versions: 3.2 Environment: Windows XP, Servicemix 3.2 Reporter: Ryan Moquin Assignee: Freeman Fang Priority: Minor Fix For: 3.2 Even though I didn't get the cxfbc provider to work, I did notice in the XSD there doesn't appear to be an option to specify a target URI, wsdl, or useJBIWrapper. I mentioned this in the bug report to create an example, but I figured I'd open a separate issue for clarity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1088) CXFbc provider should provider a targetURI element
[ https://issues.apache.org/activemq/browse/SM-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved SM-1088. -- Resolution: Fixed Fix Version/s: 3.2 CXFbc provider should provider a targetURI element -- Key: SM-1088 URL: https://issues.apache.org/activemq/browse/SM-1088 Project: ServiceMix Issue Type: Improvement Components: servicemix-cxf-bc Affects Versions: 3.2 Environment: Windows XP, Servicemix 3.2 Reporter: Ryan Moquin Assignee: Freeman Fang Priority: Minor Fix For: 3.2 Even though I didn't get the cxfbc provider to work, I did notice in the XSD there doesn't appear to be an option to specify a target URI, wsdl, or useJBIWrapper. I mentioned this in the bug report to create an example, but I figured I'd open a separate issue for clarity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
October board report
The report has to be submitted asap. I've written it at http://cwiki.apache.org/confluence/display/SM/2007-10-17. Please review and add anything missing asap. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) Am pondering if we should have a simple POJO based discovery/heartbeat mechanism thats transport agnostic so we could use multicast, jmdns, ActiveMQ, HTTP etc. Was pondering about making something really simple in Camel/SMX4 and we take it from there etc. e.g. for a heartbeat we really just wanna do a timed send of a status message to some endpoint. This could be JMS or a POST to some URI (or even an AtomPub entry we POST). Then the server side of this thing, keeps a RAM cache of all these things and times the entires out after a while so they disappear. (Doesn't need any persistence or replication really; as if the server side fails, another one can start somewhere and after a few heartbeats its back in sync again). Then the server side - lets call it a registry (but a simple registry); can just expose these heartbeats as data in different queries. So folks can query using some mechanism for nodes of a certain type or whatnot. Let's rephrase to check there is no misunderstanding. The purpose here is to have a discovery mechanism which is somewhat independant of the protocol. So there is one server and multiple clients, each client sending its own information to the server that keeps track of them. This implies, that either * there is a single point of failure for the master which is statically configured * the client elect a master amongst themselves Yeah. I guess the two common approaches would be; * use a web server as the server via a URL (which you can have some kinda DNS/IP load balancer to deal with the master failing - though we really don't want to load balance across the master and slaves; all traffic should go to the master server at all times). On failover from master to slave it would just look like all the services died and came back again shortly afterwards. * use a JMS topic - so the 'server' is in RAM in each client (e.g. a List of the non-expired heartbeat POJOs) The latter is probably much easier to do; the former has the benefit of being able to be RESTful and so work across languages and corporate boundaries etc You could always add a RESTful facade ontop of the latter too - which would support load balancing and failover :) Once the master / registry has been identified, the client send heatbeats to it and can query it for services. I'm not sure if a push or pull model is better here: having the master send new information to the clients, or have the clients polling for new informations or simply looking up the service on demand. Yeah. I can see both being useful in different circumstances The problem with the pull approach is that we won't be able to expose remote services in the OSGi registry without hacking the registry itself. For this particular use case, it would be better to be notified of new services (or subscribing somehow) so that a client can register a new remote service in the OSGi registry, which would be available through a proxy. Yeah This heartbeat/discovery thing is pretty generic stuff really; it'd be nice if the message/data could be anything at all then we can reuse the same thing in many circumstances. e.g. we could use this to discover AMQ brokers; or CXF services of a kind of WSDL or SMX instances or OSGi containers or whatnot. +1 The blob of data that is heartbeated; and what kinds of queries on the data we need to make is kinda speciifc to different problems. e.g. in AMQ we mostly just need to get the URL to connect to the broker. We may want to include some kinda network-hop type info so we try to connect to the nearest node or something - but generally a URL is enough in AMQ-land for discovery. For SMX containers, we might as well just expose the URL to talk to it. For distributed OSGi stuff we might wanna use more complex data for the heartbeat data; so folks could search (rather like the NMR does) by service QName, interface name, endpoint name or whatever. From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible.
Re: ServiceMix 4 as a distributed OSGi spring container....
Interesting discussion :) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) [big snip] From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible. Yeah; am thinking we could do content based routing or message translator stuff to format the POJO of the heartbeat data into different formats, sending it to different locations etc As an experiment in implementing a POJO based heartbeat mechanism thats protocol and data format independent (and can support the easy integration of EIP) I thought I'd try write a little test case in Camel. It turned out to be surprisingly easy :) from(bean:myService?methodName=status).to(mock:result); where the status() method is invoked periodically on the myService bean and then sent to the registry endpoint (a mock in this case as its a test case, but this could be activemq:topic:foo.bar etc) Here's the test case if you're interested... https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/BeanMethodHeartbeatTest.java -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: ServiceMix 4 as a distributed OSGi spring container....
I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: Interesting discussion :) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: Bringing this thread to dev list On 10/11/07, James Strachan [EMAIL PROTECTED] wrote: We need to find a way to discover other ServiceMix instances (through ActiveMQ ? any other idea ?) [big snip] From a low level I was wondering about a Camel factory bean in spring camel:heartbeat bean=someBeanRef property=myStatusEventObject millis=2000 uri=http://someServer.com/cheese/ This would call someBeanRef.getMyStatusEventObject() every 2 seconds and send the POJO to the endpoint URI. We could maybe wrap up this using some route? e.g. if the bean endpoint allowed for polling we could maybe do from(bean:someBeanRef?method=getMyStatusEventObjectperiod=2000).to(http://someServer.com/cheese;) though maybe a factory bean (XML element) is a bit easier - it does have better smart completion at least :) I like the idea of using camel to configure the discovery mechanism. This would be very flexible. Yeah; am thinking we could do content based routing or message translator stuff to format the POJO of the heartbeat data into different formats, sending it to different locations etc As an experiment in implementing a POJO based heartbeat mechanism thats protocol and data format independent (and can support the easy integration of EIP) I thought I'd try write a little test case in Camel. It turned out to be surprisingly easy :) from(bean:myService?methodName=status).to(mock:result); where the status() method is invoked periodically on the myService bean and then sent to the registry endpoint (a mock in this case as its a test case, but this could be activemq:topic:foo.bar etc) Here's the test case if you're interested... https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-core/src/test/java/org/apache/camel/processor/BeanMethodHeartbeatTest.java -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). Yeah; it does depend on how much data we're talking about. We could slice and dice the data using URLs. e.g. the full list of services available could be posted to some, say, Atom document on some shared server; this list can be updated incrementally or in total as and when services are added or removed. Then the heartbeat could just send around a URL to the detailed information. Or the list of services available could just be dynamically generated on demand if the container exposed a web front end. (push v pull) From a client perspective, it doesn't much care - the heartbeat message contains a URL to the detailed list of actual services provided if it wishes to get more information etc. -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: ServiceMix 4 as a distributed OSGi spring container....
BTW there's a simple example of how you could write a pure POJO registry without any dependency on any particular middleware or API and wire it together with services heartbeating with Camel here... https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-jms/src/test/java/org/apache/camel/component/jms/discovery/ (though it doesn't do the timeout of heartbeat messages - it was just a simple example to show how things could be wired together really) On 11/10/2007, James Strachan [EMAIL PROTECTED] wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). Yeah; it does depend on how much data we're talking about. We could slice and dice the data using URLs. e.g. the full list of services available could be posted to some, say, Atom document on some shared server; this list can be updated incrementally or in total as and when services are added or removed. Then the heartbeat could just send around a URL to the detailed information. Or the list of services available could just be dynamically generated on demand if the container exposed a web front end. (push v pull) From a client perspective, it doesn't much care - the heartbeat message contains a URL to the detailed list of actual services provided if it wishes to get more information etc. -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com -- James --- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com
Re: [jira] Reopened: (SM-624) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest
Guillaume My apology, it was my first attempt to contribute (i'll be more careful next time) I just realized that myself, so I'll retest all of them as well as play with the code to see if I can figure out why the are not stable. Thanks Oleg On 10/11/07, Guillaume Nodet (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Guillaume Nodet reopened SM-624: This jira issue deals with the MultipleJMSFlowTest, not the JMSFlowTest test. If you look at the core/servicemix-core pom, this test is still disabled, as are several other tests that seems to have timing issues mainly. These disabled tests are not very stable unfortunately, and they sometimes work, sometimes not. Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest --- Key: SM-624 URL: https://issues.apache.org/activemq/browse/SM-624 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Environment: Windows and linux Reporter: Fritz Oconer Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 10/11/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. Doesn't apacheds comes with a clustering / replication solution already ? Yes, it does, but I'm not sure of it's level of efficiency at all as I've not yet looked at it. I have spoken with Ersin Er who works on directory about doing directory replication via ActiveMQ, but we haven't done any work toward it yet. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Yeah. However, for performance reasons, it may be interesting to be able to only publish the delta in addition to provide an easy access to the whole data. Yeah, I really like that idea. It should cut down on traffic significantly. We could also expose the registry as a REST interface, but it may not be the most efficient way. Do we really need to expose the whole registry though? -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 10/11/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances What I am trying to get my head around, is if this configuration data can be abstracted up to the OSGi level or if it is specific to ServiceMix? I see the specific requirement for this data within ServiceMix itself, but with OSGi there is also the configuration admin service which is a standardized way to provide data to instances of services. I have been thinking about implementing a distributed version of these kinds of OSGi services for a long time so this could be another option. If nothing else, we could support a pluggable registry that could have different implementations depending on the deployment scenario. Just a thought. This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. Doesn't apacheds comes with a clustering / replication solution already ? Yes, and I can look into modifying this to use ActiveMQ to do the replication so that we can keep things consistent (current replication is direct TCP with Mina on each node). ApacheDS also allows replication without exposing the actual LDAP server... so it can be embedded and expose a direct JNDIContext without exposing a listener externally yet still achieve replication, which is a common use case for embedded users. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Yeah. However, for performance reasons, it may be interesting to be able to only publish the delta in addition to provide an easy access to the whole data. I think ApacheDS does this now, but I am sure that it could be optimized to fit our needs if it doesn't already. We could also expose the registry as a REST interface, but it may not be the most efficient way. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ I certainly think that ApacheDS could be of some use here, but I don't want to be pushy or biased ;-) There will certainly be some customizations for this use case, but ApacheDS is extensible via interceptors and other similar means. In addition, it might not be well known that ApacheDS is going to start moving to an OSGi container based deployment as well, so that might be useful too. I think these discussions are great and will help expose the requirements as we toss around these ideas and we can keep fine tuning the solution. Chris
[jira] Closed: (GERONIMO-3456) Make MEJB security configurable
[ https://issues.apache.org/jira/browse/GERONIMO-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha closed GERONIMO-3456. Resolution: Fixed Make MEJB security configurable --- Key: GERONIMO-3456 URL: https://issues.apache.org/jira/browse/GERONIMO-3456 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, security Affects Versions: 2.0.1, 2.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Priority: Critical Fix For: 2.0.2, 2.1 Attachments: configs.diff, configs.patch, configs.patch, GERONIMO-3456.patch, mejb-ear-2.1-SNAPSHOT.ear, mejb-ejb-2.1-SNAPSHOT.jar, mejb-war-2.1-SNAPSHOT.war, mejb.diff, MEJB.java, mejb.patch Currently access to MEJB is not controlled. Add configurable security for MEJB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-1102) The jbi maven plugin does not support jars packaged as bundles
The jbi maven plugin does not support jars packaged as bundles -- Key: SM-1102 URL: https://issues.apache.org/activemq/browse/SM-1102 Project: ServiceMix Issue Type: Bug Components: tooling Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-1102) The jbi maven plugin does not support jars packaged as bundles
[ https://issues.apache.org/activemq/browse/SM-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-1102. - Resolution: Fixed Sending tooling/jbi-maven-plugin/src/main/java/org/apache/servicemix/maven/plugin/jbi/GenerateComponentDescriptorMojo.java Sending tooling/jbi-maven-plugin/src/main/java/org/apache/servicemix/maven/plugin/jbi/GenerateComponentMojo.java Sending tooling/jbi-maven-plugin/src/main/java/org/apache/servicemix/maven/plugin/jbi/JbiComponentDescriptorWriter.java Transmitting file data ... Committed revision 583757. URL: http://svn.apache.org/viewvc?rev=583757view=rev The jbi maven plugin does not support jars packaged as bundles -- Key: SM-1102 URL: https://issues.apache.org/activemq/browse/SM-1102 Project: ServiceMix Issue Type: Bug Components: tooling Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3520) missing jsr-77 stats for JTA
[ https://issues.apache.org/jira/browse/GERONIMO-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534003 ] Anita Kulshreshtha commented on GERONIMO-3520: -- Viet, It might be possible to optimize the computation of ActiveCount by incrementing/decrementing a counter when ever the transactions are associated/disassociated instead of going through the Map every time. Could you please explain how/where the transactions are started in the attached application ear? missing jsr-77 stats for JTA Key: GERONIMO-3520 URL: https://issues.apache.org/jira/browse/GERONIMO-3520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring, transaction manager Affects Versions: 2.0.2, 2.1 Environment: linux Reporter: Viet Hung Nguyen Attachments: geronimo-3520.patch, jms-mdb-sample-ear-2.0-SNAPSHOT.ear, txmanagerStats.patch we need to surface transaction statistics defined by the JSR 77 spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Help! Exception while stopping geronimo using Journaled JDBC persistence
Hi, I am using Journaled JDBC for activemq persistence . I am using activemq 4.1 within geronimo 2.0.1 . I used VM connector for sending messages and I have externalized the activemq.xml in geronimo. I am getting the following exception when trying to stop the geronimo.It work fine if I use just JDBC persistence without journal. [] received stop signal XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams ERROR XBM02: XBM02.D : [0] org.apache.derby.iapi.services.stream.InfoStreams at org.apache.derby.iapi.error.StandardException.newException(Unknown So urce) at org.apache.derby.iapi.services.monitor.Monitor.missingImplementation( Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule (Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startModule (Unknow n Source) at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule (Unkn own Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState (Unkno wn Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Sou rce) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S ource) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.init(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.activemq.store.jdbc.TransactionContext.getConnection (Trans actionContext.java:55) at org.apache.activemq.store.jdbc.TransactionContext.begin (TransactionCo ntext.java:149) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransactio n(JDBCPersistenceAdapter.java:358) at org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTran saction(JournalPersistenceAdapter.java:189) at org.apache.activemq.util.TransactionTemplate.run (TransactionTemplate. java:41) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint (Jour nalMessageStore.java:247) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint (Jour nalMessageStore.java:221) at org.apache.activemq.store.journal.JournalPersistenceAdapter$4.call(Jo urnalPersistenceAdapter.java:356) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run (FutureT ask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) Got Exception in TransactionContext java.sql.SQLException: No suitable driver at java.sql.DriverManager.getDriver(DriverManager.java:243) at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown Source) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown Source ) at org.apache.activemq.store.jdbc.TransactionContext.getConnection (Trans actionContext.java:55) at org.apache.activemq.store.jdbc.TransactionContext.begin (TransactionCo ntext.java:149) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.beginTransactio n(JDBCPersistenceAdapter.java:358) at org.apache.activemq.store.journal.JournalPersistenceAdapter.beginTran saction(JournalPersistenceAdapter.java:189) at org.apache.activemq.util.TransactionTemplate.run (TransactionTemplate. java:41) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint (Jour nalMessageStore.java:247) at org.apache.activemq.store.journal.JournalMessageStore.checkpoint (Jour nalMessageStore.java:221) at org.apache.activemq.store.journal.JournalPersistenceAdapter$4.call(Jo urnalPersistenceAdapter.java:356) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run (FutureT ask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor ker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) 16:25:58,546 ERROR [JournalPersistenceAdapter] Failed to checkpoint a message st ore: edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lan g.NoClassDefFoundError: org/apache/activemq/util/IOExceptionSupport edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NoC lassDefFoundError: org/apache/activemq/util/IOExceptionSupport at
[jira] Resolved: (GERONIMO-3522) monitoring client needs ability to tell if snapshot thread is running, control proper stop/start of thread
[ https://issues.apache.org/jira/browse/GERONIMO-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig resolved GERONIMO-3522. - Resolution: Fixed Good after commit, Thanks anita =) monitoring client needs ability to tell if snapshot thread is running, control proper stop/start of thread -- Key: GERONIMO-3522 URL: https://issues.apache.org/jira/browse/GERONIMO-3522 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring Reporter: Viet Hung Nguyen Assignee: Erik B. Craig Attachments: GERONIMO-3522.patch the monitoring client needs to be able tell whether or not the snapshot thread is actually collecting any data, control stop/start of the thread -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Reopened: (SM-624) Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest
No big deal, and thx for investigating these issues. Bt, I've just disabled a new test which is unstable too (SubscritionTest). I've no clear idea what happens :-( On 10/11/07, Oleg Zhurakousky [EMAIL PROTECTED] wrote: Guillaume My apology, it was my first attempt to contribute (i'll be more careful next time) I just realized that myself, so I'll retest all of them as well as play with the code to see if I can figure out why the are not stable. Thanks Oleg On 10/11/07, Guillaume Nodet (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/activemq/browse/SM-624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Guillaume Nodet reopened SM-624: This jira issue deals with the MultipleJMSFlowTest, not the JMSFlowTest test. If you look at the core/servicemix-core pom, this test is still disabled, as are several other tests that seems to have timing issues mainly. These disabled tests are not very stable unfortunately, and they sometimes work, sometimes not. Failed unit test (servicemix-core) : org.apache.servicemix.jbi.nmr.flow.jms.MultipleJMSFlowTest --- Key: SM-624 URL: https://issues.apache.org/activemq/browse/SM-624 Project: ServiceMix Issue Type: Sub-task Components: servicemix-core Affects Versions: 3.0 Environment: Windows and linux Reporter: Fritz Oconer Fix For: 3.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Commented: (GERONIMO-3508) Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends
[ https://issues.apache.org/jira/browse/GERONIMO-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534032 ] Kevan Miller commented on GERONIMO-3508: I've never experienced this problem. My builds are always able to download the artifacts from the openejb-3rdparty-builds repo (aka http://svn.apache.org/repos/asf/openejb/repo/). It seems that in some situations, maven is associateing the r579367 version of xbean-naming with non-openejb dependencies. In these cases, the openejb-3rdparty-builds repo will not be searched -- it's evidently a maven-style, spooky crapshoot as to whether the openejb repo is searched... I've added exclusions to try and prevent downloading of the problematic xbean versions. I haven't been totally successful. At the moment, xbean-naming-3.2-r579367.jar is not being downloaded. So, seemingly Donald's problem is fixed. However, xbean-reflect-3.2-r579367.jar and commons-dbcp are still being downloaded. Possible that moving to a non-snapshot version (i.e. 2.0.2) may help... we'll see. Even when bad versions are downloaded, they aren't included in our binaries... Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends Key: GERONIMO-3508 URL: https://issues.apache.org/jira/browse/GERONIMO-3508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0.2 Reporter: Donald Woods Priority: Blocker Fix For: 2.0.2 Unless you build openejb-3.0-beta-1 first, you will not be able to build Geronimo 2.0.2 (client-corba-yoko config build fails), because of the private xbean revisioned jars that are referenced by the openejb POM. The private versions are located by their build by - repository idopenejb-3rdparty-builds/id name3rd Party Build Repository/name urlhttp://svn.apache.org/repos/asf/openejb/repo//url [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.xbean:xbean-naming:jar:3.2-r579367 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.xbean -DartifactId=xbean-nam ing \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.xbean -DartifactId=xbean-naming \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT 2) org.apache.geronimo.configs:openejb-corba-deployer:car:2.0.2-SNAPSHOT 3) org.apache.geronimo.configs:j2ee-deployer:car:2.0.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-client:jar:2.0.2-SNAPSHOT 5) org.apache.geronimo.modules:geronimo-naming:jar:2.0.2-SNAPSHOT 6) org.apache.xbean:xbean-naming:jar:3.2-r579367 -- 1 required artifact is missing. for artifact: org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-240) Bad, duplicate project name in org.apache.gernimo.v10.feature/.project file
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-240: --- Attachment: GD240.patch Bad, duplicate project name in org.apache.gernimo.v10.feature/.project file --- Key: GERONIMODEVTOOLS-240 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-240 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.2.1, 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x Reporter: Ted Kirby Attachments: GD240.patch The current project name is org.apache.geronimo.feature, which conflicts with org.apache.geronimo.feature/feature.xml. The name should be org.apache.gernimo.v10.feature. If you try to import existing feature projects into eclipse, you get an error on duplicate name, which this patch fixes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-240) Bad, duplicate project name in org.apache.gernimo.v10.feature/.project file
Bad, duplicate project name in org.apache.gernimo.v10.feature/.project file --- Key: GERONIMODEVTOOLS-240 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-240 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0, 1.2.0, 1.1.0, 1.0.0, 1.2.1, 2.0.2, 2.0.x, 2.1.0, 2.1.x Reporter: Ted Kirby The current project name is org.apache.geronimo.feature, which conflicts with org.apache.geronimo.feature/feature.xml. The name should be org.apache.gernimo.v10.feature. If you try to import existing feature projects into eclipse, you get an error on duplicate name, which this patch fixes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3520) missing jsr-77 stats for JTA
[ https://issues.apache.org/jira/browse/GERONIMO-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534037 ] Viet Hung Nguyen commented on GERONIMO-3520: Anita, I thought since the application was using JMS, each message sent would be a transaction. missing jsr-77 stats for JTA Key: GERONIMO-3520 URL: https://issues.apache.org/jira/browse/GERONIMO-3520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring, transaction manager Affects Versions: 2.0.2, 2.1 Environment: linux Reporter: Viet Hung Nguyen Attachments: geronimo-3520.patch, jms-mdb-sample-ear-2.0-SNAPSHOT.ear, txmanagerStats.patch we need to surface transaction statistics defined by the JSR 77 spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMO-3520) missing jsr-77 stats for JTA
[ https://issues.apache.org/jira/browse/GERONIMO-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534037 ] vhnguyen edited comment on GERONIMO-3520 at 10/11/07 6:35 AM: -- Anita, I thought since the application was using JMS, each message sent would be a transaction. The transaction call is actually in AMQ's code. was (Author: vhnguyen): Anita, I thought since the application was using JMS, each message sent would be a transaction. missing jsr-77 stats for JTA Key: GERONIMO-3520 URL: https://issues.apache.org/jira/browse/GERONIMO-3520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring, transaction manager Affects Versions: 2.0.2, 2.1 Environment: linux Reporter: Viet Hung Nguyen Attachments: geronimo-3520.patch, jms-mdb-sample-ear-2.0-SNAPSHOT.ear, txmanagerStats.patch we need to surface transaction statistics defined by the JSR 77 spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[GShell] Plexus dependency in CommandLineBuilder
I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: J2g - purpose of configurator?
Jason and Erik, Thanks for your feedback! I think Jason is correct, the script (j2g-configure) is the one that does the copying. I'll work on allowing the users to install j2g from our eclipse update site (which should perform similar things as what j2g-configure does). Removing the need to config config.ini file and the unnecessary java files in j2g\trunk\src\main\resources\compatibility\org.apache.geronimo.devtools.j2g.sources.dependence.compatibility will enable me to do that IMHO. Lin Jason Warner wrote: Erik, I was under the impression that the copying of the necessary jars was handle by the j2g-configure script itself. I don't think the configurator module is required for this script. It might be best, if the config.ini changes are unnecessary, to remove the configurator plugin component, and redo the script so that it only does the copying. Cheers, Jason Warner On 10/10/07, *Erik B. Craig* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Lin, I did some poking around with what it's actually doing now... It actually looks like this may not be necessary with eclipse 3.3. I am not 100% sure on this, because I have only touched j2g while using Eclipse 3.3 milestones and up, never with 3.2, but I think it may have been necessary to set some of the things that it is setting with Eclipse 3.2. At any rate, I think you are correct in that this is no longer required with what it's doing to the eclipse config.ini, however it is copying some of the dependencies (properties files) into the eclipse plugins directory, along with the actual plugins themselves, which this is most certainly a critical part of its functionality. Thanks, Erik Lin Sun wrote: Hi, I'd like to know a bit more as to why we need the configurator module in j2g. From our user doc, we ask our users to run the j2g-configure in the bin dir which at the end would call org.apache.geronimo.devtools.j2g.Configurator. Looks like what it does is to make a copy of existing eclipse_home\configuration\config.ini and add some config properties to the config.ini file. But I don't really understand why we need to modify the default config.ini file. I don't think our geronimo eclipse plugin modifies it either. It can be a prob when we want to enable a user to download j2g from an update site. I tried to run j2g with the default config.ini and able to run the jdes2g and jsrc2g fine. I haven't been able to find a sample that allows me to run jres2g yet, so if you know any let me know. Thanks, Lin
Re: J2g - purpose of configurator?
OOps, looks like this reply yesterday only went directly to Jason... Jason, Erm, yeah, you are correct, that stuff is in fact handled by the script itself, and not in the executed Configurator. -Erik Lin Sun wrote: Jason and Erik, Thanks for your feedback! I think Jason is correct, the script (j2g-configure) is the one that does the copying. I'll work on allowing the users to install j2g from our eclipse update site (which should perform similar things as what j2g-configure does). Removing the need to config config.ini file and the unnecessary java files in j2g\trunk\src\main\resources\compatibility\org.apache.geronimo.devtools.j2g.sources.dependence.compatibility will enable me to do that IMHO. Lin Jason Warner wrote: Erik, I was under the impression that the copying of the necessary jars was handle by the j2g-configure script itself. I don't think the configurator module is required for this script. It might be best, if the config.ini changes are unnecessary, to remove the configurator plugin component, and redo the script so that it only does the copying. Cheers, Jason Warner On 10/10/07, *Erik B. Craig* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Lin, I did some poking around with what it's actually doing now... It actually looks like this may not be necessary with eclipse 3.3. I am not 100% sure on this, because I have only touched j2g while using Eclipse 3.3 milestones and up, never with 3.2, but I think it may have been necessary to set some of the things that it is setting with Eclipse 3.2. At any rate, I think you are correct in that this is no longer required with what it's doing to the eclipse config.ini, however it is copying some of the dependencies (properties files) into the eclipse plugins directory, along with the actual plugins themselves, which this is most certainly a critical part of its functionality. Thanks, Erik Lin Sun wrote: Hi, I'd like to know a bit more as to why we need the configurator module in j2g. From our user doc, we ask our users to run the j2g-configure in the bin dir which at the end would call org.apache.geronimo.devtools.j2g.Configurator. Looks like what it does is to make a copy of existing eclipse_home\configuration\config.ini and add some config properties to the config.ini file. But I don't really understand why we need to modify the default config.ini file. I don't think our geronimo eclipse plugin modifies it either. It can be a prob when we want to enable a user to download j2g from an update site. I tried to run j2g with the default config.ini and able to run the jdes2g and jsrc2g fine. I haven't been able to find a sample that allows me to run jres2g yet, so if you know any let me know. Thanks, Lin
Re: [GShell] Plexus dependency in CommandLineBuilder
Yep, that's what i did. I just mistyped in my email ... I may also have to add constructors to a few classes (as done in other classes) where they are missing... On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (GERONIMO-3520) missing jsr-77 stats for JTA
[ https://issues.apache.org/jira/browse/GERONIMO-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3520: --- Attachment: (was: txmanagerStats.patch) missing jsr-77 stats for JTA Key: GERONIMO-3520 URL: https://issues.apache.org/jira/browse/GERONIMO-3520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring, transaction manager Affects Versions: 2.0.2, 2.1 Environment: linux Reporter: Viet Hung Nguyen Attachments: geronimo-3520.patch, jms-mdb-sample-ear-2.0-SNAPSHOT.ear, txmanagerStats.patch we need to surface transaction statistics defined by the JSR 77 spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GShell] Plexus dependency in CommandLineBuilder
Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (GERONIMO-3520) missing jsr-77 stats for JTA
[ https://issues.apache.org/jira/browse/GERONIMO-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Viet Hung Nguyen updated GERONIMO-3520: --- Attachment: txmanagerStats.patch Updated the patch to use AtomicLong for statistic counters to avoid having inaccurate values due to threading like Matt suggested. Also, keeps track of another attribute for activeCount and increments/decrements accordingly (i.e. when associate() and unassociate() are called) like Anita suggested. missing jsr-77 stats for JTA Key: GERONIMO-3520 URL: https://issues.apache.org/jira/browse/GERONIMO-3520 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: monitoring, transaction manager Affects Versions: 2.0.2, 2.1 Environment: linux Reporter: Viet Hung Nguyen Attachments: geronimo-3520.patch, jms-mdb-sample-ear-2.0-SNAPSHOT.ear, txmanagerStats.patch we need to surface transaction statistics defined by the JSR 77 spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build issue with trunk - build hangs
I'm consistently hitting a build hang with trunk that I can't get past.
Is anybody else hitting these problems or does anybody know what
might be going wrong? Perhaps I need to bump up the MaxPermSize?
The build hangs when I get to building the car-maven-plugin. This is on
OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first with
2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK 1.5.0_11.
My MAVEN_OPTS are set to:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
Here's the last thing I always see:
---
T E S T S
---
Running org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
Running org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [shitty:install {execution: default}]
[INFO] Installing
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
to
/home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-maven-plugin-2.1-SNAPSHOT.jar
[jira] Resolved: (GERONIMO-3508) Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends
[ https://issues.apache.org/jira/browse/GERONIMO-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-3508. Resolution: Fixed I just updated my build version from 2.0.2-SNAPSHOT to 2.0.2. And built from a clean repo. My build succeeded *and* the private builds of xbean and commons-dbcp were not downloaded. So, I think this issue is fixed... Donald, hoping you can verify? Still cannot build branches/2.0 without building OpenEJB first, due to XBean depends Key: GERONIMO-3508 URL: https://issues.apache.org/jira/browse/GERONIMO-3508 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0.2 Reporter: Donald Woods Priority: Blocker Fix For: 2.0.2 Unless you build openejb-3.0-beta-1 first, you will not be able to build Geronimo 2.0.2 (client-corba-yoko config build fails), because of the private xbean revisioned jars that are referenced by the openejb POM. The private versions are located by their build by - repository idopenejb-3rdparty-builds/id name3rd Party Build Repository/name urlhttp://svn.apache.org/repos/asf/openejb/repo//url [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.xbean:xbean-naming:jar:3.2-r579367 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.xbean -DartifactId=xbean-nam ing \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.xbean -DartifactId=xbean-naming \ -Dversion=3.2-r579367 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT 2) org.apache.geronimo.configs:openejb-corba-deployer:car:2.0.2-SNAPSHOT 3) org.apache.geronimo.configs:j2ee-deployer:car:2.0.2-SNAPSHOT 4) org.apache.geronimo.modules:geronimo-client:jar:2.0.2-SNAPSHOT 5) org.apache.geronimo.modules:geronimo-naming:jar:2.0.2-SNAPSHOT 6) org.apache.xbean:xbean-naming:jar:3.2-r579367 -- 1 required artifact is missing. for artifact: org.apache.geronimo.configs:client-corba-yoko:car:2.0.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), java.net (http://download.java.net/maven/1/), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Build issue with trunk - build hangs
I had to use the MaxPermSize of 256m on RedHat for this to work.
On Windows, my mavenrc_pre.bat had some settings that I had to remove.
Now it works fine with just 128M
Cheers
Prasad
On 10/11/07, Shiva Kumar H R [EMAIL PROTECTED] wrote:
I used a MaxPermSize of 256m and build worked fine for me on Windows.
On 10/11/07, Joe Bohn [EMAIL PROTECTED] wrote:
I'm consistently hitting a build hang with trunk that I can't get past.
Is anybody else hitting these problems or does anybody know what
might be going wrong? Perhaps I need to bump up the MaxPermSize?
The build hangs when I get to building the car-maven-plugin. This is on
OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first with
2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK 1.5.0_11.
My MAVEN_OPTS are set to:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
Here's the last thing I always see:
---
T E S T S
---
Running
org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
Running
org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [shitty:install {execution: default}]
[INFO] Installing
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-maven-plugin-2.1-SNAPSHOT.jar
to
/home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-
maven-plugin-2.1-SNAPSHOT.jar
--
Thanks,
Shiva
Come to ApacheCon US 2007 or OS Summit Asia 2007 and learn about
Java EE 5 App Development on Geronimo 2.0 simplified using Eclipse
http://us.apachecon.com/us2007/program/talk/2003
http://www.ossummit.com/2007/program/talk/16
Re: Build issue with trunk - build hangs
I used a MaxPermSize of 256m and build worked fine for me on Windows.
On 10/11/07, Joe Bohn [EMAIL PROTECTED] wrote:
I'm consistently hitting a build hang with trunk that I can't get past.
Is anybody else hitting these problems or does anybody know what
might be going wrong? Perhaps I need to bump up the MaxPermSize?
The build hangs when I get to building the car-maven-plugin. This is on
OpenSUSE 10.2 with maven 2.0.7 (although I had the failures first with
2.0.5 and moving to 2.0.7 didn't change the results) and Sun JDK 1.5.0_11.
My MAVEN_OPTS are set to:
-XX:MaxPermSize=128m -Xms512m -Xmx512m
Here's the last thing I always see:
---
T E S T S
---
Running org.apache.geronimo.mavenplugins.car.PlanProcessorMojoTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.6 sec
Running org.apache.geronimo.mavenplugins.car.PluginMetadataTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.691 sec
Results :
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-
maven-plugin-2.1-SNAPSHOT.jar
[INFO] [plugin:addPluginArtifactMetadata]
[INFO] [shitty:install {execution: default}]
[INFO] Installing
/home/jbohn/geronimo/maven-plugins/car-maven-plugin/target/car-
maven-plugin-2.1-SNAPSHOT.jar
to
/home/jbohn/.m2/repository/org/apache/geronimo/plugins/car-maven-plugin/2.1-SNAPSHOT/car-
maven-plugin-2.1-SNAPSHOT.jar
--
Thanks,
Shiva
Come to ApacheCon US 2007 or OS Summit Asia 2007 and learn about
Java EE 5 App Development on Geronimo 2.0 simplified using Eclipse
http://us.apachecon.com/us2007/program/talk/2003
http://www.ossummit.com/2007/program/talk/16
Re: svn commit: r583850 - in /geronimo/gbuild/daily_build_scripts: ./ gbuild.sh openejb.sh tck.sh testsuite.sh
On Oct 11, 2007, at 11:23 AM, [EMAIL PROTECTED] wrote: Author: prasad Date: Thu Oct 11 08:23:05 2007 New Revision: 583850 URL: http://svn.apache.org/viewvc?rev=583850view=rev Log: * checking in scripts that run daily build, run testsuite and tck smoketests Added: geronimo/gbuild/daily_build_scripts/ geronimo/gbuild/daily_build_scripts/gbuild.sh (with props) geronimo/gbuild/daily_build_scripts/openejb.sh (with props) geronimo/gbuild/daily_build_scripts/tck.sh (with props) geronimo/gbuild/daily_build_scripts/testsuite.sh (with props) Prasad, Can you please get some Apache source license headers on these scripts. I see that one of these scripts runs the TCK. It looks like it doesn't reveal any details of the TCK. So, I think that's fine. --kevan
[jira] Created: (GERONIMODEVTOOLS-241) J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming
J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming - Key: GERONIMODEVTOOLS-241 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.0.0 Reporter: Ted Kirby projects should be consistently named. Instructions for developing J2G in eclipse would be very good to have. I get these errors in eclipse: Errors during build. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.jasper'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.ui'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.util'. The builder launch configuration could not be found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-241) J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-241: --- Attachment: GD241.patch J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming - Key: GERONIMODEVTOOLS-241 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.0.0 Reporter: Ted Kirby Attachments: GD241.patch projects should be consistently named. Instructions for developing J2G in eclipse would be very good to have. I get these errors in eclipse: Errors during build. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.jasper'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.ui'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.util'. The builder launch configuration could not be found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-241) J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun reassigned GERONIMODEVTOOLS-241: Assignee: Lin Sun J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming - Key: GERONIMODEVTOOLS-241 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.0.0 Reporter: Ted Kirby Assignee: Lin Sun Attachments: GD241.patch projects should be consistently named. Instructions for developing J2G in eclipse would be very good to have. I get these errors in eclipse: Errors during build. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.jasper'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.ui'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.util'. The builder launch configuration could not be found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-241) J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534089 ] Lin Sun commented on GERONIMODEVTOOLS-241: -- Thanks Ted, I missed these few spots! Committed portions of the patch in rev 583881. I am working on removing the configurator module (see discussion on dev list), so I didn't commit the proposed change to that module. J2G projects should be renamed to reflect org.apache.geronimo.devtools.j2g naming - Key: GERONIMODEVTOOLS-241 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-241 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.0.0 Reporter: Ted Kirby Assignee: Lin Sun Attachments: GD241.patch projects should be consistently named. Instructions for developing J2G in eclipse would be very good to have. I get these errors in eclipse: Errors during build. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.jasper'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.ui'. The builder launch configuration could not be found. Errors running builder 'Integrated External Tool Builder' on project 'org.apache.geronimo.devtools.j2g.util'. The builder launch configuration could not be found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make useMavenDependencies default true ?
So in summary, do we keep the lists mutually exclusive ? Paul, do you still see a need for a merge/override option ? If so, I'll slowly deprecate the useMavenDependency option. Since almost all configs have now been converted to plugins, I think it is time we used the maven dependencies as default anyways. The presence of any dependencies in the c-m-p configuration will make the c-m-p use those deps only and exclude all maven deps. Cheers Prasad On 10/10/07, Paul McMahan [EMAIL PROTECTED] wrote: On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/import dependencies before could I inquire what use you found for it and how you avoided class cast exceptions? I looked into to using it to enforce module startup order.The console should startup before any console extensions because the console listens for extensions being added to its navigator. But those extensions should not (necessarily) inherit the console's classloader, especially since the console uses spring for configuring the pluto internals. The services dependency type didn't work as I had expected while using the c-m-p so I never actually used it in a server to see any class cast exceptions. Best wishes, Paul
Re: [VOTE] Release geronimo-txmanager 2.0.2
+1 TCK tests looked good. Joe Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo-transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
Re: [GShell] Plexus dependency in CommandLineBuilder
Ok, so it seems that wiring gshell using spring is not too difficult. However I have seen a weird dependency between two POJOs which cause a problem when wiring them. It happens between DefaultCommandExecutor which has a dependency on OsgiCommandLineBuilder which also has a dependency on the command executor. Is there any way to refactor things a bit to avoid this circular dependency ? On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMODEVTOOLS-242) J2g: needs indication of the script finish running in eclipse console
J2g: needs indication of the script finish running in eclipse console - Key: GERONIMODEVTOOLS-242 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-242 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Reporter: Lin Sun Assignee: Lin Sun Priority: Minor as titled. Currently, when I run any of the j2g tool (source, desp) in Eclipse, it contains no indication of whether the script finishs running or not in eclipse console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-242) J2g: needs indication of the command finish running in eclipse console
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMODEVTOOLS-242: - Summary: J2g: needs indication of the command finish running in eclipse console (was: J2g: needs indication of the script finish running in eclipse console) J2g: needs indication of the command finish running in eclipse console -- Key: GERONIMODEVTOOLS-242 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-242 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Reporter: Lin Sun Assignee: Lin Sun Priority: Minor as titled. Currently, when I run any of the j2g tool (source, desp) in Eclipse, it contains no indication of whether the script finishs running or not in eclipse console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: October board report
Guillaume, Looks fine to me... Gert Guillaume Nodet wrote: The report has to be submitted asap. I've written it at http://cwiki.apache.org/confluence/display/SM/2007-10-17. Please review and add anything missing asap.
Re: [GShell] Plexus dependency in CommandLineBuilder
FYI, I've found a workaround as Spring can solve such situations if using property injection rather than constructor injection... So creating wrapper solves the problem. On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Ok, so it seems that wiring gshell using spring is not too difficult. However I have seen a weird dependency between two POJOs which cause a problem when wiring them. It happens between DefaultCommandExecutor which has a dependency on OsgiCommandLineBuilder which also has a dependency on the command executor. Is there any way to refactor things a bit to avoid this circular dependency ? On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMODEVTOOLS-243) j2g: should not create openejb-jar.xml for the user if the project doesn't contain ejb related stuff
j2g: should not create openejb-jar.xml for the user if the project doesn't contain ejb related stuff Key: GERONIMODEVTOOLS-243 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-243 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Reporter: Lin Sun I am running the college fest sample with j2g descriptor tool. This sample just contains some jsp and servlet thus openejb-jar.xml isn't needed. However the j2g tool went ahead and created openejb-jar.xml for the project. AnnotationTool[INFO] Processing annotations for E:\gsamples\college_fest\src\servlets\PersonalServlet.java AnnotationTool[INFO] openejb-jar.xml successfully updated. AnnotationTool[INFO] Processing annotations for E:\gsamples\college_fest\src\servlets\WelcomeServlet.java AnnotationTool[INFO] openejb-jar.xml successfully updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-245) J2g: create one or more eclipse features to enable j2g to be installable from Eclipse update manager
J2g: create one or more eclipse features to enable j2g to be installable from Eclipse update manager Key: GERONIMODEVTOOLS-245 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-245 Project: Geronimo-Devtools Issue Type: New Feature Components: J2G Reporter: Lin Sun Assignee: Lin Sun Priority: Minor as titled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-244) J2g: remove unnecessary configurator module
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMODEVTOOLS-244. Resolution: Fixed changes in rev 583923 J2g: remove unnecessary configurator module --- Key: GERONIMODEVTOOLS-244 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-244 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Reporter: Lin Sun Assignee: Lin Sun Priority: Minor This has been discussed on devlist and no one really thinks the configurator module is useful with eclipse 3.3. I 've performed quite some testing (running src, res, desp tools) on 2 samples and they seem to be running fine without the module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4 as a distributed OSGi spring container....
L.S., I really like the way ServiceMix 4.0 will be built around a set of core technologies (OSGi, ActiveMQ, Camel, CXF). It's a very good idea to leverage these technologies also for our own 'internal' operations wherever possible and the Camel snippet that was shown has a very nice touch of simplicity/readability to it. I also like the suggestion of sending only a URL of the container in the heartbeat, thus limiting the size of the heartbeat message, while still allowing the other node to retrieve the data it needs. Perhaps I'm completely missing the point here, but ... Wouldn't it be possible to also include 'update notifications' in the heartbeat message this way? Whenever a new service (or a bundle of services) becomes available, an update notification is sent with a URL to allow the other nodes to only retrieve information about what has changed. This way, the node receiving the heartbeat can update it's own internal registry to reflect changes that have occurred in the other nodes. Gert James Strachan wrote: On 11/10/2007, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). Yeah; it does depend on how much data we're talking about. We could slice and dice the data using URLs. e.g. the full list of services available could be posted to some, say, Atom document on some shared server; this list can be updated incrementally or in total as and when services are added or removed. Then the heartbeat could just send around a URL to the detailed information. Or the list of services available could just be dynamically generated on demand if the container exposed a web front end. (push v pull) From a client perspective, it doesn't much care - the heartbeat message contains a URL to the detailed list of actual services provided if it wishes to get more information etc.
[jira] Created: (GERONIMODEVTOOLS-244) J2g: remove unnecessary configurator module
J2g: remove unnecessary configurator module --- Key: GERONIMODEVTOOLS-244 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-244 Project: Geronimo-Devtools Issue Type: Bug Components: J2G Reporter: Lin Sun Assignee: Lin Sun Priority: Minor This has been discussed on devlist and no one really thinks the configurator module is useful with eclipse 3.3. I 've performed quite some testing (running src, res, desp tools) on 2 samples and they seem to be running fine without the module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make useMavenDependencies default true ?
Ah.. #2 in your list above hadn't registered well. Sorry. Anyways, I get it now. But I'll still answer your questions below. Cheers Prasad On 10/11/07, David Jencks [EMAIL PROTECTED] wrote: On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote: So in summary, do we keep the lists mutually exclusive ? You've said mutually exclusive a couple of times and I don't understand why. The list of dependencies in the c-m-p configuration has to be a subset of the dependencies in the maven configuration. This is required by maven to get the build order right. What do you mean by mutually exclusive? Mutually exclusive is using either the maven dependencies or c-mp configuration deps but not both. This is what we have at present. The current useMavenDep option makes it mutually exclusive. Paul, do you still see a need for a merge/override option ? I do. Now I see it. Based on #2 in your note, there is an override option. So this means we will merge the list from maven deps and the c-m-p. Some deps in the c-m-p may override the ones in the maven deps but the other deps will be used as is. If so, I'll slowly deprecate the useMavenDependency option. Since almost all configs have now been converted to plugins, I think it is time we used the maven dependencies as default anyways. The presence of any dependencies in the c-m-p configuration will make the c-m-p use those deps only and exclude all maven deps. This is decidedly different from what I thought you proposed and what I thought was a good idea. I thought you proposed always using all the qualifying maven dependencies (i.e. leave out provided and test, as at present) but modify the import type based on the c-m-p configuration. This is still on the same veins, where the presence of deps in the c-m-p will obviate the need for a separate useMavenDep option. However, I don't think we should proceed with this refinement until all the configs are checked to be generating reasonable geronimo- plugin.xml files thanks david jencks Cheers Prasad On 10/10/07, Paul McMahan [EMAIL PROTECTED] wrote: On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/import dependencies before could I inquire what use you found for it and how you avoided class cast exceptions? I looked into to using it to enforce module startup order.The console should startup before any console extensions because the console listens for extensions being added to its navigator. But those extensions should not (necessarily) inherit the console's classloader, especially since the console uses spring for configuring the pluto internals. The services dependency type didn't work as I had expected while using the c-m-p so I never actually used it in a server to see any class cast exceptions. Best wishes, Paul
Re: [GShell] Plexus dependency in CommandLineBuilder
So I've been able to have a local shell wired with Spring without including any plexus jars in the classpath :-) I'm trying to do the same with the remote shell, but it seems that gshel-whisper is much more tied to plexus. Do you have any ongoing modifications to decouple it a bit from plexus or can I look at that ? On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: FYI, I've found a workaround as Spring can solve such situations if using property injection rather than constructor injection... So creating wrapper solves the problem. On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Ok, so it seems that wiring gshell using spring is not too difficult. However I have seen a weird dependency between two POJOs which cause a problem when wiring them. It happens between DefaultCommandExecutor which has a dependency on OsgiCommandLineBuilder which also has a dependency on the command executor. Is there any way to refactor things a bit to avoid this circular dependency ? On 10/11/07, Jason Dillon [EMAIL PROTECTED] wrote: Yup, sounds fine. As I mentioned to ya a while ago on IRC I took a few short cuts when I whipped this stuff up... after what now seems like a long time ago. Anyways, go for it. Only comment I've got is you should call the intf CommandLineBuilder and the default impl DefaultCommandLineBuilder (prefix insteand of suffix to follow how the other components play... ). --jason On Oct 11, 2007, at 6:46 AM, Guillaume Nodet wrote: I'm trying to configure GShell through spring because spring can integrate nicely in OSGi (which is my main purpose) and I just crossed one problem: the CommandLineBuilder is a dependency of DefaultCommandExecutor (in terms of POJOs). The problem is that CommandLineBuilder is a class, not an interface, with a strong dependency on plexus. So I'd like to introduce an interface CommandLineBuilder and rename the class as the default implementation CommandLineBuilderDefault. Any objections ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
Re: [DISCUSS] G 2.0.2 Release plan
All, I've updated the versions in branches/2.0.2 from 2.0.2-SNAPSHOT to 2.0.2. No code changes should be going into 2.0.2. I'm going to be finalizing the release notes and building binaries later tonight. The ibiblio repo is having problems this afternoon. To build successfully, I had to add the following to my settings.xml: mirrors mirror idibiblio.org/id nameMirror of http://repo1.maven.org/maven2//name urlhttp://repo1.maven.org/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors In case these problems persist, I intend to add this information to the 2.0.2 release notes and the building geronimo page on our wiki. --kevan
RE: ClassCastException at Derby EmbeddedDataSource
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at
org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor
.i
nternalGetConnection(SinglePoolConnectionInterceptor.java:67)
at
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt
er
ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:78)
at
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor
.g
etConnection(TransactionEnlistingInterceptor.java:46)
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.g
et
Connection(TransactionCachingInterceptor.java:88)
at
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get
Co
nnection(ConnectionHandleInterceptor.java:43)
at
Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
I went back to the commit list... looks like the last min fix aren't
pulled into geronimo 2.0.1, but they should be avail in the upcoming
geronimo 2.0.2. Sorry about the confusion.
No, for derby, we recommend people to select systemdatabase instead, as
it already has org.apache.derby/derby*/*/jar as the dependency. This
was a change made since geronimo 1.1 and here is some doc about it
(http://cwiki.apache.org/GMOxDOC11/migrating-applications-from-geronimo-v10.html,
check 2) Manually convert the derby jar dependencies to system-datasource).
David Jencks has worked on limiting the list of available JARs on the
portlet, but I think his change is only in trunk (which will be geronimo
2.1).
HTH,
Lin
Zakharov, Vasily M wrote:
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver (implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
dXAMCF.java:52)
at
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.getCon
ne
ction(MCFConnectionInterceptor.java:48)
at
org.apache.geronimo.connector.outbound.LocalXAResourceInsertionInterce
pt
or.getConnection(LocalXAResourceInsertionInterceptor.java:41)
at
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534158 ] Bhagwath Vadyala commented on GERONIMO-3457: I donot know whether Geronimo or jetty which is causing this error. Yes we are using G 2.0.1 Drools BRMS issue using geronimo 2.0.1-jetty6 - Key: GERONIMO-3457 URL: https://issues.apache.org/jira/browse/GERONIMO-3457 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Jetty Affects Versions: 2.0.1 Environment: geronimo 2.0.1-jetty6 windows drools-jbrms 4.0.1 Reporter: Bhagwath Vadyala Attachments: drools-error-screenshot.doc, geronimo-jetty-server-log.txt We are having an issuing testing drools BRMS 4.0.1 on geronimo 2.0.1 jetty 6 version. It deploys fine but when we open the url http://localhost:8080/drools-jbrms, its not redirecting to correct page. We use the same drools-jbrms war file and deploy on jboss-tomcat it works fine and redirects to the correct page. We posted the issue to JBOSS and here is the response from them. Michael Neale commented on JBRULES-1150: ok the URL in the browser it wrong. Ideally you will put in: http://localhost:8080/drools-jbrms and it *should* redirect to : http://localhost:8080/drools-jbrms/org.drools.brms.JBRMS/JBRMS.html if it doesn't - then it is a bug with how geronimo is redirecting. The index.jsp, which is default, has: % String redirectURL = org.drools.brms.JBRMS/JBRMS.html; response.sendRedirect(redirectURL); % which should work as it does on every other app server tried so far. unfortunately we don't have resources to support every purmutation of app servers/web containers so this will require some experimentation. please let me know how you go. .. Please let me know how to fix this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: ClassCastException at Derby EmbeddedDataSource
Ok, I see, thank you very much for the clarification.
Ok, let's wait for G2.0.2/2.1. :)
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 1:00 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
I went back to the commit list... looks like the last min fix aren't
pulled into geronimo 2.0.1, but they should be avail in the upcoming
geronimo 2.0.2. Sorry about the confusion.
No, for derby, we recommend people to select systemdatabase instead, as
it already has org.apache.derby/derby*/*/jar as the dependency. This
was a change made since geronimo 1.1 and here is some doc about it
(http://cwiki.apache.org/GMOxDOC11/migrating-applications-from-geronimo-
v10.html,
check 2) Manually convert the derby jar dependencies to
system-datasource).
David Jencks has worked on limiting the list of available JARs on the
portlet, but I think his change is only in trunk (which will be geronimo
2.1).
HTH,
Lin
Zakharov, Vasily M wrote:
Hi, Lin,
I don't see any org.apache.geronimo.* entries in Driver JAR
selection.
May this be a problem?
And anyway, selecting non-Derby JAR for Derby access is
counterintuitive, isn't it?
Taking into account that I'm connecting not to the SystemDatabase, but
to another database I've created through Console DB Manager.
Is there a case when choosing an org.apache.derby/derby*/*/jar for
Embedded Derby connection would be a valid choice?
Maybe there's some sense in limiting the list of available JARs after
Database Type is selected?
As for now creating the operational connector to the embedded database
seems impossible without asking questions and editing deployment plans
manually.
Thank you!
Vasily
-Original Message-
From: Lin Sun [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 10:36 PM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi,
You should see
org.apache.geronimo.configs/system-database/{version}/car
there on the list of driver Jar. (I think it was there when I used it
last time on 2.0.1.) You want to select it instead of
org.apache.derby/derby/10.2.2.0/jar to avoid your ClassCastException.
Lin
Zakharov, Vasily M wrote:
Hi David,
Yes, this actually helped, thank you very much!
However, the deployment plan I provided was generated by database
pool
wizard in the console, as follows:
Console Navigation - Services - Database Pools
Create a new database pool: Using the Geronimo database pool wizard
Database Type: Derby embedded XA
Driver JAR: org.apache.derby/derby/10.2.2.0/jar
This seems to be a logical and trivial way.
And org.apache.geronimo.configs is absent in the Driver JAR list.
So, maybe there's a problem with database pool wizard that generates
a
deployment plan that doesn't work as expected?
Vasily
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 10, 2007 4:16 AM
To: dev@geronimo.apache.org
Subject: Re: ClassCastException at Derby EmbeddedDataSource
Hi Vasily,
when you use a derby datasource you have to make sure you get the
derby classes from the same classloader as the embedded derby
database. You normally do this by replacing the derby dependency in
your plan with something like
dep:dependency
dep:groupIdorg.apache.geronimo.configs/dep:groupId
dep:artifactIdsystem-database/dep:artifactId
dep:typecar/dep:type
/dep:dependency
Hope this helps
david jencks
On Oct 9, 2007, at 2:16 PM, Zakharov, Vasily M wrote:
Hi, all,
I've come into a strange situation, that looks like maybe a bug,
while
working on SPECjAppServer2004 deployment on G2.0.1.
When working with Embedded XA TranQL connector to internal Derby
database, class org.apache.geronimo.jdbc.DelegatingDriver
(implements
java.sql.Driver) comes out in a place where either
org.apache.derby.jdbc.AutoloadedDriver (implements java.sql.Driver)
or
org.apache.derby.jdbc.InternalDriver (implements
org.apache.derby.iapi.services.monitor.ModuleControl) is expected,
and
this causes a ClassCastException on server side:
java.lang.ClassCastException:
org.apache.geronimo.jdbc.DelegatingDriver
at
org.apache.derby.jdbc.EmbeddedDataSource.findDriver(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedDataSource.getConnection(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.setupResourceAdapter
(Unknown
Source)
at
org.apache.derby.jdbc.EmbeddedXADataSource.getXAConnection(Unknown
Source)
at
org.tranql.connector.jdbc.AbstractXADataSourceMCF.getPhysicalConnectio
n(
AbstractXADataSourceMCF.java:74)
at
org.tranql.connector.derby.EmbeddedXAMCF.createManagedConnection
(Embedde
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, David Jencks [EMAIL PROTECTED] wrote: The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. why would this be better than using the built in ldap replication? (mitosis in apacheds) This is not a leading question, I really don't know :-) The only reason I said this is because I haven't yet looked at the replication code in ApacheDS. I have looked at the marshaling code in ActiveMQ and I know it is highly optimized and very well tested. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
gshell broken in trunk?
When I try to start the server with gshell...I am getting this: java.lang.NullPointerException: Cannot get property: homeDir on null object at org.codehaus.groovy.runtime.Invoker.getProperty(Invoker.java:179) at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:179) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:469) at org.apache.geronimo.commands.StartServerCommand.doExecute(StartServerCommand.groovy:159) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:103) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:128) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:97) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:124) at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209) at org.apache.geronimo.gshell.GShell.run(GShell.java:156) at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247) at org.apache.geronimo.gshell.cli.Main.main(Main.java:264) 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:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
Re: gshell broken in trunk?
I will take a look... --jason -Original Message- From: Jeff Genender [EMAIL PROTECTED] Date: Thu, 11 Oct 2007 16:14:53 To:dev@geronimo.apache.org Subject: gshell broken in trunk? When I try to start the server with gshell...I am getting this: java.lang.NullPointerException: Cannot get property: homeDir on null object at org.codehaus.groovy.runtime.Invoker.getProperty(Invoker.java:179) at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:179) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:469) at org.apache.geronimo.commands.StartServerCommand.doExecute(StartServerCommand.groovy:159) at org.apache.geronimo.gshell.command.CommandSupport.execute(CommandSupport.java:103) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute(PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:128) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute(DefaultCommandExecutor.java:97) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:124) at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209) at org.apache.geronimo.gshell.GShell.run(GShell.java:156) at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247) at org.apache.geronimo.gshell.cli.Main.main(Main.java:264) 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:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
Re: gshell broken in trunk?
I see this also. I have no idea what caused it. I was wondering if we could all agree on some manual integration tests before committing to gshell so that the projects that depend on it can continue to work while it evolves. I think its great that ServiceMix is also starting to use gshell but without a stable released version we might need to be extra careful. I expect for geronimo building the boilerplate and framework assemblies and making sure the framework assembly starts w/gshell would suffice. Is there something fairly simple we could do for a SM smoke test? thanks david jencks On Oct 11, 2007, at 3:14 PM, Jeff Genender wrote: When I try to start the server with gshell...I am getting this: java.lang.NullPointerException: Cannot get property: homeDir on null object at org.codehaus.groovy.runtime.Invoker.getProperty (Invoker.java:179) at org.codehaus.groovy.runtime.InvokerHelper.getProperty (InvokerHelper.java:179) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty (ScriptBytecodeAdapter.java:469) at org.apache.geronimo.commands.StartServerCommand.doExecute (StartServerCommand.groovy:159) at org.apache.geronimo.gshell.command.CommandSupport.execute (CommandSupport.java:103) at org.apache.geronimo.gshell.plugin.PlexusCommandWrapper.execute (PlexusCommandWrapper.java:71) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:128) at org.apache.geronimo.gshell.DefaultCommandExecutor.execute (DefaultCommandExecutor.java:97) at org.apache.geronimo.gshell.DefaultShell.execute(DefaultShell.java:124) at org.apache.geronimo.gshell.DefaultShell.run(DefaultShell.java:209) at org.apache.geronimo.gshell.GShell.run(GShell.java:156) at org.apache.geronimo.gshell.cli.Main.boot(Main.java:247) at org.apache.geronimo.gshell.cli.Main.main(Main.java:264) 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:585) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:351) at org.apache.geronimo.gshell.bootstrap.Launcher.main(Launcher.java:59)
[jira] Updated: (GERONIMO-3501) The geronimo tuscany plugin cannot be started in Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMO-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3501: --- Fix Version/s: (was: 2.0.x) The geronimo tuscany plugin cannot be started in Geronimo 2.0.1 --- Key: GERONIMO-3501 URL: https://issues.apache.org/jira/browse/GERONIMO-3501 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0.1 Reporter: Raymond Feng Attachments: rfeng-tuscany-plugin.patch The geronimo tuscany plugin cannot be started in Geronimo 2.0.1 as tuscany-definitions module is not added as dependency. There are also SNAPSHOT dependencies on sdo/das. I attach a patch to fix these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3494) HTTP GET is not handled correctly for JAX-WS services
[ https://issues.apache.org/jira/browse/GERONIMO-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3494: --- Fix Version/s: (was: 2.0.x) HTTP GET is not handled correctly for JAX-WS services - Key: GERONIMO-3494 URL: https://issues.apache.org/jira/browse/GERONIMO-3494 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0, 2.0.1 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.0.2, 2.1 The JAX-WS spec is not very clear on this but Geronimo does not seem to handle HTTP GET correctly for JAX-WS web services. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3446) Improperly configured JRE_HOME or JAVA_HOME environment variables can cause server failure
[ https://issues.apache.org/jira/browse/GERONIMO-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3446. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.0.2 Problem was fixed. Closing issue. Improperly configured JRE_HOME or JAVA_HOME environment variables can cause server failure -- Key: GERONIMO-3446 URL: https://issues.apache.org/jira/browse/GERONIMO-3446 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0 Reporter: Kevan Miller Assignee: Kevan Miller Fix For: 2.0.2 If JAVA_HOME or JRE_HOME environment variables are not set properly, the Geronimo server may fail during startup. For example, on Mac OS X, if you export JRE_HOME=/usr. You get the following: Caused by: java.lang.NullPointerException at org.apache.geronimo.security.SubjectId.hashCode(SubjectId.java:79) at java.util.HashMap.hash(HashMap.java:264) at java.util.HashMap.put(HashMap.java:382) at java.util.Collections$SynchronizedMap.put(Collections.java:1983) at org.apache.geronimo.security.ContextManager.registerSubject(ContextManager.java:299) at org.apache.geronimo.security.ContextManager.clinit(ContextManager.java:71) ... 37 more The problem is that the java.ext.dirs property is being set to an improper value. This means the JRE is not able to load jar files from $JRE_HOME/lib/ext. At a minimum, our scripts should detect an invalid JRE_HOME or JAVA_HOME setting. Better yet, we could try to set it automatically... In addition, it looks like we don't need to explicitly configure the java.ext.dirs property any longer, anyway (we no longer package ext jars). Removing the setting of the property (e.g. -Djava.ext.dirs=$EXT_DIRS ) from our scripts would also fix this specific problem... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3326) ClassLoader memory leak caused by OpenJPA
[ https://issues.apache.org/jira/browse/GERONIMO-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-3326. -- Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.0.2 Closing issue. Problem was fixed. ClassLoader memory leak caused by OpenJPA - Key: GERONIMO-3326 URL: https://issues.apache.org/jira/browse/GERONIMO-3326 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.0-M7 Reporter: Kevan Miller Assignee: Kevan Miller Priority: Blocker Fix For: 2.0.2, 2.1 Attachments: OpenJPAMemLeak-G.patch, OpenJPAMemLeak-OJPA.patch As David Jencks mentioned in GERONIMO-3305, there's a ClassLoader memory leak in deploy/undeploy. Geronimo is running out of PermGen space in some simple deploy/undeploy scenarios involving OpenJPA. The cause of the problem seems to be the _metas table in PCRegistry. _metas is a ConcurrentReferenceHashMap with WEAK reference keys and HARD reference values. The keys are the PersistenceCapable classes. While the values are the metadata for these classes which are maintained by the internal Meta class. The cause of the ClassLoader memory leak is simple -- if any of the objects/classes held by the Meta class (e.g. fieldTypes) have also been loaded by the same ClassLoader used to load the PersistenceCapable class, the PersistenceCapable class (the weak key) will never be GCed. The value of the HashMap entry will always maintain a hard reference to the ClassLoader. Since the ClassLoader will never be GC'ed, the the the pcClass Class object will never be GC'able... The problem can be easily recreated using current Geronimo trunk and the Geronimo Daytrader application. FYI, here are the GC Roots for one of our ClassLoaders being leaked -- http://people.apache.org/~kevan/PCRegistryLeak.html I've contacted the OpenJPA dev list. Hopefully, can get this resolved, quickly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-2515) load of geronimo/rmi-naming/1.1.1/car failed on Solaris 10
[ https://issues.apache.org/jira/browse/GERONIMO-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534207 ] Donald Woods commented on GERONIMO-2515: Yep, tar on AIX has the same problem You have to use the optional/add-on Linux gunzip utils (or jar command.) load of geronimo/rmi-naming/1.1.1/car failed on Solaris 10 -- Key: GERONIMO-2515 URL: https://issues.apache.org/jira/browse/GERONIMO-2515 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.1.1 Environment: Solaris 10 , JDK 1.4.2 Reporter: K Wesley Priority: Blocker $ java -jar server.jar Booting Geronimo Kernel (in Java 1.4.2_12)... Starting Geronimo Application Server v1.1.1 [*-] 0% 2s Startup failed org.apache.geronimo.kernel.config.LifecycleException: load of geronimo/rmi-naming/1.1.1/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:294) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:275) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:250) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$fe617d34.loadConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:294) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) Caused by: org.apache.geronimo.kernel.repository.MissingDependencyException: Unable to resolve dependency org.apache.geronimo.specs/geronimo-activation_1.0.2_spec//jar at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:119) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver.resolveInClassLoader(DefaultArtifactResolver.java:98) at org.apache.geronimo.kernel.repository.DefaultArtifactResolver$$FastClassByCGLIB$$e847b746.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.repository.ArtifactResolver$$EnhancerByCGLIB$$8e854b59.resolveInClassLoader(generated) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.resolveParentIds(SimpleConfigurationManager.java:466) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadDepthFirst(SimpleConfigurationManager.java:425) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:291) ... 15 more Server shutdown begun Server shutdown completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: KEYS ?
On Aug 8, 2007, at 3:08 PM, Jason Dillon wrote: And... this is done. I don't know what else needs to be changed... if anyone runs into any problems lemme know. The new location for this puppy in svn is: https://svn.apache.org/repos/asf/geronimo/KEYS Props need to check the current trunk/* and branches/* (except for release in progress branches) bits for other KEYS files and nuke them. I just encountered our proliferation of KEYS files. From an Apache release signing perspective, I think the only important file is http://www.apache.org/dist/geronimo/KEYS. Probably makes sense to keep this file and https://svn.apache.org/repos/asf/geronimo/KEYS in sync (they are currently not in sync). I'm not sure if it's possible to automate this... Ideas? I don't know of any reason to maintain KEYS files in any other svn directory. I propose we delete them from all non-tagged branches/ trunks in our svn tree. Thoughts? --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Oops. Accidentally sent my vote directly to myself instead of the dev list. Here's my +1. --kevan
