date:20061031

Re: JMS Server portlets broke...

2006-10-31 Thread Jason Dillon


Why on earth is this exception logged as info?!?

--jason


On Oct 31, 2006, at 11:08 PM, Jason Dillon wrote:

Something is wrong with the JMS Server portlet to create new  
connectors... seems like any connector you try to add pukes with:



[INFO] 23:06:11,272 ERROR [JMSConnectorPortlet] Unable to process  
portlet action
[INFO] java.lang.NoClassDefFoundError: org/apache/activemq/broker/ 
BrokerService

[INFO]  at java.lang.Class.getDeclaredMethods0(Native Method)
[INFO]  at java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
[INFO]  at java.lang.Class.getDeclaredMethods(Class.java:1139)
[INFO]  at net.sf.cglib.core.ReflectUtils.addAllMethods 
(ReflectUtils.java:348)

[INFO]  at net.sf.cglib.proxy.Enhancer.getMethods(Enhancer.java:426)
[INFO]  at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java: 
456)
[INFO]  at net.sf.cglib.core.DefaultGeneratorStrategy.generate 
(DefaultGeneratorStrategy.java:25)
[INFO]  at net.sf.cglib.core.AbstractClassGenerator.create 
(AbstractClassGenerator.java:216)

[INFO]  at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
[INFO]  at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
[INFO]  at org.apache.geronimo.kernel.basic.BasicProxyManager 
$ManagedProxyFactory.(BasicProxyManager.java:202)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory( 
BasicProxyManager.java:78)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy 
(BasicProxyManager.java:116)
[INFO]  at  
org.apache.geronimo.console.util.KernelManagementHelper.getObject 
(KernelManagementHelper.java:366)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.getJMSBroker 
(PortletManager.java:274)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.createJMSConnector 
(PortletManager.java:278)
[INFO]  at  
org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.proc 
essAction(JMSConnectorPortlet.java:80)
[INFO]  at org.apache.pluto.core.PortletServlet.dispatch 
(PortletServlet.java:229)
[INFO]  at org.apache.pluto.core.PortletServlet.doGet 
(PortletServlet.java:158)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
688)
[INFO]  at org.apache.pluto.core.PortletServlet.service 
(PortletServlet.java:153)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.dispatch 
(Dispatcher.java:283)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.include 
(Dispatcher.java:163)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke 
(PortletInvokerImpl.java:120)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.action 
(PortletInvokerImpl.java:68)
[INFO]  at  
org.apache.pluto.PortletContainerImpl.processPortletAction 
(PortletContainerImpl.java:164)
[INFO]  at  
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPo 
rtletAction(PortletContainerWrapperImpl.java:82)

[INFO]  at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
688)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.ServletHandler.handle 
(ServletHandler.java:568)

[INFO]  at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationContext.handle 
(WebApplicationContext.java:633)
[INFO]  at org.apache.geronimo.jetty.JettyWebAppContext.handle 
(JettyWebAppContext.java:329)

[INFO]  at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
[INFO]  at org.a

Re: JMS Server portlets broke...

2006-10-31 Thread Jason Dillon

Why doesn't the console reflect these failure messages?  From the  
console you can not tell this operating failed... you just do not see  
any new connector.  Seems highly broken.


--jason


On Oct 31, 2006, at 11:08 PM, Jason Dillon wrote:

Something is wrong with the JMS Server portlet to create new  
connectors... seems like any connector you try to add pukes with:



[INFO] 23:06:11,272 ERROR [JMSConnectorPortlet] Unable to process  
portlet action
[INFO] java.lang.NoClassDefFoundError: org/apache/activemq/broker/ 
BrokerService

[INFO]  at java.lang.Class.getDeclaredMethods0(Native Method)
[INFO]  at java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
[INFO]  at java.lang.Class.getDeclaredMethods(Class.java:1139)
[INFO]  at net.sf.cglib.core.ReflectUtils.addAllMethods 
(ReflectUtils.java:348)

