Re: org.apache.geronimo.gbean.NoProxy=true
Why were proxies introduced at all? -VamsiOn 3/22/06, Jeff Genender <[EMAIL PROTECTED]> wrote: This is great...debugging with proxies has been a real PITA...this will*really* help.Hiram Chirino wrote:> +1 from me too. Way back when I was working on the ActiveMQ -> Geronimo integration, the poxies gave me a few headaches. >> Regards,> Hiram>> On 3/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:>> +1...the debugging thing has been a problem. If for no other reason this is the >> right thing to do. However, there will be users who care less about isolation>> and more about memory and speed. This gives them the choice to run exposed to>> get what they want.>> >> Matt Dain Sundstrom wrote:>>> On Mar 18, 2006, at 5:18 AM, John Sisson wrote:>>> Dain Sundstrom wrote:> Forgot to mention, I added an experimental flag to 1.1 which will> turn off proxying in GBean references. This means that the injected> reference will be the actual service instance and not a proxy to the> service. My guess is this will break a few services that use > ProxyManager.getProxyTarget(Objcet), since the reference won't be a> proxy. All of these uses will have be rewritten to not assume a> proxy if we want to keep use this flag. >> To turn it on, you simply set the system property> org.apache.geronimo.gbean.NoProxy=true. This is property is picked> up by a static block in the AbstractGBeanReference class, so the > property will apply for the life of the kernel class loader> (normally the life of the vm).>> -dain> > What was the reason for this experiment?>> I'd like to completely remove proxying between gbeans in the future,>>> but I think it would lots break stuff to just flip it over right now. >>> Proxying between GBeans is problematic because it changes the expected>>> programming model of component writers. When you are giving out>>> proxies instead of the instance, the user can no longer use == for >>> comparison, and the since proxies are so much slower, the expected>>> overhead of a call is much higher. Both of these require require>>> changes to the component for it to run in geronimo, and if we want to >>> have the largest component base, we're going to have to change.>> Besides all of that, it is really a PITA to debug geronimo since you>>> have to step through all of those proxies, for really no reason. >> -dain --> Regards,> Hiram
Re: org.apache.geronimo.gbean.NoProxy=true
This is great...debugging with proxies has been a real PITA...this will *really* help. Hiram Chirino wrote: > +1 from me too. Way back when I was working on the ActiveMQ - > Geronimo integration, the poxies gave me a few headaches. > > Regards, > Hiram > > On 3/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> +1...the debugging thing has been a problem. If for no other reason this is >> the >> right thing to do. However, there will be users who care less about >> isolation >> and more about memory and speed. This gives them the choice to run exposed >> to >> get what they want. >> >> Matt >> >> Dain Sundstrom wrote: >>> On Mar 18, 2006, at 5:18 AM, John Sisson wrote: >>> Dain Sundstrom wrote: > Forgot to mention, I added an experimental flag to 1.1 which will > turn off proxying in GBean references. This means that the injected > reference will be the actual service instance and not a proxy to the > service. My guess is this will break a few services that use > ProxyManager.getProxyTarget(Objcet), since the reference won't be a > proxy. All of these uses will have be rewritten to not assume a > proxy if we want to keep use this flag. > > To turn it on, you simply set the system property > org.apache.geronimo.gbean.NoProxy=true. This is property is picked > up by a static block in the AbstractGBeanReference class, so the > property will apply for the life of the kernel class loader > (normally the life of the vm). > > -dain > > What was the reason for this experiment? >>> >>> I'd like to completely remove proxying between gbeans in the future, >>> but I think it would lots break stuff to just flip it over right now. >>> Proxying between GBeans is problematic because it changes the expected >>> programming model of component writers. When you are giving out >>> proxies instead of the instance, the user can no longer use == for >>> comparison, and the since proxies are so much slower, the expected >>> overhead of a call is much higher. Both of these require require >>> changes to the component for it to run in geronimo, and if we want to >>> have the largest component base, we're going to have to change. >>> >>> Besides all of that, it is really a PITA to debug geronimo since you >>> have to step through all of those proxies, for really no reason. >>> >>> -dain >>> >>> >>> > > > -- > Regards, > Hiram
Dynamically registering a GBean
Hi Dain, Is possible to dynamicaly register/unregister a GBean in the kernel? Last time I checked, that was not really possible, but I'm hoping things have changed since then? -- Regards, Hiram
Re: org.apache.geronimo.gbean.NoProxy=true
+1 from me too. Way back when I was working on the ActiveMQ - Geronimo integration, the poxies gave me a few headaches. Regards, Hiram On 3/19/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > +1...the debugging thing has been a problem. If for no other reason this is > the > right thing to do. However, there will be users who care less about isolation > and more about memory and speed. This gives them the choice to run exposed to > get what they want. > > Matt > > Dain Sundstrom wrote: > > On Mar 18, 2006, at 5:18 AM, John Sisson wrote: > > > >> Dain Sundstrom wrote: > >> > >>> Forgot to mention, I added an experimental flag to 1.1 which will > >>> turn off proxying in GBean references. This means that the injected > >>> reference will be the actual service instance and not a proxy to the > >>> service. My guess is this will break a few services that use > >>> ProxyManager.getProxyTarget(Objcet), since the reference won't be a > >>> proxy. All of these uses will have be rewritten to not assume a > >>> proxy if we want to keep use this flag. > >>> > >>> To turn it on, you simply set the system property > >>> org.apache.geronimo.gbean.NoProxy=true. This is property is picked > >>> up by a static block in the AbstractGBeanReference class, so the > >>> property will apply for the life of the kernel class loader > >>> (normally the life of the vm). > >>> > >>> -dain > >>> > >>> > >> What was the reason for this experiment? > > > > > > I'd like to completely remove proxying between gbeans in the future, > > but I think it would lots break stuff to just flip it over right now. > > Proxying between GBeans is problematic because it changes the expected > > programming model of component writers. When you are giving out > > proxies instead of the instance, the user can no longer use == for > > comparison, and the since proxies are so much slower, the expected > > overhead of a call is much higher. Both of these require require > > changes to the component for it to run in geronimo, and if we want to > > have the largest component base, we're going to have to change. > > > > Besides all of that, it is really a PITA to debug geronimo since you > > have to step through all of those proxies, for really no reason. > > > > -dain > > > > > > > -- Regards, Hiram
Re: ActiveMQ forums
Hi John, oh that's awesome! I had not realized that it would that simple. We definitely need to get our lists on Nabble ASAP. Who knows how to do that? On 3/21/06, John Sisson <[EMAIL PROTECTED]> wrote: > Hiram Chirino wrote: > > Hi John, > > > > Nabble looks nice! Thanks for pointing that out. Is it possible to > > create accounts on gmane or nabble to post messages in the the forums? > > Most users of forum software are the kind that just want to pop in > > and ask a quick question and then pop out. Which is quite different > > for the use pattern that most of us developers have. Something the > > bridge the 2 use cases would be most useful. > > > Having a further look at Nabble (never used it myself, but we have users > on the Geronimo list that use it) it appears these are the steps you > need to make before you can make your first post to a list: > > * Register (for free) at Nabble: http://www.nabble.com/user/Register.jtp > * Receive and reply to the confirmation email from Nabble to confirm > your email address is valid. > * Go to the ASF list in Nabble (e.g. see Geronimo's at > http://www.nabble.com/Apache-Geronimo---Users-f135.html ) > * Click on Post new message > * The Post New Message screen is displayed with a warning that if you > haven't subscribed that you must subscribe. > * Click on "how to subscribe" link > * Pop up window appears - click on Subscribe > * Receive and reply to subscription confirmation from ASF list > > Once subscription is approved you can post a message. > > So there are a few steps that have to be done, but it is quite simple. > > Regards, > > John > > On 3/21/06, John Sisson <[EMAIL PROTECTED]> wrote: > > > >> Currently the http://incubator.apache.org/activemq/ has a link to a web > >> forums page that is hosted by LogicBlaze. > >> > >> I can understand the need for a web forum - users who don't want to > >> subscribe to a mailing list, but couldn't that be addressed by directing > >> users to existing web forums that are a web interface to the mailing > >> lists that also allow messages to be posted. For example, something like: > >> > >> http://www.nabble.com/ActiveMQ-f2354.html > >> http://news.gmane.org/gmane.comp.java.activemq.user/cutoff=3704 > >> > >> Currently there is activity happening on the web forums that is not > >> visible on the mailing lists, which should be the primary means of > >> communication for the project. > >> > >> John > >> > >> > > > > > > -- > > Regards, > > Hiram > > > > > > -- Regards, Hiram
[jira] Assigned: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ] Prasad Kashyap reassigned GERONIMO-1737: Assign To: Prasad Kashyap > Plugin migration to Maven 2: geronimo-assembly-plugin > - > > Key: GERONIMO-1737 > URL: http://issues.apache.org/jira/browse/GERONIMO-1737 > Project: Geronimo > Type: Sub-task > Components: buildsystem > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > > It's a task to keep track of the progress of the plugin build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Getting Geronimo to use the upcoming ActiveMQ 4.0-RC1 and the activemq-gbean & activemq-gbean-management modules
Hi John, Yep it will be needed. We need to update it so that it works with the new 4.x way of updating stuff. Should not be to hard to get it working again now that 4.x has stabilized. What would be nice is to have a better set of gbeans than what we had with ActiveMQ 3.x. The 3.x gbeans allow you to configure about 5% of the options that activemq allows you to tweak using the standard activemq.xml files. I was hoping we could improve this for 4.x. Regards, Hiram On Mar 21, 2006, at 1:33 AM, John Sisson wrote: What needs to be done to Geronimo to use ActiveMQ 4.0-RC1 when it is available for testing? I noticed the activemq-gbean module (that was available in previous ActiveMQ releases used by Geronimo) is under the sandbox with some svn log comments about it not being operational. Won't this be needed for embedding ActiveMQ in Geronimo? Thanks, John
Re: ActiveMQ forums
Hiram Chirino wrote: Hi John, Nabble looks nice! Thanks for pointing that out. Is it possible to create accounts on gmane or nabble to post messages in the the forums? Most users of forum software are the kind that just want to pop in and ask a quick question and then pop out. Which is quite different for the use pattern that most of us developers have. Something the bridge the 2 use cases would be most useful. Having a further look at Nabble (never used it myself, but we have users on the Geronimo list that use it) it appears these are the steps you need to make before you can make your first post to a list: * Register (for free) at Nabble: http://www.nabble.com/user/Register.jtp * Receive and reply to the confirmation email from Nabble to confirm your email address is valid. * Go to the ASF list in Nabble (e.g. see Geronimo's at http://www.nabble.com/Apache-Geronimo---Users-f135.html ) * Click on Post new message * The Post New Message screen is displayed with a warning that if you haven't subscribed that you must subscribe. * Click on "how to subscribe" link * Pop up window appears - click on Subscribe * Receive and reply to subscription confirmation from ASF list Once subscription is approved you can post a message. So there are a few steps that have to be done, but it is quite simple. Regards, John On 3/21/06, John Sisson <[EMAIL PROTECTED]> wrote: Currently the http://incubator.apache.org/activemq/ has a link to a web forums page that is hosted by LogicBlaze. I can understand the need for a web forum - users who don't want to subscribe to a mailing list, but couldn't that be addressed by directing users to existing web forums that are a web interface to the mailing lists that also allow messages to be posted. For example, something like: http://www.nabble.com/ActiveMQ-f2354.html http://news.gmane.org/gmane.comp.java.activemq.user/cutoff=3704 Currently there is activity happening on the web forums that is not visible on the mailing lists, which should be the primary means of communication for the project. John -- Regards, Hiram
[jira] Created: (GERONIMO-1758) Can not use Realm with SQL database over connection pool
Can not use Realm with SQL database over connection pool
Key: GERONIMO-1758
URL: http://issues.apache.org/jira/browse/GERONIMO-1758
Project: Geronimo
Type: Bug
Components: security
Versions: 1.0
Environment: Basic install
Reporter: Torsten Markwardt
i have tested with integrated derby. configuration (userSelect etc.) was bad
stored for SQLLoginModule. On the map the map was stored the entries
userSelect, dataSourceApplication, groupSelect and dataSourceName with key
"{userSelect" and the value ",[
,]dataSourceApplication=,[ ,]groupSelect=,[
,]dataSourceName=".
Ergo ... i can not use SQL based realm :-(
here a debug hack to view:
# options.KeySet list
03:22:30,390 ERROR [] DEBUG: 000: 0: {userSelect
03:22:30,390 ERROR [] DEBUG: 000: 1:
org.apache.geronimo.security.realm.GenericSecurityRealm.KERNEL
03:22:30,390 ERROR [] DEBUG: 000: 2:
org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER
03:22:30,390 ERROR [] DEBUG: 000: 3:
org.apache.geronimo.security.realm.GenericSecurityRealm.SERVERINFO
# options
03:22:30,390 ERROR [] DEBUG: 001: options={{userSelect=SELECT u.login,
u.password, u.passwordmethod FROM login_users AS u WHERE u.login=?,
dataSourceApplication=null, groupSelect=SELECT u.login, g.name FROM l
ogin_users AS u, login_groups AS g, login_group_members AS r WHERE
u.id=r.user_id AND g.id = r.group_id AND u.login=?,
dataSourceName=jdbc/WebConfDatabase}},
org.apache.geronimo.security.realm.Generic
SecurityRealm.KERNEL=geronimo,
org.apache.geronimo.security.realm.GenericSecurityRealm.CLASSLOADER=[org.apache.geronimo.kernel.config.MultiParentClassLoader
id=SecurityRealm-webconf-realm], org.apache
.geronimo.security.realm.GenericSecurityRealm.SERVERINFO=[org.apache.geronimo.system.serverinfo.ServerInfo$$EnhancerByCGLIB$$5eff278f:
geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-sys
tem/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=ServerInfo]}
# Error on SQLLoginModule.initialize -> properties.put( "jdbcUser",
options.get( USER))
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [VOTE] create 4.0-RC1 release of ActiveMQ
Hi John, I've created a couple ActiveMQ issues to track those: http://jira.activemq.org/jira/browse/AMQ-651 http://jira.activemq.org/jira/browse/AMQ-652 Putting them on the ActiveMQ Road map seems to encourage folks to resolve them. Since 4.x is substantially different from 3.x, I've got a feeling that many of these issues will not be a problem anymore, and conversely, we may find a few new issues. So is the plan to have ActiveMQ 4.0 integrated into Geronimo? Or can that wait for 4.1?? On 3/21/06, John Sisson <[EMAIL PROTECTED]> wrote: > +1 create the 4.0-RC1 distribution - assuming that release candidates > will give us the opportunity to test/resolve some ActiveMQ issues in > Geronimo's JIRA under the 'ActiveMQ' component (whilst using the 4.0-RCx > distributions) before the 4.0 release. > > In particular the following seem to be ActiveMQ (not Geronimo) issues > that I feel should also be resolved before the 4.0 release: > > http://issues.apache.org/jira/browse/GERONIMO-815 > http://issues.apache.org/jira/browse/GERONIMO-1493 > http://issues.apache.org/jira/browse/GERONIMO-1494 > > The remainder of the JIRAs under the ActiveMQ component of Geronimo seem > to be Geronimo issues (e.g. management console etc.): > > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10220&sorter/order=DESC&sorter/field=priority&resolution=-1&component=11417 > > Thanks, > > John > > James Strachan wrote: > > The 4.0 release of ActiveMQ is long overdue; since we started incubation > > we've got out of the good habit of releasing early and releasing often. So > > I'd like us to get back on track making frequent releases even though we are > > still in the incubator (we can work on the community building and > > infrastructure issues in parallel to getting good releases out that people > > can use & give us feedback on). > > > > So I'd like us to create a release candidate (4.0-RC1) of what 4.0 will be > > so we can iron out any gremlins before the full 4.0 release. > > > > I've put a Release Plan together on the wiki > > http://docs.codehaus.org/display/ACTIVEMQ/Release+Plans > > > > in particular > > http://docs.codehaus.org/display/ACTIVEMQ/4.0+RC+1+Guide > > > > So please can you vote on whether to go ahead and start making this release. > > When the binary distro is done, we'll have another vote to approve the > > distro - then ask for the Incubator PMC's blessing to actually ship the > > release. > > > > [ ] +1 create the 4.0-RC1 distribution > > [ ] -1 veto the creation of the distro because: .. > > > > Here's my +1 > > > > -- > > > > James > > --- > > http://radio.weblogs.com/0112098/ > > > > > > -- Regards, Hiram
[jira] Created: (AMQ-652) Potential infinite loop in ActiveMQ shutdown processing when in Geronimo
Potential infinite loop in ActiveMQ shutdown processing when in Geronimo Key: AMQ-652 URL: http://jira.activemq.org/jira//browse/AMQ-652 Project: ActiveMQ Type: Bug Components: Connector Environment: Geronimo Reporter: Hiram Chirino Fix For: 4.0 RC 2 Need to check to see if this is still valid against 4.x see: http://issues.apache.org/jira/browse/GERONIMO-1494 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1494) Potential infinite loop in ActiveMQ shutdown processing
[ http://issues.apache.org/jira/browse/GERONIMO-1494?page=comments#action_12371370 ] Hiram Chirino commented on GERONIMO-1494: - see http://jira.activemq.org/jira/browse/AMQ-652 > Potential infinite loop in ActiveMQ shutdown processing > --- > > Key: GERONIMO-1494 > URL: http://issues.apache.org/jira/browse/GERONIMO-1494 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0 > Reporter: Kevan Miller > Priority: Minor > Fix For: 1.2 > > The geronimo.log posted to http://issues.apache.org/jira/browse/GERONIMO-1372 > shows evidence of infinite loop in ActiveMQ shutdown processing. > The log entry from the 1372 log is excerpted below: > 17:30:34,325 WARN [TransportChannelSupport] Caught exception dispatching > message and no ExceptionListener registered: javax.jms.JMSException: > asyncSend failed: java.io.EOFException: Cannot write to the stream any more > it has already been closed > javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write > to the stream any more it has already been closed > at > org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:483) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) > > at > org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) > > at > org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > ... (you get the picture) > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:139) > > at > org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261) > > at > org.apache.geronimo.connector.ResourceAdapterWrapper.endpointDeactivation(ResourceAdapterWrapper.java:92) > > at > org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke() > > at net.sf.cglib.
[jira] Commented: (GERONIMO-815) Get stack trace from ActiveMQ when shutting down geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-815?page=comments#action_12371369 ] Hiram Chirino commented on GERONIMO-815: I've got a feeling that this will not show up anymore with AMQ 4.x but will need to get the integration work for AMQ 4.x done first to know for sure. > Get stack trace from ActiveMQ when shutting down geronimo > - > > Key: GERONIMO-815 > URL: http://issues.apache.org/jira/browse/GERONIMO-815 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0-M4 > Reporter: John Sisson > Assignee: Hiram Chirino > Fix For: 1.2 > > It seems unnecessary to have a stack trace from ActiveMQ when a connection is > shut down during Geronimo shutdown? > Server shutdown begun > 2005-07-26 12:29:43,623 [TcpTransportChannel: > Socket[addr=localhost/127.0.0.1,port=61616,localport=1567]] WARN > org.activemq.transpo > rt.tcp.TcpTransportChannel - Peer closed connection > java.io.EOFException > at java.io.DataInputStream.readByte(Unknown Source) > at > org.activemq.io.impl.AbstractDefaultWireFormat.readPacket(AbstractDefaultWireFormat.java:168) > at > org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:309) > at java.lang.Thread.run(Unknown Source) > Server shutdown completed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1493) Deadlock in ActiveMQ close processing
[ http://issues.apache.org/jira/browse/GERONIMO-1493?page=comments#action_12371368 ] Hiram Chirino commented on GERONIMO-1493: - See http://jira.activemq.org/jira/browse/AMQ-651 > Deadlock in ActiveMQ close processing > - > > Key: GERONIMO-1493 > URL: http://issues.apache.org/jira/browse/GERONIMO-1493 > Project: Geronimo > Type: Bug > Components: ActiveMQ > Versions: 1.0 > Environment: Geronimo 1.0 > Reporter: Kevan Miller > Fix For: 1.2 > > Poor use of synchronization in ActiveMQAsfEndpointWorker can prevent Geronimo > from shutting down. The problem showed up in Jira 1422 > (http://issues.apache.org/jira/browse/GERONIMO-1422). And is contained in the > attached file > (http://issues.apache.org/jira/secure/attachment/12321750/geronimo_shutdown_stdout.txt). > The following thread is attempting to reconnect to the broker: > "Thread-91" prio=7 tid=0x08358d50 nid=0x91 waiting on condition > [c082f000..c082fd98] > at java.lang.Thread.sleep(Native Method) > at > org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:177) > - locked <0xc7c80470> (a org.activemq.ra.ActiveMQAsfEndpointWorker) > at > org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) > at > org.activemq.ra.ActiveMQAsfEndpointWorker$1.run(ActiveMQAsfEndpointWorker.java:105) > - locked <0xc7c7d138> (a org.activemq.ra.ActiveMQAsfEndpointWorker$1) > at > org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:534) > While the following thread is attempting to close the EndpointWorker: > "Geronimo shutdown thread" prio=5 tid=0x08ed3030 nid=0x7f waiting for monitor > entry [c07ed000..c07edd98] > at > org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:135) > - waiting to lock <0xc7c80470> (a > org.activemq.ra.ActiveMQAsfEndpointWorker) > at > org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261) > at > org.apache.geronimo.connector.ResourceAdapterWrapper.endpointDeactivation(ResourceAdapterWrapper.java:92) > at > org.apache.geronimo.connector.ResourceAdapterWrapper$$FastClassByCGLIB$$4ab28e73.invoke() > 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:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.connector.ResourceAdapterWrapper$$EnhancerByCGLIB$$168e117d.endpointDeactivation() > at > org.apache.geronimo.connector.ActivationSpecWrapper.deactivate(ActivationSpecWrapper.java:109) > at > org.apache.geronimo.connector.ActivationSpecWrapper$$FastClassByCGLIB$$aaa078c1.invoke() > 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:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.connector.ActivationSpecWrapper$$EnhancerByCGLIB$$17d592bb.deactivate() > at org.openejb.mdb.MDBContainer.doStop(MDBContainer.java:223) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1079) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:395) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:200) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:545) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:213) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:192) >
[jira] Updated: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ http://jira.activemq.org/jira//browse/AMQ-531?page=all ] Hiram Chirino updated AMQ-531: -- Fix Version: (was: 4.0 RC1) 4.0 RC 2 > XBean has a runtime issue with Spring 2.0M2 > --- > > Key: AMQ-531 > URL: http://jira.activemq.org/jira//browse/AMQ-531 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Environment: Spring 2.0M2 > Reporter: Ben Hale > Assignee: james strachan > Fix For: 4.0 RC 2 > > > Apparently there is an issue with XBean now that Spring 2.0 (starting with > M2) is compiled against a Java 5 compiler > (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating > how long before XBean releases a fix and postponing the 4.0 release until > they do. If not, at least documenting in a known issues list that ActiveMQ > 4.0 can't working with 2.0M2 and later until a later release where they do > fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-639) Broker is not re-connecting to a network of brokers after going down and then being brought back up
[ http://jira.activemq.org/jira//browse/AMQ-639?page=all ] Hiram Chirino updated AMQ-639: -- Fix Version: (was: 4.0 RC1) 4.0 RC 2 > Broker is not re-connecting to a network of brokers after going down and then > being brought back up > --- > > Key: AMQ-639 > URL: http://jira.activemq.org/jira//browse/AMQ-639 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Reporter: Brian Diesenhaus > Assignee: Hiram Chirino > Priority: Critical > Fix For: 4.0 RC 2 > > > I have set up a network of brokers with the following configuration: > http://activemq.org/config/1.0";> >class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> > >managementContext="#mc"> > > > > > > > > > > > > >discoveryUri="multicast://bfe2"/> > > > > > > > > > > > > > > > I then run a series of tests (producing and consuming on the network of > brokers). Then I shut one broker down and then start it up again it can't > see the other brokers in the network but the other brokers can see it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-501) ActiveMQ is not JCA1.5 compliant
[ http://jira.activemq.org/jira//browse/AMQ-501?page=all ] Hiram Chirino updated AMQ-501: -- Fix Version: (was: 4.0 RC1) (was: 4.0) 4.0 RC 2 > ActiveMQ is not JCA1.5 compliant > - > > Key: AMQ-501 > URL: http://jira.activemq.org/jira//browse/AMQ-501 > Project: ActiveMQ > Type: Bug > Components: Connector > Versions: 4.0, 4.0 RC1 > Environment: RHEL4, BEA Weblogic 9.0.1 > Reporter: Richard Cottrill > Assignee: Patrick Villacorta > Priority: Blocker > Fix For: 4.0 RC 2 > Attachments: rartest-new.ear, rartest.ear > > > When attempting to install the ActiveMQ RAR, these errors are thrown, and > appear to be vaild and correct (verified by browsing the ActiveMQ source > code). Classloading problems appear to prevent using ActiveMQ using the > Foriegn JMS facility of Weblogic. > [1] The ra.xml class > 'org.activemq.ra.ActiveMQManagedConnectionFactory' must override both > equals() and hashCode(), but doesn't. > [2] The ra.xml class > 'org.activemq.ra.ActiveMQManagedConnectionFactory' must override both > equals() and hashCode(), but doesn't. > [3] The ra.xml class > 'org.activemq.ra.ActiveMQManagedConnectionFactory' must override both > equals() and hashCode(), but doesn't. > [4] The ra.xml > 'org.activemq.ra.ActiveMQActivationSpec' must implement java.io.Serializable > but does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Geronimo Documentation - Spring
Hi All, here is an update to the Spring integration doc. So far so good, two more apps to go and I'll have just the foundation :D http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Spring Has anyone fully tested the *Countries* sample? I'm having some trouble trying to use the database configuration. Cheers! Hernan
[jira] Updated: (GERONIMO-1738) Plugin migration to Maven 2: geronimo-deployment-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1738?page=all ] Prasad Kashyap updated GERONIMO-1738: - Attachment: geronimo-deployment-plugin.patch 1) Plugin has been used and verified by the new itests framework 2) UnpackServer goal has been made redundant by similar goals in maven-assembly-plugin and dependency-maven-plugin. 3) WaitForServer is made into an util and now invoked from StartRemoteServer. It can be invoked by any other mojo in the plugin too. 4) 'mvn site' goal on this plugin fails. Either fix it here next or in another JIRA. > Plugin migration to Maven 2: geronimo-deployment-plugin > --- > > Key: GERONIMO-1738 > URL: http://issues.apache.org/jira/browse/GERONIMO-1738 > Project: Geronimo > Type: Sub-task > Components: buildsystem > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > Attachments: geronimo-deployment-plugin.patch > > It's a task to keep track of the progress of the plugin build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating geronimo-plugins to M2
On Mar 21, 2006, at 7:16 AM, Matt Hogstrom wrote: Sorry if this has been mentioned. Would it make sense to put out an informational message in the M1 plugins announcing deprecation so people could consider moving up or at least get them thinking about it. I don't see why this would be a good idea. If someone is using the packaging and assembly plugins to construct a custom server, I am not really interested in telling them they should be using m2 rather than m1. I think it will be pretty obvious our position on a desirable build system when we remove our m1 build: we still need m1 plugins. thanks david jencks Prasad Kashyap wrote: Wait a minute ! Wait a minute ! Except for the deployment plugin, who else outside Geronimo uses our other plugins ? Why do we need to support those plugins to run in an M1 environment even after we have completely m2-ized our uild ? Cheers Prasad On 3/20/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: M1 plugins are being kept around for people who want to continue using M1. +1 to option 3 Cheers Anita --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: Ah.. gotcha. So the existing m1 plugins will continue to exist but be built using the M2 build process. We should also migrate the plugin such that it can e used (invoked) in an M2 environment. That would mean making mojos out of them. Does it also mean leave the old groupid & artifactid for the m1 plugins as is ? How will that fit in with our strategy of our pom restructuring discussed in Geronimo-1755. Cheers Prasad On 3/20/06, John Sisson <[EMAIL PROTECTED]> wrote: Jacek Laskowski wrote: 2006/3/20, Prasad Kashyap <[EMAIL PROTECTED]>: As we start migrating the plugins, where do we drop them ? [ ] Option 1: create a new directory for m2 plugins. (eg. geronimo/m2-plugins). Drop m2 plugins here. In the future, delete existing geronimo/plugins and rename the m2-plugins to plugins. [ ] Option 2: drop m2 plugins in the same directories as their m1 counterparts. The m2 code will be in a different package structure. The m2 artifact will have a different groupid. Ensure different jars get built. Live with the harmless possibility of the m1 jar carrying m2 classes and vice-versa. [X] Option 3: It's a mixture of Option 1 and Option 2, i.e. create a new directory for m2 plugins *and* support them as well as the m1 plugins. Although it's technically possible to do Option 2, it may not be very user- and developer- friendly. Let's keep these two plugin flavours separated. I think m2-plugins is good enough to get us started. +1 to Option 3 John Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Migrating geronimo-plugins to M2
On Mar 21, 2006, at 5:25 AM, Prasad Kashyap wrote: Wait a minute ! Wait a minute ! Except for the deployment plugin, who else outside Geronimo uses our other plugins ? Why do we need to support those plugins to run in an M1 environment even after we have completely m2-ized our uild ? The packaging plugin is currently the only "offline deployer". The assembly plugin can be used to construct a customized server containing your app(s) and just the modules it needs. While both of these could use a lot of improvement, we need to support this functionality on m1, m2, and ant as well as the command line. We need to find a way to use the same code for all of these build environments. thanks david jencks Cheers Prasad On 3/20/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: M1 plugins are being kept around for people who want to continue using M1. +1 to option 3 Cheers Anita --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: Ah.. gotcha. So the existing m1 plugins will continue to exist but be built using the M2 build process. We should also migrate the plugin such that it can e used (invoked) in an M2 environment. That would mean making mojos out of them. Does it also mean leave the old groupid & artifactid for the m1 plugins as is ? How will that fit in with our strategy of our pom restructuring discussed in Geronimo-1755. Cheers Prasad On 3/20/06, John Sisson <[EMAIL PROTECTED]> wrote: Jacek Laskowski wrote: 2006/3/20, Prasad Kashyap <[EMAIL PROTECTED]>: As we start migrating the plugins, where do we drop them ? [ ] Option 1: create a new directory for m2 plugins. (eg. geronimo/m2-plugins). Drop m2 plugins here. In the future, delete existing geronimo/plugins and rename the m2-plugins to plugins. [ ] Option 2: drop m2 plugins in the same directories as their m1 counterparts. The m2 code will be in a different package structure. The m2 artifact will have a different groupid. Ensure different jars get built. Live with the harmless possibility of the m1 jar carrying m2 classes and vice-versa. [X] Option 3: It's a mixture of Option 1 and Option 2, i.e. create a new directory for m2 plugins *and* support them as well as the m1 plugins. Although it's technically possible to do Option 2, it may not be very user- and developer- friendly. Let's keep these two plugin flavours separated. I think m2-plugins is good enough to get us started. +1 to Option 3 John Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-1757) rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction
[ http://issues.apache.org/jira/browse/GERONIMO-1757?page=all ] Lin Sun updated GERONIMO-1757: -- Attachment: G1757.patch > rarRelativePath is not set correctly cause showplan.jsp displayswrong > instruction > - > > Key: GERONIMO-1757 > URL: http://issues.apache.org/jira/browse/GERONIMO-1757 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.x > Environment: winXP > Reporter: Lin Sun > Priority: Minor > Attachments: G1757.patch > > Portions of this is working in version 1.0 but broken after 1/25's change of > DatabasePoolPortlet.java. > Problem: > At the show database plan page, you see the following instructions and the > rarRelativePath is wrong. Should be > repository/tranql/rars/tranql-connector-1.1.rar > Deploy Command: > To deploy a database pool from the command line using this plan, copy and > paste it to a file (say, plan-file.xml) and save it. Then run a command like: > cd GERONIMO_HOME > java -jar bin/deployer.jar deploy plan-file.xml \ > tranql-connector-1.1.rar > Debug: > I printed the value of base and path (value of > PortletManager.getRepositoryEntry(renderRequest, data.getRarPath()).getPath()) > ***linsun***path: /C:/ag10/repository/tranql/rars/tranql-connector-1.1.rar > ***linsun***base: C:\ag10 > ***linsun***rarRelativePath: tranql-connector-1.1.rar > Also, If the server is installed onto a directory that contains space, for > example c:\program files, the path needs to be decoded using URLDecode. For > example, here's the output: > ***linsun***path: > /C:/program%20files/ag10/repository/tranql/rars/tranql-connector-1.1.rar > ***linsun***base: C:\program files\ag10 > ***linsun***rarRelativePath: tranql-connector-1.1.rar > patch will be attached shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1757) rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction
[ http://issues.apache.org/jira/browse/GERONIMO-1757?page=all ] Lin Sun updated GERONIMO-1757: -- Description: Portions of this is working in version 1.0 but broken after 1/25's change of DatabasePoolPortlet.java. Problem: At the show database plan page, you see the following instructions and the rarRelativePath is wrong. Should be repository/tranql/rars/tranql-connector-1.1.rar Deploy Command: To deploy a database pool from the command line using this plan, copy and paste it to a file (say, plan-file.xml) and save it. Then run a command like: cd GERONIMO_HOME java -jar bin/deployer.jar deploy plan-file.xml \ tranql-connector-1.1.rar Debug: I printed the value of base and path (value of PortletManager.getRepositoryEntry(renderRequest, data.getRarPath()).getPath()) ***linsun***path: /C:/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar Also, If the server is installed onto a directory that contains space, for example c:\program files, the path needs to be decoded using URLDecode. For example, here's the output: ***linsun***path: /C:/program%20files/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\program files\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar patch will be attached shortly was: Portions of this is working in version 1.0 but broken after 1/25's change of DatabasePoolPortlet.java. Problem: At the show database plan page, you see the following instructions and the rarRelativePath is wrong. Should be repository/tranql/rars/tranql-connector-1.1.rar Deploy Command: To deploy a database pool from the command line using this plan, copy and paste it to a file (say, plan-file.xml) and save it. Then run a command like: cd GERONIMO_HOME java -jar bin/deployer.jar deploy plan-file.xml \ tranql-connector-1.1.rar Debug: I printed the value of base and path (value of PortletManager.getRepositoryEntry(renderRequest, data.getRarPath()).getPath()) ***linsun***path: /C:/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar Also, If the server is installed onto a directory that contains space, for example c:\program files, the path needs to be decoded using URLDecode. For example, here's the output: ***linsun***path: /C:/program%files/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\program files\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar patch will be attached shortly > rarRelativePath is not set correctly cause showplan.jsp displayswrong > instruction > - > > Key: GERONIMO-1757 > URL: http://issues.apache.org/jira/browse/GERONIMO-1757 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.x > Environment: winXP > Reporter: Lin Sun > Priority: Minor > Attachments: G1757.patch > > Portions of this is working in version 1.0 but broken after 1/25's change of > DatabasePoolPortlet.java. > Problem: > At the show database plan page, you see the following instructions and the > rarRelativePath is wrong. Should be > repository/tranql/rars/tranql-connector-1.1.rar > Deploy Command: > To deploy a database pool from the command line using this plan, copy and > paste it to a file (say, plan-file.xml) and save it. Then run a command like: > cd GERONIMO_HOME > java -jar bin/deployer.jar deploy plan-file.xml \ > tranql-connector-1.1.rar > Debug: > I printed the value of base and path (value of > PortletManager.getRepositoryEntry(renderRequest, data.getRarPath()).getPath()) > ***linsun***path: /C:/ag10/repository/tranql/rars/tranql-connector-1.1.rar > ***linsun***base: C:\ag10 > ***linsun***rarRelativePath: tranql-connector-1.1.rar > Also, If the server is installed onto a directory that contains space, for > example c:\program files, the path needs to be decoded using URLDecode. For > example, here's the output: > ***linsun***path: > /C:/program%20files/ag10/repository/tranql/rars/tranql-connector-1.1.rar > ***linsun***base: C:\program files\ag10 > ***linsun***rarRelativePath: tranql-connector-1.1.rar > patch will be attached shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-358) NullPointerException in WSIFMarshaller.isSimpleType()
NullPointerException in WSIFMarshaller.isSimpleType() - Key: SM-358 URL: http://jira.activemq.org/jira//browse/SM-358 Project: ServiceMix Type: Bug Reporter: Ken Berthelot Attachments: WSIFMarshaler.java There is a logic flaw in WSIFMarshaller.isSimpleType() that causes a NullPointerException for wsdl messages that use complex types. The current logic assumes the existence of a "type" attribute for the "part" element. (e.g. ). For messages that use complex types, the "element" attribute is used in place of the "type" attribute. (e.g. ). The following code results in a NullPointerException for complex types: QName typeName = part.getTypeName(); return "http://www.w3.org/2001/XMLSchema".equals(typeName.getNamespaceURI()); I've attached a patch that checks for typeName == null. The resulting code will return false for any case except where "http://www.w3.org/2001/XMLSchema".equals(typeName.getNamespaceURI(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: m2: geronimo-packaging-plugin
On Mar 21, 2006, at 7:13 AM, anita kulshreshtha wrote: David J, This is one of goals from the packaging plugin. I need some insight into this : Is this still needed? In principle, yes. It may be necessary to hard-code the dependencies/ imports until the transitive dependencies of all modules are further stabilized. This is likely to have a problem similar to the dependency plugin, but I haven't thought through whether or not it actually does :-) I would start by including all dependencies and sorting them into imports and dependencies based on their type. If this gets too far from what the m1 plugin generates we could check in the dependencies/ imports from the m1 output and revisit this when we merge 1.1 into trunk. thanks david jencks Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-1757) rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction
rarRelativePath is not set correctly cause showplan.jsp displayswrong instruction - Key: GERONIMO-1757 URL: http://issues.apache.org/jira/browse/GERONIMO-1757 Project: Geronimo Type: Bug Components: console Versions: 1.x Environment: winXP Reporter: Lin Sun Priority: Minor Portions of this is working in version 1.0 but broken after 1/25's change of DatabasePoolPortlet.java. Problem: At the show database plan page, you see the following instructions and the rarRelativePath is wrong. Should be repository/tranql/rars/tranql-connector-1.1.rar Deploy Command: To deploy a database pool from the command line using this plan, copy and paste it to a file (say, plan-file.xml) and save it. Then run a command like: cd GERONIMO_HOME java -jar bin/deployer.jar deploy plan-file.xml \ tranql-connector-1.1.rar Debug: I printed the value of base and path (value of PortletManager.getRepositoryEntry(renderRequest, data.getRarPath()).getPath()) ***linsun***path: /C:/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar Also, If the server is installed onto a directory that contains space, for example c:\program files, the path needs to be decoded using URLDecode. For example, here's the output: ***linsun***path: /C:/program%files/ag10/repository/tranql/rars/tranql-connector-1.1.rar ***linsun***base: C:\program files\ag10 ***linsun***rarRelativePath: tranql-connector-1.1.rar patch will be attached shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to work properly
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35865 ] Kevin Yaussy commented on AMQ-643: -- I'll try this out tomorrow after the SNAPSHOT build. > maxInactivityDuration does not seem to work properly > > > Key: AMQ-643 > URL: http://jira.activemq.org/jira//browse/AMQ-643 > Project: ActiveMQ > Type: Bug > Components: Connector > Versions: 4.0 RC1 > Environment: AMQ 4 03/17/2006 SNAPSHOT > Solaris 8, 10 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.0 RC1 > Attachments: amq1.xml, amq2.xml > > > AMQ 4 03/17/2006 SNAPSHOT > Using maxInactivityDuration causes a connection to automatically break after > the inactivity duration, even though nothing is wrong with either side of the > connection. > Tracing it through, it looks like the KeepAliveInfo command does not require > a response. This means that the KeepAlive sent never results in receive > activity. So, if both processes are perfectly fine, just not sending any > data, the connection breaks due to InactivityMonitor.readCheck. > I've changed KeepAliveInfo.java to return true for isResponseRequired. This > seems to fix the problem, from a client perspective, anyway. > However, if this is used for broker-to-broker connections, and you force a > problem with one of the brokers (like doing pstop on Solaris), major problems > will happen: > 1) The broker that is left alone seems to break the connection. But, it > continues to attempt to send messages to the failed broker. It was mentioned > in the forum at one point you were going to have the broker unregister > subscriptions so it would not attempt to send messages to the failed broker. > Doesn't seem like this is in place. > 2) If you reawaken the pstopped broker, the two brokers never really recover > properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating geronimo-plugins to M2
Matt Hogstrom wrote: > Sorry if this has been mentioned. Would it make sense to put out an > informational message in the M1 plugins announcing deprecation so people > could consider moving up or at least get them thinking about it. > This is a good idea. > Prasad Kashyap wrote: >> Wait a minute ! Wait a minute ! >> >> Except for the deployment plugin, who else outside Geronimo uses our >> other plugins ? Why do we need to support those plugins to run in an >> M1 environment even after we have completely m2-ized our uild ? >> >> Cheers >> Prasad >> >> On 3/20/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: >> >>> M1 plugins are being kept around for people who >>> want to continue using M1. >>> +1 to option 3 >>> >>> Cheers >>> Anita >>> >>> --- Prasad Kashyap <[EMAIL PROTECTED]> >>> wrote: >>> >>> Ah.. gotcha. So the existing m1 plugins will continue to exist but be built using the M2 build process. We should also migrate the plugin such that it can e used (invoked) in an M2 environment. That would mean making mojos out of them. Does it also mean leave the old groupid & artifactid for the m1 plugins as is ? How will that fit in with our strategy of our pom restructuring discussed in Geronimo-1755. Cheers Prasad On 3/20/06, John Sisson <[EMAIL PROTECTED]> wrote: > Jacek Laskowski wrote: > >> 2006/3/20, Prasad Kashyap <[EMAIL PROTECTED]>: >> >>> As we start migrating the plugins, where do we drop them ? >>> [ ] Option 1: create a new directory for m2 plugins. (eg. >>> geronimo/m2-plugins). Drop m2 plugins here. In the future, delete >>> existing geronimo/plugins and rename the m2-plugins to plugins. >>> [ ] Option 2: drop m2 plugins in the same directories as their m1 >>> counterparts. The m2 code will be in a different package structure. >>> The m2 artifact will have a different groupid. Ensure different jars >>> get built. Live with the harmless possibility of the m1 jar carrying >>> m2 classes and vice-versa. >>> >>> >> >> [X] Option 3: It's a mixture of Option 1 and Option 2, i.e. create a >> new directory for m2 plugins *and* support them as well as the m1 >> plugins. Although it's technically possible to do Option 2, it may not >> be very user- and developer- friendly. Let's keep these two plugin >> flavours separated. I think m2-plugins is good enough to get us >> started. >> >> > > +1 to Option 3 > > John > >>> Prasad >>> >> >> Jacek >> >> -- >> Jacek Laskowski >> http://www.laskowski.org.pl >> >> > > >>> >>> __ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >> >> >> >>
[jira] Commented: (AMQ-632) TaskRunnerFactory from broker is not carried along to Broker-to-Broker connections
[ http://jira.activemq.org/jira//browse/AMQ-632?page=comments#action_35863 ] Kevin Yaussy commented on AMQ-632: -- I'll try this on my end tomorrow after the SNAPSHOT build. > TaskRunnerFactory from broker is not carried along to Broker-to-Broker > connections > -- > > Key: AMQ-632 > URL: http://jira.activemq.org/jira//browse/AMQ-632 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 RC1 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.0 RC1 > Attachments: VMTransportFactory.java > > > When trying to enable dispatchAsync for broker-to-broker connections (which, > since I've not found a way to configure demandForwardingBridge in the broker > XML, I had to hard code by setting the default value of dispatchAsync in > DemandForwardingBridge.java), I found that the TaskRunnerFactory from the > broker was not being carried through to the Network connections. > I'm not sure if the way I fixed it is fully acceptable or not, however the > attached VMTransportFactory.java seems to fix the issue. I changed > doCompositeConnect to call setTaskRunnerFactory on the newly created > TransportConnector. > The change is against SNAPSHOT 03/14/2006. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-632) TaskRunnerFactory from broker is not carried along to Broker-to-Broker connections
[ http://jira.activemq.org/jira//browse/AMQ-632?page=all ] Hiram Chirino resolved AMQ-632: --- Resolution: Fixed patch committed. > TaskRunnerFactory from broker is not carried along to Broker-to-Broker > connections > -- > > Key: AMQ-632 > URL: http://jira.activemq.org/jira//browse/AMQ-632 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 RC1 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.0 RC1 > Attachments: VMTransportFactory.java > > > When trying to enable dispatchAsync for broker-to-broker connections (which, > since I've not found a way to configure demandForwardingBridge in the broker > XML, I had to hard code by setting the default value of dispatchAsync in > DemandForwardingBridge.java), I found that the TaskRunnerFactory from the > broker was not being carried through to the Network connections. > I'm not sure if the way I fixed it is fully acceptable or not, however the > attached VMTransportFactory.java seems to fix the issue. I changed > doCompositeConnect to call setTaskRunnerFactory on the newly created > TransportConnector. > The change is against SNAPSHOT 03/14/2006. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to work properly
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35864 ] Hiram Chirino commented on AMQ-643: --- The change has been commited. You now configure the maxInactivityDuration on the wireFormat. So on tcp connection, it would look like: tcp://localhost:61616?wireFormat.maxInactivityDuration=1 > maxInactivityDuration does not seem to work properly > > > Key: AMQ-643 > URL: http://jira.activemq.org/jira//browse/AMQ-643 > Project: ActiveMQ > Type: Bug > Components: Connector > Versions: 4.0 RC1 > Environment: AMQ 4 03/17/2006 SNAPSHOT > Solaris 8, 10 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.0 RC1 > Attachments: amq1.xml, amq2.xml > > > AMQ 4 03/17/2006 SNAPSHOT > Using maxInactivityDuration causes a connection to automatically break after > the inactivity duration, even though nothing is wrong with either side of the > connection. > Tracing it through, it looks like the KeepAliveInfo command does not require > a response. This means that the KeepAlive sent never results in receive > activity. So, if both processes are perfectly fine, just not sending any > data, the connection breaks due to InactivityMonitor.readCheck. > I've changed KeepAliveInfo.java to return true for isResponseRequired. This > seems to fix the problem, from a client perspective, anyway. > However, if this is used for broker-to-broker connections, and you force a > problem with one of the brokers (like doing pstop on Solaris), major problems > will happen: > 1) The broker that is left alone seems to break the connection. But, it > continues to attempt to send messages to the failed broker. It was mentioned > in the forum at one point you were going to have the broker unregister > subscriptions so it would not attempt to send messages to the failed broker. > Doesn't seem like this is in place. > 2) If you reawaken the pstopped broker, the two brokers never really recover > properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
m2: geronimo-packaging-plugin
David J, This is one of goals from the packaging plugin. I need some insight into this : Is this still needed? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1754) Add GBeans for configuring NNTPTransport and NNTPStore access
[ http://issues.apache.org/jira/browse/GERONIMO-1754?page=comments#action_12371240 ] Rick McGuire commented on GERONIMO-1754: Some notes: > * @version should be @version $Rev$ $Date$ Noted for the future. > * I didn't think *.orig files should have been committed, too, should they? No they shouldn't have. I don't see any .orig files in the patch. Where did they come from? > * Copyright in the new files should be 2006 Grrr, forgot to change that in the last file I created. Sorry. > Add GBeans for configuring NNTPTransport and NNTPStore access > - > > Key: GERONIMO-1754 > URL: http://issues.apache.org/jira/browse/GERONIMO-1754 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Attachments: GERONIMO-1754.patch, GERONIMO-1754B.patch, GERONIMO-1754B.patch > > The Geronimo Mail support has GBeans for configuring each of the javamail > protocols (SMTP, POP3, IMAP), but the Geronimo javamail implemenation now has > support for nntp and nntp-post protocols, so additional GBeans are needed for > the new protocols. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating geronimo-plugins to M2
Sorry if this has been mentioned. Would it make sense to put out an informational message in the M1 plugins announcing deprecation so people could consider moving up or at least get them thinking about it. Prasad Kashyap wrote: Wait a minute ! Wait a minute ! Except for the deployment plugin, who else outside Geronimo uses our other plugins ? Why do we need to support those plugins to run in an M1 environment even after we have completely m2-ized our uild ? Cheers Prasad On 3/20/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: M1 plugins are being kept around for people who want to continue using M1. +1 to option 3 Cheers Anita --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: Ah.. gotcha. So the existing m1 plugins will continue to exist but be built using the M2 build process. We should also migrate the plugin such that it can e used (invoked) in an M2 environment. That would mean making mojos out of them. Does it also mean leave the old groupid & artifactid for the m1 plugins as is ? How will that fit in with our strategy of our pom restructuring discussed in Geronimo-1755. Cheers Prasad On 3/20/06, John Sisson <[EMAIL PROTECTED]> wrote: Jacek Laskowski wrote: 2006/3/20, Prasad Kashyap <[EMAIL PROTECTED]>: As we start migrating the plugins, where do we drop them ? [ ] Option 1: create a new directory for m2 plugins. (eg. geronimo/m2-plugins). Drop m2 plugins here. In the future, delete existing geronimo/plugins and rename the m2-plugins to plugins. [ ] Option 2: drop m2 plugins in the same directories as their m1 counterparts. The m2 code will be in a different package structure. The m2 artifact will have a different groupid. Ensure different jars get built. Live with the harmless possibility of the m1 jar carrying m2 classes and vice-versa. [X] Option 3: It's a mixture of Option 1 and Option 2, i.e. create a new directory for m2 plugins *and* support them as well as the m1 plugins. Although it's technically possible to do Option 2, it may not be very user- and developer- friendly. Let's keep these two plugin flavours separated. I think m2-plugins is good enough to get us started. +1 to Option 3 John Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1754) Add GBeans for configuring NNTPTransport and NNTPStore access
[ http://issues.apache.org/jira/browse/GERONIMO-1754?page=comments#action_12371238 ] Jacek Laskowski commented on GERONIMO-1754: --- Committed revision 387533. Thanks Rick! Some notes: * @version should be @version $Rev$ $Date$ * I didn't think *.orig files should have been committed, too, should they? * Copyright in the new files should be 2006 > Add GBeans for configuring NNTPTransport and NNTPStore access > - > > Key: GERONIMO-1754 > URL: http://issues.apache.org/jira/browse/GERONIMO-1754 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Attachments: GERONIMO-1754.patch, GERONIMO-1754B.patch, GERONIMO-1754B.patch > > The Geronimo Mail support has GBeans for configuring each of the javamail > protocols (SMTP, POP3, IMAP), but the Geronimo javamail implemenation now has > support for nntp and nntp-post protocols, so additional GBeans are needed for > the new protocols. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-643) maxInactivityDuration does not seem to work properly
[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35861 ] Kevin Yaussy commented on AMQ-643: -- However, that sounds like both sides would still have to explicitly make the setting, right? > maxInactivityDuration does not seem to work properly > > > Key: AMQ-643 > URL: http://jira.activemq.org/jira//browse/AMQ-643 > Project: ActiveMQ > Type: Bug > Components: Connector > Versions: 4.0 RC1 > Environment: AMQ 4 03/17/2006 SNAPSHOT > Solaris 8, 10 > Reporter: Kevin Yaussy > Assignee: Hiram Chirino > Fix For: 4.0 RC1 > Attachments: amq1.xml, amq2.xml > > > AMQ 4 03/17/2006 SNAPSHOT > Using maxInactivityDuration causes a connection to automatically break after > the inactivity duration, even though nothing is wrong with either side of the > connection. > Tracing it through, it looks like the KeepAliveInfo command does not require > a response. This means that the KeepAlive sent never results in receive > activity. So, if both processes are perfectly fine, just not sending any > data, the connection breaks due to InactivityMonitor.readCheck. > I've changed KeepAliveInfo.java to return true for isResponseRequired. This > seems to fix the problem, from a client perspective, anyway. > However, if this is used for broker-to-broker connections, and you force a > problem with one of the brokers (like doing pstop on Solaris), major problems > will happen: > 1) The broker that is left alone seems to break the connection. But, it > continues to attempt to send messages to the failed broker. It was mentioned > in the forum at one point you were going to have the broker unregister > subscriptions so it would not attempt to send messages to the failed broker. > Doesn't seem like this is in place. > 2) If you reawaken the pstopped broker, the two brokers never really recover > properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ http://jira.activemq.org/jira//browse/AMQ-531?page=comments#action_35860 ] Hiram Chirino commented on AMQ-531: --- While the jarjar would resolve the binary compatability issues, it would break folks who make use of spring objects in the spring.xml > XBean has a runtime issue with Spring 2.0M2 > --- > > Key: AMQ-531 > URL: http://jira.activemq.org/jira//browse/AMQ-531 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Environment: Spring 2.0M2 > Reporter: Ben Hale > Assignee: james strachan > Fix For: 4.0 RC1 > > > Apparently there is an issue with XBean now that Spring 2.0 (starting with > M2) is compiled against a Java 5 compiler > (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating > how long before XBean releases a fix and postponing the 4.0 release until > they do. If not, at least documenting in a known issues list that ActiveMQ > 4.0 can't working with 2.0M2 and later until a later release where they do > fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating geronimo-plugins to M2
Hmm.. ok. Didn't think others would be doing geronimo builds too. But I understand we can't discount that possibility. Cool. Thanks for your patience Jacek :-) So, what shall we do with the groupid and artifactid of the m1 plugins ? Keep it same ? Cheers Prasad On 3/21/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > 2006/3/21, Prasad Kashyap <[EMAIL PROTECTED]>: > > Wait a minute ! Wait a minute ! > > Hi Prasad, > > ...after a couple of minutes... > > > Except for the deployment plugin, who else outside Geronimo uses our > > other plugins ? > > I don't know, you don't know, but we can't just stop supporting it > because of our belief noone *might* not be using it. There're many > companies using M1 and don't think they'll be moving to M2 soon, not > that soon. > > > Why do we need to support those plugins to run in an > > M1 environment even after we have completely m2-ized our uild ? > > There're two different matters - build and runtime. We can build the > plugins with M2, but they will be useable in M1. We could also build > the M2 plugins with M1. What a final product support doesn't relate > how it's built, does it? > > > Prasad > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.org.pl >
Re: Migrating geronimo-plugins to M2
2006/3/21, Prasad Kashyap <[EMAIL PROTECTED]>: > Hmm.. ok. Didn't think others would be doing geronimo builds too. But > I understand we can't discount that possibility. Not necessarily. They might be using Geronimo in ways we can't yet even anticipate and the plugins help to build *their* solutions. > So, what shall we do with the groupid and artifactid of the m1 plugins > ? Keep it same ? I'd not think about it now. Let's convert the plugins to M2 and we'll go back to the question later on. groupIds tell me what version of Maven it's built and able to work with. So, shorter groupIds - geronimo - *might* imply it's M1-wise whereas org.apache.geronimo is M2-wise. In most cases it's true. > Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Commented: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ http://jira.activemq.org/jira//browse/AMQ-531?page=comments#action_35859 ] james strachan commented on AMQ-531: If Spring are not going to maintain binary compatibility with XBean then maybe we should just ship a jar-jar'd version of Spring 1.2.x which is switched into the org.apache.xbean.spring namespace so that folks can still use spring 2.x or later in their own config files, then XBean will use an older version of spring > XBean has a runtime issue with Spring 2.0M2 > --- > > Key: AMQ-531 > URL: http://jira.activemq.org/jira//browse/AMQ-531 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Environment: Spring 2.0M2 > Reporter: Ben Hale > Assignee: james strachan > Fix For: 4.0 RC1 > > > Apparently there is an issue with XBean now that Spring 2.0 (starting with > M2) is compiled against a Java 5 compiler > (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating > how long before XBean releases a fix and postponing the 4.0 release until > they do. If not, at least documenting in a known issues list that ActiveMQ > 4.0 can't working with 2.0M2 and later until a later release where they do > fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Migrating geronimo-plugins to M2
2006/3/21, Prasad Kashyap <[EMAIL PROTECTED]>: > Wait a minute ! Wait a minute ! Hi Prasad, ...after a couple of minutes... > Except for the deployment plugin, who else outside Geronimo uses our > other plugins ? I don't know, you don't know, but we can't just stop supporting it because of our belief noone *might* not be using it. There're many companies using M1 and don't think they'll be moving to M2 soon, not that soon. > Why do we need to support those plugins to run in an > M1 environment even after we have completely m2-ized our uild ? There're two different matters - build and runtime. We can build the plugins with M2, but they will be useable in M1. We could also build the M2 plugins with M1. What a final product support doesn't relate how it's built, does it? > Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Migrating geronimo-plugins to M2
Wait a minute ! Wait a minute ! Except for the deployment plugin, who else outside Geronimo uses our other plugins ? Why do we need to support those plugins to run in an M1 environment even after we have completely m2-ized our uild ? Cheers Prasad On 3/20/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: >M1 plugins are being kept around for people who > want to continue using M1. > +1 to option 3 > > Cheers > Anita > > --- Prasad Kashyap <[EMAIL PROTECTED]> > wrote: > > > Ah.. gotcha. So the existing m1 plugins will > > continue to exist but be > > built using the M2 build process. We should also > > migrate the plugin > > such that it can e used (invoked) in an M2 > > environment. That would > > mean making mojos out of them. > > > > Does it also mean leave the old groupid & artifactid > > for the m1 > > plugins as is ? How will that fit in with our > > strategy of our pom > > restructuring discussed in Geronimo-1755. > > > > Cheers > > Prasad > > > > On 3/20/06, John Sisson <[EMAIL PROTECTED]> wrote: > > > Jacek Laskowski wrote: > > > > 2006/3/20, Prasad Kashyap > > <[EMAIL PROTECTED]>: > > > > > > > > > > > >> As we start migrating the plugins, where do we > > drop them ? > > > >> > > > >> [ ] Option 1: create a new directory for m2 > > plugins. (eg. > > > >> geronimo/m2-plugins). Drop m2 plugins here. In > > the future, delete > > > >> existing geronimo/plugins and rename the > > m2-plugins to plugins. > > > >> > > > >> [ ] Option 2: drop m2 plugins in the same > > directories as their m1 > > > >> counterparts. The m2 code will be in a > > different package structure. > > > >> The m2 artifact will have a different groupid. > > Ensure different jars > > > >> get built. Live with the harmless possibility > > of the m1 jar carrying > > > >> m2 classes and vice-versa. > > > >> > > > >> > > > > > > > > [X] Option 3: It's a mixture of Option 1 and > > Option 2, i.e. create a > > > > new directory for m2 plugins *and* support them > > as well as the m1 > > > > plugins. Although it's technically possible to > > do Option 2, it may not > > > > be very user- and developer- friendly. Let's > > keep these two plugin > > > > flavours separated. I think m2-plugins is good > > enough to get us > > > > started. > > > > > > > > > > > +1 to Option 3 > > > > > > John > > > >> Prasad > > > >> > > > > > > > > Jacek > > > > > > > > -- > > > > Jacek Laskowski > > > > http://www.laskowski.org.pl > > > > > > > > > > > > > > > > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
Re: M2 migration status
2006/3/21, anita kulshreshtha <[EMAIL PROTECTED]>: > I am also getting the same exception. This version > of system properties does not work for me either. Ok, enough! ;) Gonna delete ~/.m2 repo completely and rebuild Geronimo. Will report later. > Anita Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: M2 migration status
Jacek, Prasad I am also getting the same exception. This version of system properties does not work for me either. I am back to where I was on 03/06. Here are the versions I am using : windows xp SP2 C:\Documents and Settings\User>java -version java version "1.4.2_09" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05) Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode) C:\Documents and Settings\User>mvn -v Maven version: 2.0.2 The contents of .m2/repository/maven-metadata-snapshots.xml are org.apache.maven.plugins maven-surefire-plugin 2.1.3-SNAPSHOT 20060228.012944 10 20060228013013 Thanks Anita --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: > The following modules are failing tests with NPE > > 1) security > 2) jetty > 3) tomcat > > [INFO] Trace > java.lang.NullPointerException > at > java.util.Hashtable.put(Ljava.lang.Object;Ljava.lang.Object;)Ljava.lang.Object;(Unknown > Source) > at > java.util.Properties.setProperty(Properties.java:128) > at > java.lang.System.setProperty(Ljava.lang.String;Ljava.lang.String;)Ljava.lang.String;(Unknown > Source) > at > org.apache.maven.test.SurefirePlugin.processSystemProperties(SurefirePlugin.java:408) > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:335) > > 4) axis-builder fails tests. Remove the redudant > surefire plugin and > it works fine. > > 5) tomcat-builder tests fail. > [surefire] Running > org.apache.geronimo.tomcat.deployment.TomcatModuleBuilderTest > Created MBeanServer with ID: > 4bd21901:10a190b5e32:-8000:bharat:1 > Retrieving document at 'WEB-INF/wsdl/hello.wsdl'. > [surefire] Tests run: 2, Failures: 0, Errors: 2, > Time elapsed: 5.778 > sec FAILURE !! > > Cheers > Prasad > > On 3/18/06, anita kulshreshtha <[EMAIL PROTECTED]> > wrote: > > > > > > --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > > > > 2006/3/18, anita kulshreshtha > <[EMAIL PROTECTED]>: > > > > > > >THANKS! It was a pleasure to work on m2 > > > migration > > > > > > was ?!?! I think it still *is* ;) > > Yeah.. The fun will start now, converting all > the > > plugins. I have started looking at the packaging > > plugin. > > > > Thnaks > > Anita > > > > > > > Anita > > > > > > Jacek > > > > > > -- > > > Jacek Laskowski > > > http://www.laskowski.org.pl > > > > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (AMQ-531) XBean has a runtime issue with Spring 2.0M2
[ http://jira.activemq.org/jira//browse/AMQ-531?page=comments#action_35858 ] james strachan commented on AMQ-531: Still looks to be an issue with 2.0-M3 - Spring changed their binary protocol, so unless they provide us a similar hook, the only thing I can see is we'll have to have a special "2.0-M3 or later" version of XBean > XBean has a runtime issue with Spring 2.0M2 > --- > > Key: AMQ-531 > URL: http://jira.activemq.org/jira//browse/AMQ-531 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Environment: Spring 2.0M2 > Reporter: Ben Hale > Assignee: james strachan > Fix For: 4.0 RC1 > > > Apparently there is an issue with XBean now that Spring 2.0 (starting with > M2) is compiled against a Java 5 compiler > (http://jira.codehaus.org/browse/XB-7). It's probably worth investigating > how long before XBean releases a fix and postponing the 4.0 release until > they do. If not, at least documenting in a known issues list that ActiveMQ > 4.0 can't working with 2.0M2 and later until a later release where they do > fix it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1754) Add GBeans for configuring NNTPTransport and NNTPStore access
[ http://issues.apache.org/jira/browse/GERONIMO-1754?page=all ] Rick McGuire updated GERONIMO-1754: --- Attachment: GERONIMO-1754B.patch A patch built on the already committed previous patch that replaces hard coded literal strings in the protocol GBeans with constants. This also adds an SMTPSTransportGBean to complete the set of GBean adaptors for all of the currently supported protocols. > Add GBeans for configuring NNTPTransport and NNTPStore access > - > > Key: GERONIMO-1754 > URL: http://issues.apache.org/jira/browse/GERONIMO-1754 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Attachments: GERONIMO-1754.patch, GERONIMO-1754B.patch > > The Geronimo Mail support has GBeans for configuring each of the javamail > protocols (SMTP, POP3, IMAP), but the Geronimo javamail implemenation now has > support for nntp and nntp-post protocols, so additional GBeans are needed for > the new protocols. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1754) Add GBeans for configuring NNTPTransport and NNTPStore access
[ http://issues.apache.org/jira/browse/GERONIMO-1754?page=all ] Rick McGuire updated GERONIMO-1754: --- Attachment: GERONIMO-1754B.patch Doh! I grabbed a version of the file from the wrong build. This is the one I meant to attach, which I've verified by applying the patch to a fresh checkout. > Add GBeans for configuring NNTPTransport and NNTPStore access > - > > Key: GERONIMO-1754 > URL: http://issues.apache.org/jira/browse/GERONIMO-1754 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Attachments: GERONIMO-1754.patch, GERONIMO-1754B.patch, GERONIMO-1754B.patch > > The Geronimo Mail support has GBeans for configuring each of the javamail > protocols (SMTP, POP3, IMAP), but the Geronimo javamail implemenation now has > support for nntp and nntp-post protocols, so additional GBeans are needed for > the new protocols. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1754) Add GBeans for configuring NNTPTransport and NNTPStore access
[ http://issues.apache.org/jira/browse/GERONIMO-1754?page=comments#action_12371221 ] Jacek Laskowski commented on GERONIMO-1754: --- I've got loads of errors during patching and am wondering how it went on your side? Any idea as to how to proceed? $ svn status ? GERONIMO-1754B.patch [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/mail $ svn info Path: . URL: https://svn.apache.org/repos/asf/geronimo/trunk/modules/mail Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 387517 Node Kind: directory Schedule: normal Last Changed Author: jlaskowski Last Changed Rev: 387218 Last Changed Date: 2006-03-20 16:12:37 +0100 (Mon, 20 Mar 2006) Properties Last Updated: 2005-11-23 09:29:08 +0100 (Wed, 23 Nov 2005) [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/mail $ patch -p0 < GERONIMO-1754B.patch (Stripping trailing CRs from patch.) patching file src/test/org/apache/geronimo/mail/MailGBeanTest.java Hunk #1 FAILED at 140. Hunk #2 FAILED at 242. Hunk #3 FAILED at 263. 3 out of 3 hunks FAILED -- saving rejects to file src/test/org/apache/geronimo/mail/MailGBeanTest.java.rej (Stripping trailing CRs from patch.) patching file src/test/org/apache/geronimo/mail/TestTransport.java Reversed (or previously applied) patch detected! Assume -R? [n] y (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/IMAPStoreGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/SMTPSTransportGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/NNTPStoreGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/NNTPTransportGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/NNTPGBeanConstants.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/POP3StoreGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/SMTPTransportGBean.java (Stripping trailing CRs from patch.) patching file src/java/org/apache/geronimo/mail/ProtocolGBean.java > Add GBeans for configuring NNTPTransport and NNTPStore access > - > > Key: GERONIMO-1754 > URL: http://issues.apache.org/jira/browse/GERONIMO-1754 > Project: Geronimo > Type: New Feature > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Attachments: GERONIMO-1754.patch, GERONIMO-1754B.patch > > The Geronimo Mail support has GBeans for configuring each of the javamail > protocols (SMTP, POP3, IMAP), but the Geronimo javamail implemenation now has > support for nntp and nntp-post protocols, so additional GBeans are needed for > the new protocols. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