[INFO]  at net.sf.cglib.proxy.Enhancer.getMethods(Enhancer.java:426)
[INFO]  at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java: 
456)
[INFO]  at net.sf.cglib.core.DefaultGeneratorStrategy.generate 
(DefaultGeneratorStrategy.java:25)
[INFO]  at net.sf.cglib.core.AbstractClassGenerator.create 
(AbstractClassGenerator.java:216)

[INFO]  at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
[INFO]  at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
[INFO]  at org.apache.geronimo.kernel.basic.BasicProxyManager 
$ManagedProxyFactory.(BasicProxyManager.java:202)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory( 
BasicProxyManager.java:78)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy 
(BasicProxyManager.java:116)
[INFO]  at  
org.apache.geronimo.console.util.KernelManagementHelper.getObject 
(KernelManagementHelper.java:366)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.getJMSBroker 
(PortletManager.java:274)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.createJMSConnector 
(PortletManager.java:278)
[INFO]  at  
org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.proc 
essAction(JMSConnectorPortlet.java:80)
[INFO]  at org.apache.pluto.core.PortletServlet.dispatch 
(PortletServlet.java:229)
[INFO]  at org.apache.pluto.core.PortletServlet.doGet 
(PortletServlet.java:158)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
688)
[INFO]  at org.apache.pluto.core.PortletServlet.service 
(PortletServlet.java:153)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.dispatch 
(Dispatcher.java:283)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.include 
(Dispatcher.java:163)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke 
(PortletInvokerImpl.java:120)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.action 
(PortletInvokerImpl.java:68)
[INFO]  at  
org.apache.pluto.PortletContainerImpl.processPortletAction 
(PortletContainerImpl.java:164)
[INFO]  at  
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPo 
rtletAction(PortletContainerWrapperImpl.java:82)

[INFO]  at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java: 
688)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.ServletHandler.handle 
(ServletHandler.java:568)

[INFO]  at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationContext.handle 
(WebApplicationContext.java:633)
[INFO]  at org.apache.geronimo.jetty.JettyWebAppC

JMS Server portlets broke...

2006-10-31 Thread Jason Dillon

Something is wrong with the JMS Server portlet to create new  
connectors... seems like any connector you try to add pukes with:



[INFO] 23:06:11,272 ERROR [JMSConnectorPortlet] Unable to process  
portlet action
[INFO] java.lang.NoClassDefFoundError: org/apache/activemq/broker/ 
BrokerService

[INFO]  at java.lang.Class.getDeclaredMethods0(Native Method)
[INFO]  at java.lang.Class.privateGetDeclaredMethods(Class.java:1655)
[INFO]  at java.lang.Class.getDeclaredMethods(Class.java:1139)
[INFO]  at net.sf.cglib.core.ReflectUtils.addAllMethods 
(ReflectUtils.java:348)

[INFO]  at net.sf.cglib.proxy.Enhancer.getMethods(Enhancer.java:426)
[INFO]  at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:456)
[INFO]  at net.sf.cglib.core.DefaultGeneratorStrategy.generate 
(DefaultGeneratorStrategy.java:25)
[INFO]  at net.sf.cglib.core.AbstractClassGenerator.create 
(AbstractClassGenerator.java:216)

[INFO]  at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
[INFO]  at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
[INFO]  at org.apache.geronimo.kernel.basic.BasicProxyManager 
$ManagedProxyFactory.(BasicProxyManager.java:202)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory 
(BasicProxyManager.java:78)
[INFO]  at  
org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy 
(BasicProxyManager.java:116)
[INFO]  at  
org.apache.geronimo.console.util.KernelManagementHelper.getObject 
(KernelManagementHelper.java:366)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.getJMSBroker 
(PortletManager.java:274)
[INFO]  at  
org.apache.geronimo.console.util.PortletManager.createJMSConnector 
(PortletManager.java:278)
[INFO]  at  
org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.proces 
sAction(JMSConnectorPortlet.java:80)
[INFO]  at org.apache.pluto.core.PortletServlet.dispatch 
(PortletServlet.java:229)
[INFO]  at org.apache.pluto.core.PortletServlet.doGet 
(PortletServlet.java:158)

[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
[INFO]  at org.apache.pluto.core.PortletServlet.service 
(PortletServlet.java:153)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.dispatch 
(Dispatcher.java:283)
[INFO]  at org.mortbay.jetty.servlet.Dispatcher.include 
(Dispatcher.java:163)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke 
(PortletInvokerImpl.java:120)
[INFO]  at org.apache.pluto.invoker.impl.PortletInvokerImpl.action 
(PortletInvokerImpl.java:68)
[INFO]  at org.apache.pluto.PortletContainerImpl.processPortletAction 
(PortletContainerImpl.java:164)
[INFO]  at  
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPort 
letAction(PortletContainerWrapperImpl.java:82)

[INFO]  at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
[INFO]  at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
[INFO]  at org.mortbay.jetty.servlet.ServletHolder.handle 
(ServletHolder.java:428)
[INFO]  at org.apache.geronimo.jetty.JettyServletHolder.handle 
(JettyServletHolder.java:103)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:830)
[INFO]  at org.mortbay.jetty.servlet.JSR154Filter.doFilter 
(JSR154Filter.java:170)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler 
$CachedChain.doFilter(WebApplicationHandler.java:821)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch 
(WebApplicationHandler.java:471)
[INFO]  at  
org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch 
(JettyWebApplicationHandler.java:58)
[INFO]  at org.mortbay.jetty.servlet.ServletHandler.handle 
(ServletHandler.java:568)

[INFO]  at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
[INFO]  at org.mortbay.jetty.servlet.WebApplicationContext.handle 
(WebApplicationContext.java:633)
[INFO]  at org.apache.geronimo.jetty.JettyWebAppContext.handle 
(JettyWebAppContext.java:329)

[INFO]  at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
[INFO]  at org.apache.geronimo.jetty.JettyWebAppContext.handle 
(JettyWebAppContext.java:313)

[INFO]  at org.mortbay.http.HttpServer.servi

Re: Why is the activemq.car using the tcp transport?

2006-10-31 Thread Jason Dillon

Do client-side consumers use the activemq.car?  I really don't know  
where this is used... if it is for clients, then I can understand...  
but if this is only used in the server, then it should use the vm://  
transport for efficiency.


--jason


On Oct 31, 2006, at 9:55 PM, Bruce Snyder wrote:


On 10/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Its currently configured with:

tcp://$ 
{PlanServerHostname}:

${PlanActiveMQPort}

If this resourceadapter is used with in the server, then it should
use the vm:// transport.

Anyone know?


I'm not sure, but I hazard a guess that this was so that client-side
consumers can connect to ActiveMQ. If a vm:// transport is used, then
ActiveMQ is not exposed outside the JVM.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61EG;6%I;\"YC;VT*"

);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Problem with latest 4.1 SNAPSHOT when broker name is set

2006-10-31 Thread Jason Dillon

Folks, there is a problem with the latest 4.1 SNAPSHOT when a broker  
name is set.  It causes 2 brokers to be created... and I think it is  
because of the newly added CommandAgent service which is added to the  
brokers default services when started.  It is using vm://localhost,  
which appears to be creating a new Broker using the name "localhost"  
when the broker it is attached to has a different name.


For example:


BrokerService broker = new BrokerService();
broker.setBrokerName("foo");
broker.start();


Will end up creating a broker name "foo" and then another named  
"localhost".


Where, this will create one broker, named "localhost":


BrokerService broker = new BrokerService();
broker.start();


I'm not really sure how vm://* works with respect to broker names...  
so I can not say for sure what the fix is, or why this is happening.   
But I can say for sure that the above snips create 2 and 1 brokers  
respectively.


We noticed this while trying to track down a rouge activemq-data  
directory which kept popping up in Geronimo, which for some reason  
had its broker gbean set to create a broker with the name "possibly- 
unique-broker".  I've fixed this by only setting the broker name if  
it is non-null, and then commenting out the brokerName attributed in  
the plan, but something is definitely broke on your side of the fence  
wrt broker names and vm:// transports.


--jason

Re: Why is the activemq.car using the tcp transport?

2006-10-31 Thread Bruce Snyder


On 10/31/06, Jason Dillon <[EMAIL PROTECTED]> wrote:

Its currently configured with:

tcp://${PlanServerHostname}:
${PlanActiveMQPort}

If this resourceadapter is used with in the server, then it should
use the vm:// transport.

Anyone know?


I'm not sure, but I hazard a guess that this was so that client-side
consumers can connect to ActiveMQ. If a vm:// transport is used, then
ActiveMQ is not exposed outside the JVM.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/

Why is the activemq.car using the tcp transport?

2006-10-31 Thread Jason Dillon


Its currently configured with:

tcp://${PlanServerHostname}: 
${PlanActiveMQPort}


If this resourceadapter is used with in the server, then it should  
use the vm:// transport.


Anyone know?

--jason

Re: 1.2 Fit and Finish

2006-10-31 Thread Dain Sundstrom


On Oct 31, 2006, at 4:25 AM, Aaron Mulder wrote:


I would say that the startup and shutdown sequences should not show
any Log4J log output or stack traces, tested under both JDK 1.4 and
JDK 1.5.


I fixed some of the amq logging problems today (their package name  
changed so log4j needed updating).  Yet again, ActiveMQ is logging  
exceptions at shutdown which are not real problems.  I sent an email  
to the amq list but who knows if they will fix them.



Also, all current functionality in all portlets in the
console should work as expected.  And the deploy tool should be able
to deploy, undeploy, and redeploy all J2EE module types, with no
module ID in the plan, a versionless module ID, a module ID with only
an artifact ID, or no plan at all.


Are you going to verify these?  If you are, please do it sooner  
rather then later.


-dain

Re: 1.2 Fit and Finish

2006-10-31 Thread Dain Sundstrom


On Oct 31, 2006, at 6:13 AM, Kevan Miller wrote:

IMO, fixing the startup time of the web console config under jetty  
(see GERONIMO-2507) is a must fix...


Does that mean you are going to fix it?

-dain

More car-maven-plugin changes...

2006-10-31 Thread Jason Dillon

Well, I discovered that the car plugin was still caching old bits  
when car:install-modules was run.  And I dug into it much deeper than  
I wanted to and eventually ended up re-writing the installation of  
artifacts.


It should now try a heck of a lot harder to reinstall bits that have  
changed.  When installing modules, we check the sha1 of the configs,  
if they are the same, then we skip re-installing, but now we will  
continue to process the module's deps.


Deps are now checked if they need to be reinstalled, instead of just  
skipping.  If the source dep's file size has changed, or  the last  
modified time is greater than the target, we reinstall it.


Also now we are tracking all installed artifacts so we can easily  
skip ones we know that we have processed already, which speeds things  
up a itty bit.


And, I have added info logging when a dependency is installed, so now  
you can see what is really being installed.  Debug logging with `mvn - 
X` will show the bits that are skipped and when they are being  
reinstalled, blah, blah.  The side effect is that when a lot changes,  
then a lot of info logs are spit out for each dependency oh well.


I did a little bit of testing and it does appear that when something  
from modules/* changes (and nothing else) that only that one  
dependency will get copied into the Geronimo repository and  
similarly if just one configs/* changes, then just that one module  
will be re-installed.


 * * *

I think the one last thing might be that car:install-modules may need  
to use the Maven2RepositoryAdapter bits which I hacked into  
car:package to resolve SNAPSHOT artifacts directly using the Maven  
API... but I am not sure yet... and I'd rather not hack more of this  
in.  But if I refactor it into less of a hack I might.


Anyways... *please* give it a whirl.  I've pushed out the latest car- 
maven-plugin SNAPSHOT with all these fixes.


Next I guess we should try to make the car:package skip re-packaging  
unless something has really changed... but that is gonna be tricky,  
as we need to check the target/** and the effective pom.xml to see if  
anything has changed... ugh :-(


Then once we re-organize these modules into related groups it might  
be much easier to run small builds from specific trees, and then re- 
assembly to validate (ie. all activemq modules and configs all under  
one geronimo-activemq/* tree).


--jason

[jira] Updated: (GERONIMO-2478) ContextForwardServlet should have a registration mechanism

2006-10-31 Thread Aaron Mulder (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2478?page=all ]

Aaron Mulder updated GERONIMO-2478:
---

Description: 
Currently the ContextForwardServlet must be deployed separately for each URL 
path to redirect.

This does not work well for plugins, nor will it work well for a more 
fine-grained console composed of multiple optional bits of functionality.

Instead, the ContextForwardServlet should listen on a single path (say, 
/portlet-resources) and then have a registration mechanism that lets you add 
sub-mappings dynamically (/portlet-resources/foo/* -> web app 1 and 
/portlet-resources/bar/* -> web app 2).  Presumably something where it has a 
collection of GBeans and each web app that wants to register some forward with 
the console deploys one or more instances of the GBean.

  was:
Currently the ContextForwardServlet must be deployed separately for each URL 
path to redirect.

This does not work well for plugins, nor will it work well for a more 
fine-grained console composed of multiple optional bits of functionality.

Instead, the ContextForwardServlet should listen on a single path (say, 
/portlet-resources) and then have a registration mechanism that lets you add 
sub-mappings dynamically (/portlet-resources/foo/* -> web app 1 and 
/portlet-resources/bar/* -> web app 2).  Presumably something where it has a 
collection of GBeans and each web app that wants to register some forward with 
the console deploys one or more instances of the web app.


Fixed in 1.1.2 -- needs to be merged to 1.2

> ContextForwardServlet should have a registration mechanism
> --
>
> Key: GERONIMO-2478
> URL: http://issues.apache.org/jira/browse/GERONIMO-2478
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 1.1.1
>Reporter: Aaron Mulder
> Assigned To: Aaron Mulder
> Fix For: 1.2, 1.1.2
>
>
> Currently the ContextForwardServlet must be deployed separately for each URL 
> path to redirect.
> This does not work well for plugins, nor will it work well for a more 
> fine-grained console composed of multiple optional bits of functionality.
> Instead, the ContextForwardServlet should listen on a single path (say, 
> /portlet-resources) and then have a registration mechanism that lets you add 
> sub-mappings dynamically (/portlet-resources/foo/* -> web app 1 and 
> /portlet-resources/bar/* -> web app 2).  Presumably something where it has a 
> collection of GBeans and each web app that wants to register some forward 
> with the console deploys one or more instances of the GBean.

-- 
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

I am looking for a way to have my clients failover to alternate brokers, use
asynchronous sends, and keep my client code vanilla JMS.
It appears you can't use the failover transport and set connection
properties via the uri at the same time. What I would like to do is combine
failover:(tcp://localhost:61616,tcp://remotehost:61616) with
tcp://localhost:61616?jms.useAsyncSend=true but it doesn't seem to work.
i.e.
failover:(tcp://localhost:61616?jms.useAsyncSend=true,tcp://remotehost:61616?jms.useAsyncSend=true)
Anyone know if this is supposed to work?

The documentation says:
"The good news is that ActiveMQ sends message in async mode by default in
several cases. It is only in cases where the JMS specification required the
use of sync sending that we default to sync sending. The cases that we are
forced to send in sync mode are when persistent messages are being sent
outside of a transaction."

This doesn't appear to be entirely true because when I attempt to use the
NON_PERSISTENT mode, send() still blocks if no brokers are available. When
this happens I can't shut the program down or notify anyone there is a
problem. Note, the ttl of the message can expire and the send() remains
blocked. If I could somehow stop the send() I could have another thread
monitor it and stop it if necessary. Lots of things seem to block that
shouldn't, you can't build robust software if you can't shut things down and
restart them when you suspect something is out of wack.

Ron
--
View this message in context:
http://www.nabble.com/Failover-Protocol-tf2549326.html#a7105422
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

84 matches

Mail list logo