Re: AJAX and Geronimo
How about versioning of the Dojo libraries over time? I haven't played with the AJAX stuff really but I assume we'll be seeing new versions, etc. over time where different applications would be looking for different levels of the dojo libraries. So the goal would be use our server provided version and override it in your app if you need a newer one? Paul McMahan wrote: Dojo is a popular open source AJAX library that's available under the BSD and Academic Free licenses. The DayTrader folks use it in the web UI they recently announced on the Geronimo dev list and Chris used it in the nice LDAP UI he did for GERONIMO-1823. I would also like to start introducing some use of it into the Geronimo admin console when its appropriate to do so. The way that developers usually incorporate an AJAX library into their applications is by making a copy of its static files (javascript, css, gifs, etc) in their webapp and referencing them from their servlets and JSPs. The obvious downside is that each application has a separate copy of the AJAX library, increasing the server's overall disk footprint (Dojo is ~3mb) and preventing the browser from using a single copy of the library files from its cache. Another downside is that the AJAX library can't be upgraded independently from the web application. I think it would be great if Geronimo could provide a more AJAX friendly development environment by helping solve these problems. One idea is that Geronimo could include the Dojo library as a native, standalone webapp with its AJAX library files laid out so that other applications can point at from their HTML. Referencing it in geronimo-web.xml would cause Geronimo to start it up and make its files available at some predetermined context root, say /dojo. Referencing it with a versionless moduleId would make sure the most recent version is always used. So AJAX enabling your application in Geronimo would be a simple as add this line to your geronimo-web.xml. Does this sound like a good idea? Any suggestions or concerns? Perhaps this could be done as a plugin instead of a native module? Best wishes, Paul
Re: Organization and versioning of specs; a new proposal
Jason,
I'm +1 on the change. In order to release 1.1.1 we need to release an updated version of the
J2EE_JAAC specs. I am waiting for feedback from Geir on some licensing issues as well as a TCK run
that Kevan is doing. That said I'd prefer to wait until the we cut the 1.1.1 release. If it looks
like its going to be delayed due to the licensing concerns then we should do this straight away next
week.
Since this isn't a code change I agree with Jason's comments on no review required. Lazy consensus
is appropriate here.
Jason Dillon wrote:
A while ago there was talks about independently versioning specs, and
Alan started a reorg branch which gives each spec module its own
trunk+branches+tags...
I have been thinking about this for a while, and with the recent desire
to split off more modules from geronimo/trunk I've been pondering it
even more. What I have come to believe is that spitting up spec modules
into their own trunk+branches+tags is probably not the best direction
for us to head in.
I believe that all of our specs can, and should, share one trunk... and
still have each module specify its own version. This is very similar to
how Maven2 plugins is setup, see here:
http://svn.apache.org/repos/asf/maven/plugins
Each plugin has its own version that changes independently. The
top-level pom has a version too, which is independent and is only
changed when there is a major configuration change in that pom.
I recommend that we follow this model for our specs.
The advantage to one trunk, is that it facilitates easy check out and
building when you just want all of the specs. If each spec was in its
own trunk, you would need to svn co each one, then mvn install in each
tree, which is a pain.
We also almost never branch specs, they just keep chugging along, only
really needing tags to track released versions.
So, here is what I propose:
specs/trunk/pom.xml
specs/trunk/artifactId
specs/tags/artifactId/version
And if needed:
specs/branches/artifactId/name
This is a single trunk so to build all specs:
svn co https://svn.apache.org/repos/asf/geronimo/specs/trunk/ specs
cd specs
mvn install
To release an individual spec, say geronimo-spec-jms:
cd specs/geronimo-spec-jms
mvn release
The m2 release plugin can be configured with a _tag base_, which we can
set to:
https://svn.apache.org/repos/asf/geronimo/specs/tags/${pom.artifactId}
When released, the plugin will svn cp just the module's directory into a
directory under tags, so it will be easy to see what the released
versions of a specific spec are.
* * *
I really do not see the need for each spec to have its own trunk, and
really I think that if we did then it would just make it more difficult
for cases when we really want all specs.
I do not see any downside to the approach above.
I recommend that we implement this. The only major change, which isn't
that major, is that the properties which live in the root pom that
control the versions need to be removed... or rather moved back to the
version element of the respective pom.
Comments?
--jason
Re: What is left to merge from dead-1.2?
I don't have anything left in dead-1.2. Jason, perhaps we can propose a deadline of next Friday for completing the work or raising an issue. That way we'll be able to put this baby to bed :) Jason Dillon wrote: Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
Re: build broken
We have changed the tooling version to 3.0, so for the first time you have to build following the instructions on http://servicemix.goopen.org/site/building.html On 8/11/06, Tomas Olsson [EMAIL PROTECTED] wrote: Hi, I have recently updated my old servicemix trunk version but when I run maven I get: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.tooling -DartifactId=jbi-maven-plugin \ -Dversion=3.0-incubating-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/to/file org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:3.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), apache.snapshots (http://cvs.apache.org/maven-snapshot-repository) org.apache.servicemix.tooling:jbi-maven-plugin:maven-plugin:3.0-incubating-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), servicemix-m2-repo (http://servicemix.org/m2-repo), apache.snapshots (http://cvs.apache.org/maven-snapshot-repository) Whats wrong /Tomas -- Cheers, Guillaume Nodet
Re: Pulling consumer design
On 8/11/06, Fateev, Maxim [EMAIL PROTECTED] wrote: James, I'm looking into your change (430445) and don't understand how it solves problem of slow consumer. It doesn't solve the slow consumer problem - it was purely to allow pull based delivery of messages for cases where you have few messages and very slow to process messages. i.e. support for prefetch of zero -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-878) JMX Exception: Destination already created when recovering gigantic queues from database
JMX Exception: Destination already created when recovering gigantic queues from database -- Key: AMQ-878 URL: https://issues.apache.org/activemq/browse/AMQ-878 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: incubation Environment: Embeded broker, Any platform (OS, JDK) - currentlly embeded in JBoss 4.0.4.GA Reporter: Nikolai Penkov Attachments: async-recovery.patch I think this issue is described in Hiram's blog: http://blogbucket.blogspot.com/2006/05/scaling-to-gigantic-queues-and-topics.html. E.g. when broker is stopped with a lot of messages in queue. When started - recovery process is fired (currently on creation of a queue), and if another subscriber requests queue - it creates a new one, because previous process hasn't finished. I think the simpliest solution for that problem is to start recovery process in another thread with synchronization to sent process(sent process should be suspended till full recovery is done) and subscriber notification method (every sunscriber should be notified on recovery of message). I have attached a patch to activemq-core, which I have tested with my environment - JBoss 4.0.4.GA with Embeded Broker ActiveMQ trunk release, jdbc persistence. I am not a spec. in threads nor in ActiveMQ design, and I am sure that you will find a more elegant sollution to what I have provided. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: What is left to merge from dead-1.2?
That sounds good to me. --jason On Aug 12, 2006, at 12:19 AM, Matt Hogstrom wrote: I don't have anything left in dead-1.2. Jason, perhaps we can propose a deadline of next Friday for completing the work or raising an issue. That way we'll be able to put this baby to bed :) Jason Dillon wrote: Can we get this finished... so we can move forward and setup modules to use the m2 standard layout? Also, if there is a list of modules which no merge is needed, we can update them now. Anyone know? --jason
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
On 8/11/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks for the reply, my comments are inline... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Friday, August 11, 2006 3:02 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component A few comments: 1) Files should include the Apache standard header Will include them 2) resources are loaded with xbean in BAMEndpoint.process they override any definition specified directly with the rules, actions properties IMHO, they should be loaded when activate is called (or at initialization time, by implementing the spring interface InitializingBean) and only if the properties are not set I had kept both ways to load properties, but going forward I think resource based file loading would be the most appropriate solution so will keep that and remove the embedded beans defn. from BAMEndpoint. Let me know if I missing the point. Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not always the easiest way ... 3) I don't see any use of the BAMGlobalConfig / Params classes This has been kept for future use where global parameters can be defined and used by adaptors as well as actions and rules 4) Rules are not extensible. People will need to use to be able to check for properties, attachments, not only xpath on the content. So it should be an interface with Object evaluate(MessageExchange exchange) or Object evaluate(NormalizedMessage message) or anything like that. This is a good idea, for now let me just implement for content based then we can provide other adaptors later 5) When using xpath, you need a way to configure the namesapces in use in the xpath expression, else you can not use it on xml requests with namespaces. Take a look at the XPathPredicate in servicemix-eip Will make sure that it handles namespaces 6) The configuration could leverage much more of spring/xbean features and use a clean POJO model which will be easily translated into a clean xml schema using xbean. They don't need to use id references and class names, as spring will do that easily. And instead of using BAMActionParameters, these parameters could be easily configured on the action / adaptor itself. So instead of having bam:bAMRule description=Email rule1 resultType=Boolean ruleName=emailRule1 xpath=/[EMAIL PROTECTED]'555-3482'] bam:actionDetails bam:bAMActionDetail executeOn=true actionID=printer active=true/ /bam:actionDetails /bam:bAMRule bam:bAMAction actionName=printer adaptorClass= org.apache.servicemix.bam.sample.PrintAdaptor description=For emailing bam:params bam:bAMActionParameter name=mobileNumber value=405-3785 type=String/ bam:bAMActionParameter name=address value=680, morse ave CA type=String/ /bam:params /bam:bAMAction You could simply have bam:endpoint ... bam:rule bam:evaluator bam:xpath xpath=/test:sample/@id nsContext=#nsContext / /bam:evaluator bam:actions bam:action executeOn=554-345 adaptor=#printAdaptor / /bam:actions /bam:endpoint bam:print id=printAdaptor output=stderr mobileNumber=405-3785 address=680, morse ave CA / bam:namespaceContext id=nsContext bam:namespace prefix=testhttp://test/bam:namespace /bam:namespaceContext This is only an example to show how to use references, without having to define IDs and classNames. This lead to a much cleaner POJO model. The reason it has been repesented this way is because an action can be referenced by multiple rules. So you can define an action once and then reference it from different rules.This provides separation of action from rules. The relationship is as follows:(haven't included the attributes) BAMAction has one or more BAMActionParameter (bamActionParameter has details of the parameters that the action adaptor would use) BAMRule has one or more BAMActionDetail (bamActionDetail has the reference to actions using an ID) So from a user perspective in the rule.xml file they can specify an actionid which is there in the actions.xml . so even if the action implementation changes the rules file doesn't need to be changed. Consider a situation where these files could be coming from an external source so rather than getting a whole bulk of xml we can isolate and deal with specific xmls. From an dev perspective, it's more of a parent child relationship- later on storage could be easy in a database maybe. I have used BAMActionParameter as well as BAMGlobalParameter - they both are same so I guess, use one class and name it BAMParameter. I do understand the relationship between the classes. What i meant is that instead of implemeting the wiring inside the BAM component, you could leverage
car plugin changes... geronimo-plugin.xml, etc.
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
[jira] Resolved: (GERONIMO-2317) Unable to create a new peer listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2317?page=all ] Vamsavardhana Reddy resolved GERONIMO-2317. --- Resolution: Duplicate Unable to create a new peer listener from console - Key: GERONIMO-2317 URL: http://issues.apache.org/jira/browse/GERONIMO-2317 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a new peer listener from console 12:48:47,655 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewPeer javax.jms.JMSException: Could not load protocol: peer. Reason: java.lang.ClassNotFoundException: org.activemq.transport.peer.PeerTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at
[jira] Resolved: (GERONIMO-2316) Unable to create a new Active IO listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2316?page=all ] Vamsavardhana Reddy resolved GERONIMO-2316. --- Resolution: Duplicate Unable to create a new Active IO listener from console -- Key: GERONIMO-2316 URL: http://issues.apache.org/jira/browse/GERONIMO-2316 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.2 Environment: Geronimo 1.1 Reporter: Krishnakumar B I get the following exception when i create a New Active IO Listener from console 12:46:13,784 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.NoSuchMethodError: org.activeio.ChannelFactory.bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTransportServerChannelFactory.java:60) at org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFactory.java:49) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:104) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at
[jira] Resolved: (GERONIMO-2319) Unable to create a new OpenWire Listener from console
[ http://issues.apache.org/jira/browse/GERONIMO-2319?page=all ] Vamsavardhana Reddy resolved GERONIMO-2319. --- Resolution: Duplicate Unable to create a new OpenWire Listener from console - Key: GERONIMO-2319 URL: http://issues.apache.org/jira/browse/GERONIMO-2319 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ, console Affects Versions: 1.1, 1.0 Environment: Geronimo 1.1 Reporter: Krishnakumar B Fix For: 1.2 I am unable to create a new openwire listener from console. I get the following exception 12:51:25,081 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/activemq-broker/1.1/car?JMSServer=ActiveMQ,ServiceModule=geronimo/activemq-broker/1.1/car,j2eeType=GBean,name=NewOpenWire javax.jms.JMSException: Could not load protocol: openwire. Reason: java.lang.ClassNotFoundException: org.activemq.transport.openwire.OpenWireTransportServerChannelFactory in classloader geronimo/activemq-broker/1.1/car at org.activemq.transport.TransportServerChannelProvider.createJMSexception(TransportServerChannelProvider.java:85) at org.activemq.transport.TransportServerChannelProvider.getFactory(TransportServerChannelProvider.java:79) at org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) at org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) at org.activemq.broker.impl.BrokerConnectorImpl.init(BrokerConnectorImpl.java:69) at org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:160) at org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:128) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$c6a55a11.startRecursive(generated) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:83) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at
Re: Is PackagingCommandLine still used anywhere?
AFAIK it has never been used. IMO, it can be removed. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Anyone know? --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
I actually agree with you in all accounts but just trying to decouple the config sources so that there is minimum dependency if it's fed from external sources. But either way the internal dependency will be there. One important thing that I need to mention here is that you had commented about having an interface for what to evaluate, such as properties,content etc... Let's discuss about this as the scope will broaden a lot: The possible sources that one could monitor are: From the MessageExchange: (These in my opinion are not relevant as they are more application specific and not content specific) 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation 7) Pattern 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message For (13) Message alone could have 13.1) Attachment (have to deal with DataHandler) 13.2) Property (handle Object) 13.3) SecuritySubject ( subject and principal) 13.4) Content (xml- being handled now) The rule definition will change as each of the above needs to be uniquely handled. This will get pretty complicated as we may then have to have an interface for the Rule and have different implementations, example - XPathRule could be an implementation where we can handle it based on what we have, PropertyBasedRule would introduce another story where the evaluation could be expression based, With attachment it could be anything - depends on the DahaHandler... So rather than having Object evaluate(NormalizedMessage message) we could have an interface for the BAMProcessor and pass appropriate values to the implementation. The other thing is we can't pass the NormalizedMessage directly to the processor as it's an async operation so we should not wait for any values to be passed from the processor. It will make it blocking. (as in the processor we may take the content out so there would be no content left after delegation to the processor) Your thoughts... Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Saturday, August 12, 2006 2:36 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component On 8/11/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks for the reply, my comments are inline... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Friday, August 11, 2006 3:02 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component A few comments: 1) Files should include the Apache standard header Will include them 2) resources are loaded with xbean in BAMEndpoint.process they override any definition specified directly with the rules, actions properties IMHO, they should be loaded when activate is called (or at initialization time, by implementing the spring interface InitializingBean) and only if the properties are not set I had kept both ways to load properties, but going forward I think resource based file loading would be the most appropriate solution so will keep that and remove the embedded beans defn. from BAMEndpoint. Let me know if I missing the point. Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not always the easiest way ... 3) I don't see any use of the BAMGlobalConfig / Params classes This has been kept for future use where global parameters can be defined and used by adaptors as well as actions and rules 4) Rules are not extensible. People will need to use to be able to check for properties, attachments, not only xpath on the content. So it should be an interface with Object evaluate(MessageExchange exchange) or Object evaluate(NormalizedMessage message) or anything like that. This is a good idea, for now let me just implement for content based then we can provide other adaptors later 5) When using xpath, you need a way to configure the namesapces in use in the xpath expression, else you can not use it on xml requests with namespaces. Take a look at the XPathPredicate in servicemix-eip Will make sure that it handles namespaces 6) The configuration could leverage much more of spring/xbean features and use a clean POJO model which will be easily translated into a clean xml schema using xbean. They don't need to use id references and class names, as spring will do that easily. And instead of using BAMActionParameters, these parameters could be easily configured on the action / adaptor itself. So instead of having bam:bAMRule description=Email rule1 resultType=Boolean ruleName=emailRule1 xpath=/[EMAIL PROTECTED]'555-3482'] bam:actionDetails bam:bAMActionDetail executeOn=true actionID=printer active=true/ /bam:actionDetails /bam:bAMRule bam:bAMAction actionName=printer adaptorClass= org.apache.servicemix.bam.sample.PrintAdaptor description=For emailing
Re: car plugin changes... geronimo-plugin.xml, etc.
Yay
I'll try it out.
I wouldn't be too concerned about tidying up the deployer -- I think
it needs a more massive overhaul.
Thanks,
Aaron
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
Re: car plugin changes... geronimo-plugin.xml, etc.
IMO there are 2 aspects of this plugin:
1. The features used by all users - These users will use the packaging
plugin to package a car to create geronimo plugins. We should make
their lives are as easy as possible by providing everything in the
dafault configuration. In other words they could say geronimoPlugin
(may be not even that) and put the files in src/conf dir
(geronimo-plugin.xml, notices.txt etc) and it should work. IMO, we
should not expect them to know maven well. If it makes the code a bit
messy for the people maintaining the plugin, it should be ok because
they are supposed to be maven experts. These users will use application
configs similar to the *-examples configs. They would like to specify a
server by name and not by using ordered deployers.
2. The features used to build the server cars - These features are used
by very few: Dain, David Jencks, Aaron and may be few others. They are
the only ones who modify these configurations and the changes are very
rare. We should not care if these fearutes are clumsy at the moment
;-).
I hope you would take the above into consideration while changing
the plugin. The filtering should work. IIUC you are using the deployer
to generate an unpacked car (even for executable configurations),
copying the files from target/classes to the correct location in the
mojo and then archiving it using your favorite tool ;-). I would prefer
that we use geronimo code to do this so that the all the cars are
consistent. I would like David Jencks' input on this. Maybe we should
modify the deployer to take a dir parameter for the stuff to be added
at META-INF in the car.
Since the m1 build will be dropped and you have changed the plans,
it should be possible to remove the velocity merge.
The daytrader generates 3 artifacts. They must (?) each get
notice.txt, etc and then get zipped. They are installed using the
attached artifacts.
I have not looked at the code, but it sounds right, and I will look
at the code on Monday.
Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: car plugin changes... geronimo-plugin.xml, etc.
Another issue... When I run the car-maven-plugin on an external plugin, the execution fails because the internal deployment can't resolve a dependency (say, geronimo-security). This can't be listed as a dependency in the POM because we don't want it to be written into the target plan. But it has to be in the M2 repository for the car-maven-plugin to work. My solution so far is to add a bunch of extraneous dependencies to the module that builds the service JAR in the first place, where the plugin module is separate and builds a plugin out of the service JAR. The problem is, there are a *lot* of these dependencies. For a simple service plugin that depends only on geronimo-gbean-deployer being listed for the car-maven-plugin, I've run into these and I'm still going (you disover them one build failure at a time): - geronimo-core - geronimo-transaction - geronimo-security - geronimo-util - geronimo-webservices - howl-logger I don't know what the right way to do this is, but I'd really like it if something under the covers caused all the necessary dependencies to be downloaded so I don't have to clutter up my build with all this stuff. (web services?!?) I'm tempted to create a dummy build with all these dependencies that you run once just to suck all the stuff into your repo and I can leave it out of my real build. Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: Uh-oh. I updated and tried to build just the car-maven-plugin and it failed with a compile error. So I ran a full ./build and it failed with a test error -- some TransactionContextManager test which I would have thought was obsolete. Anyway, I ran a ./build -Dmaven.test.skip=true and it got further, but failed in the first config, which I expect means something isn't quite right with the car-maven-plugin. Results below. It seems to fail on building the GBean deployer, complaining that the GBean deployer already exists. Thanks, Aaron [INFO] [INFO] Building Geronimo :: Configs [INFO]task-segment: [install] [INFO] [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /data/cvs/geronimo/configs/pom.xml to /home/ammulder/.m2/repository/org/apache/geronimo/configs/configs/1.2-SNAPSHOT/configs-1.2-SNAPSHOT.pom [INFO] [INFO] Building Geronimo Configs :: GBean Deployer [INFO]task-segment: [install] [INFO] ... [INFO] [car:prepare-plan] [INFO] Generated: /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan [INFO] [car:package] Packaging configuration /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan/plan.xml ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.car.PackageBuilder.invokeDeployer(PackageBuilder.java:510) at org.apache.geronimo.plugin.car.PackageBuilder.execute(PackageBuilder.java:346) at org.apache.geronimo.plugin.car.PackageMojo.executePackageBuilderShell(PackageMojo.java:253) at org.apache.geronimo.plugin.car.PackageMojo.doExecute(PackageMojo.java:182) at org.apache.geronimo.plugin.MojoSupport.execute(MojoSupport.java:42) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
This isn't a problem. The spec actually says that the web app should be able to see both persistence units. Also, we are just creating a map of the persistent units visible, the user still has to choose which ones to lookup using our magic namespace which is way out side the specification. -dain On Aug 11, 2006, at 6:32 PM, Aaron Mulder wrote: So what happens if an EJB JAR has a persistence.xml and a web app in the same EAR has a separate persistence.xml? If we just look in the class loader, when we go to deploy the web app, we'll see them both because the EJB JAR is added to the parent classpath of the WAR. Is there a good way to distinguish resource in my ClassLoader from resources in my ClassLoader tree? Thanks, Aaron
Re: car plugin changes... geronimo-plugin.xml, etc.
OK, well, it doesn't seem to be working.
What I see when I got through the dependency problems and ran this on
my own plugin build is that the geronimo-plugin.xml gets written to
target/classes/META-INF/geronimo-plugin.xml but not
target/repository/.../META-INF/geronimo-plugin.xml and as a result the
CAR that's built does not include the geronimo-plugin.xml file. I
copied the usage from trunk/configs/welcome-jetty/pom.xml.
Any suggestions?
Thanks,
Aaron
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote: On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote: Ok, I understand where you are going with this. I totally agree with your thinking here. But...IIUC...in the web app, if you are including your own PU, you likely wouldn't be using the JNDI (and thus the container) for this and would be declaring use of the spi bootstrap directly: EntityManagerFactory emf = Persistence.createEntityManagerFactory(mywebpersistenceunit) But with the plugin we're working on, you can look up app-managed EntityManagerFactories in JNDI. Even without JNDI, we'd have to intercept the process to connect the EMF to the DataSource named in persistence.xml. So when you deploy a web app, we look for a persistence.xml in order to read all the settings, connect the web app to the data source and the JPA provider in question, and add the EntityManagerFactories to JNDI. This really isn't a big problem for us, because we are building the pu index at runtime so we can just lookup datasources in the kernel (or JNDI via some magic). Actually, I'm pretty sure the spec gives examples of a stateless session bean using app-managed EMFs and they're injected not looked up the way you're saying. I think that's only for Java SE clients. EJBs support both injection and jndi lookup (the former just uses the latter under the covers). For SE clients, you have to use code like this: EntityManagerFactory emf = javax.persistence.Persistence.createEntityManagerFactory(Order); EntityManager em = emf.createEntityManager(); Any JEE application can use the code above, but it is not recommended. JEE components also get to decide to use application managed injected or looked up EMF or a container managed EM. -dain
[jira] Created: (GERONIMO-2320) New DB pool didn't show up until restarted
New DB pool didn't show up until restarted -- Key: GERONIMO-2320 URL: http://issues.apache.org/jira/browse/GERONIMO-2320 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, databases, deployment Affects Versions: 1.1 Environment: Geronimo 1.1 Tomcat Reporter: Aaron Mulder Fix For: 1.1.2 Deployed a new MySQL database pool using the console wizard in the Geronimo 1.1 Tomcat J2EE distribution (including downloading a driver for it). When it finished, the stdout said Deployment completed successfully! but the new pool did not show up in the list in the Database Pools portlet. I stopped and started the module using the J2EE Connectors screen and then it showed up in the Database Pools list. Haven't seen this in the Jetty build. Need to try to reproduce on a totally clean 1.1 and 1.1.1 Tomcat/J2EE build. -- 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: [XBEAN] Mailing lists
Done, see http://issues.apache.org/jira/browse/INFRA-910On 8/11/06, Guillaume Nodet [EMAIL PROTECTED] wrote:It seems that there is a consensus to create these mailing lists. I will raise a JIRA for that on infra.On 8/1/06, Guillaume Nodet [EMAIL PROTECTED] wrote: While looking at http://issues.apache.org/jira/browse/XBEAN-28,I was wondering if we should ask for xbean specific mailing lists. [EMAIL PROTECTED] [EMAIL PROTECTED]Any opinion ? -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet
Build failure on branches/1.1.1
I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at
[jira] Closed: (XBEAN-44) Problem in JarFileUrlStreamHandler
[ http://issues.apache.org/jira/browse/XBEAN-44?page=all ] Guillaume Nodet closed XBEAN-44. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Sat Aug 12 12:09:28 2006 New Revision: 431074 URL: http://svn.apache.org/viewvc?rev=431074view=rev Log: XBEAN-44: Problem in JarFileUrlStreamHandler Added: geronimo/xbean/trunk/xbean-server/src/test-data/ geronimo/xbean/trunk/xbean-server/src/test-data/resourceFinderTest/ geronimo/xbean/trunk/xbean-server/src/test-data/resourceFinderTest/jar1/ geronimo/xbean/trunk/xbean-server/src/test-data/resourceFinderTest/jar1/resource geronimo/xbean/trunk/xbean-server/src/test-data/resourceFinderTest/jar2/ geronimo/xbean/trunk/xbean-server/src/test-data/resourceFinderTest/jar2/resource geronimo/xbean/trunk/xbean-server/src/test/java/org/apache/xbean/server/classloader/UrlResourceFinderTest.java Modified: geronimo/xbean/trunk/xbean-server/src/main/java/org/apache/xbean/server/classloader/JarFileUrlStreamHandler.java Problem in JarFileUrlStreamHandler -- Key: XBEAN-44 URL: http://issues.apache.org/jira/browse/XBEAN-44 Project: XBean Issue Type: Bug Components: server Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.6 -- 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: Build failure on branches/1.1.1
So I fixed that, and now I get another failure. What happened to this build?!? + | configurations Axis Configuration for performing J2EE deployments | Memory: 21M/25M + ... Caused by: java.lang.NoClassDefFoundError: javax/wsdl/Service at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1655) at java.lang.Class.getDeclaredMethod(Class.java:1262) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:63) ... 67 more Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472) at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332) at
Re: [jira] Created: (SM-534) Business Activity Monitoring Component
If the xml content is a stream, you first need to transform it to a re-readable xml source before any processing can be applied. The EIP component does this and still give a NormalizedMessage (take a look at it: oa.s.eip.support.MessageUtil). You should really take a look at the wire tap implementation, as this is the exact same thing that the BAM component does. If the Rule does not use a simple interface, the component has to handle all your 16 cases internally. I would prefer an extensible design, where the component would first implement the xpath rule on the content and where rules could be written by users for custom things. And as you say, even a test on a property could have lots of different implementations: someone may want to test a string property which will match a regular expression, or an integer value, ... I think all these cases can not be handled by the component, without leading to a bad xml schema and a code which will be difficult to maintain. On 8/12/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: I actually agree with you in all accounts but just trying to decouple the config sources so that there is minimum dependency if it's fed from external sources. But either way the internal dependency will be there. One important thing that I need to mention here is that you had commented about having an interface for what to evaluate, such as properties,content etc... Let's discuss about this as the scope will broaden a lot: The possible sources that one could monitor are: From the MessageExchange: (These in my opinion are not relevant as they are more application specific and not content specific) 1) Endpoint 2) Error 3) ExchangeId 4) Fault 5) InterfaceName 6) Operation 7) Pattern 8) Property 9) Role 10) Service 11) Status 12) IsTransacted 13) Message For (13) Message alone could have 13.1) Attachment (have to deal with DataHandler) 13.2) Property (handle Object) 13.3) SecuritySubject ( subject and principal) 13.4) Content (xml- being handled now) The rule definition will change as each of the above needs to be uniquely handled. This will get pretty complicated as we may then have to have an interface for the Rule and have different implementations, example - XPathRule could be an implementation where we can handle it based on what we have, PropertyBasedRule would introduce another story where the evaluation could be expression based, With attachment it could be anything - depends on the DahaHandler... So rather than having Object evaluate(NormalizedMessage message) we could have an interface for the BAMProcessor and pass appropriate values to the implementation. The other thing is we can't pass the NormalizedMessage directly to the processor as it's an async operation so we should not wait for any values to be passed from the processor. It will make it blocking. (as in the processor we may take the content out so there would be no content left after delegation to the processor) Your thoughts... Soumadeep - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Saturday, August 12, 2006 2:36 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component On 8/11/06, Soumadeep-Infravio [EMAIL PROTECTED] wrote: Thanks for the reply, my comments are inline... - Original Message - From: Guillaume Nodet [EMAIL PROTECTED] To: servicemix-dev@geronimo.apache.org Sent: Friday, August 11, 2006 3:02 PM Subject: Re: [jira] Created: (SM-534) Business Activity Monitoring Component A few comments: 1) Files should include the Apache standard header Will include them 2) resources are loaded with xbean in BAMEndpoint.process they override any definition specified directly with the rules, actions properties IMHO, they should be loaded when activate is called (or at initialization time, by implementing the spring interface InitializingBean) and only if the properties are not set I had kept both ways to load properties, but going forward I think resource based file loading would be the most appropriate solution so will keep that and remove the embedded beans defn. from BAMEndpoint. Let me know if I missing the point. Mmmh, i guess it depend. Having to create 4 xml files instead of 1 is not always the easiest way ... 3) I don't see any use of the BAMGlobalConfig / Params classes This has been kept for future use where global parameters can be defined and used by adaptors as well as actions and rules 4) Rules are not extensible. People will need to use to be able to check for properties, attachments, not only xpath on the content. So it should be an interface with Object evaluate(MessageExchange exchange) or Object evaluate(NormalizedMessage message) or anything like that. This is a good idea, for now let me just implement for content based then we can provide other adaptors later 5) When
Re: Build failure on branches/1.1.1
And on top of that, the OpenEJB openejb-builder module tests are failing. [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.947 sec [junit] [ERROR] Test org.openejb.deployment.EarDeploymentTest FAILED [junit] Running org.openejb.deployment.EjbJarModuleDeploymentTest [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.883 sec [junit] [ERROR] Test org.openejb.deployment.EjbJarModuleDeploymentTest FAILED Caused by: java.lang.RuntimeException: Could not locate soap encoding schema at org.apache.geronimo.axis.builder.SchemaInfoBuilder.clinit(SchemaInf oBuilder.java:88) ... 13 more Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: So I fixed that, and now I get another failure. What happened to this build?!? + | configurations Axis Configuration for performing J2EE deployments | Memory: 21M/25M + ... Caused by: java.lang.NoClassDefFoundError: javax/wsdl/Service at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1655) at java.lang.Class.getDeclaredMethod(Class.java:1262) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:63) ... 67 more Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at
Re: Build failure on branches/1.1.1
All the same problems on branches/1.1 Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: And on top of that, the OpenEJB openejb-builder module tests are failing. [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.947 sec [junit] [ERROR] Test org.openejb.deployment.EarDeploymentTest FAILED [junit] Running org.openejb.deployment.EjbJarModuleDeploymentTest [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 2.883 sec [junit] [ERROR] Test org.openejb.deployment.EjbJarModuleDeploymentTest FAILED Caused by: java.lang.RuntimeException: Could not locate soap encoding schema at org.apache.geronimo.axis.builder.SchemaInfoBuilder.clinit(SchemaInf oBuilder.java:88) ... 13 more Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: So I fixed that, and now I get another failure. What happened to this build?!? + | configurations Axis Configuration for performing J2EE deployments | Memory: 21M/25M + ... Caused by: java.lang.NoClassDefFoundError: javax/wsdl/Service at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1655) at java.lang.Class.getDeclaredMethod(Class.java:1262) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:63) ... 67 more Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: I just tried to build this branche from scratch and I get a dependency failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. Thanks, Aaron + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: You are working offline so the build will continue, but geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! You are working offline so the build will continue, but openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! build:start: multiproject:install-callback: [echo] Running car:install for openejb Configuration for performing J2EE deployments car:prepare-plan: car:package: [delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository [mkdir] Created dir: /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository Packaging configuration /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/plan/plan.xml 15:14:17,919 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61) at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData(ServiceConfigBuilder.java:295) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:256) at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211) at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at
Re: car plugin changes... geronimo-plugin.xml, etc.
First, you need to start with a clean build so `mvn clean` first... because you are still seeing TransactionContextManager there is definitely something stale in your build... --jason On Aug 12, 2006, at 7:03 AM, Aaron Mulder wrote: Uh-oh. I updated and tried to build just the car-maven-plugin and it failed with a compile error. So I ran a full ./build and it failed with a test error -- some TransactionContextManager test which I would have thought was obsolete. Anyway, I ran a ./build -Dmaven.test.skip=true and it got further, but failed in the first config, which I expect means something isn't quite right with the car-maven-plugin. Results below. It seems to fail on building the GBean deployer, complaining that the GBean deployer already exists. Thanks, Aaron [INFO] -- -- [INFO] Building Geronimo :: Configs [INFO]task-segment: [install] [INFO] -- -- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /data/cvs/geronimo/configs/pom.xml to /home/ammulder/.m2/repository/org/apache/geronimo/configs/configs/ 1.2-SNAPSHOT/configs-1.2-SNAPSHOT.pom [INFO] -- -- [INFO] Building Geronimo Configs :: GBean Deployer [INFO]task-segment: [install] [INFO] -- -- ... [INFO] [car:prepare-plan] [INFO] Generated: /data/cvs/geronimo/configs/geronimo-gbean- deployer/target/plan [INFO] [car:package] Packaging configuration /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan/ plan.xml ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:254) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$ $734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.plugin.car.PackageBuilder.invokeDeployer (PackageBuilder.java:510) at org.apache.geronimo.plugin.car.PackageBuilder.execute (PackageBuilder.java:346) at org.apache.geronimo.plugin.car.PackageMojo.executePackageBuilderShell( PackageMojo.java:253) at org.apache.geronimo.plugin.car.PackageMojo.doExecute (PackageMojo.java:182) at org.apache.geronimo.plugin.MojoSupport.execute (MojoSupport.java:42) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif ecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand leFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment s(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) 09:59:15,785 ERROR [PackageBuilder]
Re: car plugin changes... geronimo-plugin.xml, etc.
Can you point me at the build for one of these external plugins? --jason On Aug 12, 2006, at 8:05 AM, Aaron Mulder wrote: Another issue... When I run the car-maven-plugin on an external plugin, the execution fails because the internal deployment can't resolve a dependency (say, geronimo-security). This can't be listed as a dependency in the POM because we don't want it to be written into the target plan. But it has to be in the M2 repository for the car-maven-plugin to work. My solution so far is to add a bunch of extraneous dependencies to the module that builds the service JAR in the first place, where the plugin module is separate and builds a plugin out of the service JAR. The problem is, there are a *lot* of these dependencies. For a simple service plugin that depends only on geronimo-gbean-deployer being listed for the car-maven-plugin, I've run into these and I'm still going (you disover them one build failure at a time): - geronimo-core - geronimo-transaction - geronimo-security - geronimo-util - geronimo-webservices - howl-logger I don't know what the right way to do this is, but I'd really like it if something under the covers caused all the necessary dependencies to be downloaded so I don't have to clutter up my build with all this stuff. (web services?!?) I'm tempted to create a dummy build with all these dependencies that you run once just to suck all the stuff into your repo and I can leave it out of my real build. Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: Uh-oh. I updated and tried to build just the car-maven-plugin and it failed with a compile error. So I ran a full ./build and it failed with a test error -- some TransactionContextManager test which I would have thought was obsolete. Anyway, I ran a ./build -Dmaven.test.skip=true and it got further, but failed in the first config, which I expect means something isn't quite right with the car-maven-plugin. Results below. It seems to fail on building the GBean deployer, complaining that the GBean deployer already exists. Thanks, Aaron [INFO] - --- [INFO] Building Geronimo :: Configs [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /data/cvs/geronimo/configs/pom.xml to /home/ammulder/.m2/repository/org/apache/geronimo/configs/configs/ 1.2-SNAPSHOT/configs-1.2-SNAPSHOT.pom [INFO] - --- [INFO] Building Geronimo Configs :: GBean Deployer [INFO]task-segment: [install] [INFO] - --- ... [INFO] [car:prepare-plan] [INFO] Generated: /data/cvs/geronimo/configs/geronimo-gbean- deployer/target/plan [INFO] [car:package] Packaging configuration /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan/ plan.xml ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:254) at org.apache.geronimo.deployment.Deployer$ $FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at org.apache.geronimo.plugin.car.PackageBuilder.invokeDeployer (PackageBuilder.java:510) at org.apache.geronimo.plugin.car.PackageBuilder.execute (PackageBuilder.java:346) at org.apache.geronimo.plugin.car.PackageMojo.executePackageBuilderShell (PackageMojo.java:253) at org.apache.geronimo.plugin.car.PackageMojo.doExecute (PackageMojo.java:182) at org.apache.geronimo.plugin.MojoSupport.execute (MojoSupport.java:42) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at
Re: car plugin changes... geronimo-plugin.xml, etc.
First, I am more concerned about how the configs that are in our
tree, and how they are working. It looks to me like geronimo-
plugin.xml is getting put into META-INF/geronimo-plugin.xml for all
car's that have one defined.
Can you please verify the functionality for trunk first.
So, exactly which bits of welcome-jetty/pom.xml did you copy? Just
the plugin bits... the resources bits or the whole enchilada?
The car plugin will generate a car that includes:
target/repository/groupId/artifactId/version/artifactId-
version.car/**
and:
target/classes/**
* * *
Anyways, start out with a clean build on svn up'd tree w/no C markers
on svn status and then I can help you work out what is going on...
cause it does sound like you have some stale bits floating around.
You should not be seeing any TransactionContextManager muck
anymore... and the gbean-deployer's pom.xml was changed from
boottrue/boot to bootstraptrue/bootstrap which i you did not
have a updated car plugin would cause it to use a builder shell
instead of a bootstrap. `mvn -X` should produce logging to show
which shell type was actually used.
--jason
On Aug 12, 2006, at 8:20 AM, Aaron Mulder wrote:
OK, well, it doesn't seem to be working.
What I see when I got through the dependency problems and ran this on
my own plugin build is that the geronimo-plugin.xml gets written to
target/classes/META-INF/geronimo-plugin.xml but not
target/repository/.../META-INF/geronimo-plugin.xml and as a result the
CAR that's built does not include the geronimo-plugin.xml file. I
copied the usage from trunk/configs/welcome-jetty/pom.xml.
Any suggestions?
Thanks,
Aaron
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should drop the unused bits.
--jason
Re: car plugin changes... geronimo-plugin.xml, etc.
On Aug 12, 2006, at 6:56 AM, anita kulshreshtha wrote: Since the m1 build will be dropped and you have changed the plans, it should be possible to remove the velocity merge. Nope, the plan.xml is not being filtered as a normal resources at the moment, so we still need velocity there... or replace that with the same mechanism that the resources plugin is using. The daytrader generates 3 artifacts. They must (?) each get notice.txt, etc and then get zipped. They are installed using the attached artifacts. I'm not really worried about DayTrader now... I'd like to get trunk sorted first, then I can work on the external projects. --jason
Re: car plugin changes... geronimo-plugin.xml, etc.
So, what goes into a car file that is not provided by the original
plan.xml?
The more I work with car files the more I want to get rid of them. I
really don't like them at all.
I don't see why we need them... appears that the plan.xml (or some
other form of xml) is sufficient. Car files are adding much much
unneeded complexity to the build, to the bootstrap and to plugin and
user development.
Why are they needed? How do they make anything easier for anyone?
I really think that we need to give cars the boot (the brown leathery
type with some mud on the heels).
--jason
On Aug 12, 2006, at 6:56 AM, anita kulshreshtha wrote:
IMO there are 2 aspects of this plugin:
1. The features used by all users - These users will use the packaging
plugin to package a car to create geronimo plugins. We should make
their lives are as easy as possible by providing everything in the
dafault configuration. In other words they could say geronimoPlugin
(may be not even that) and put the files in src/conf dir
(geronimo-plugin.xml, notices.txt etc) and it should work. IMO, we
should not expect them to know maven well. If it makes the code a bit
messy for the people maintaining the plugin, it should be ok because
they are supposed to be maven experts. These users will use
application
configs similar to the *-examples configs. They would like to
specify a
server by name and not by using ordered deployers.
2. The features used to build the server cars - These features are
used
by very few: Dain, David Jencks, Aaron and may be few others. They are
the only ones who modify these configurations and the changes are very
rare. We should not care if these fearutes are clumsy at the moment
;-).
I hope you would take the above into consideration while changing
the plugin. The filtering should work. IIUC you are using the deployer
to generate an unpacked car (even for executable configurations),
copying the files from target/classes to the correct location in the
mojo and then archiving it using your favorite tool ;-). I would
prefer
that we use geronimo code to do this so that the all the cars are
consistent. I would like David Jencks' input on this. Maybe we should
modify the deployer to take a dir parameter for the stuff to be added
at META-INF in the car.
Since the m1 build will be dropped and you have changed the plans,
it should be possible to remove the velocity merge.
The daytrader generates 3 artifacts. They must (?) each get
notice.txt, etc and then get zipped. They are installed using the
attached artifacts.
I have not looked at the code, but it sounds right, and I will look
at the code on Monday.
Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:
I've just finished committing changes that should (I hope) bring back
the functionality needed to include geronimo-plugin.xml... someone
please validate that it works as desired.
Maven is now responsible for making the car archives now... the car
plugin will always spit out into a local repo and then the
PackageMojo will create an archive out of it using the m2 archiver
bits, which allows flexible manifest entries... blah blah.
geronimo-plugin.xml is still being filtered using the resources
plugin... and really anything you drop into src/main/resources will
be included into the car, and filtering is controlled by the default
m2 bits in your pom.
Plan files have been updated to use ${pom.version} instead of $
{pom.currentVersion}... ${pom} is actually the project reference,
which is closer to what it would be if filtered by resources (which
we will eventually get to, and drop velocity).
Car files now all have LICENSE.txt and NOTICE.txt included (side-
effect of using Maven's mech to pick up resources), blah blah
The addition of the startup-jar is no longer hidden... its just
another resources in src/main/resources.
I also updated the PackageBuilder to take a list of classpath
elements (that are artifacts, like the dependency plugin) which
allows for customization of the prefix added to the entry in the
manifest, which was needed to get lib/endorsed bits (the m2 archiver
only allows one prefix per set). Right now the list is non-
transitive... I could not figure how to get that working... need to
ping the peeps in #maven for help. I will be pruning the list of
properties we have in the root pom to manage versions, which are
mostly unused now.
There is still some more dependency clean up that needs to be done,
but the servers are starting fine.
Please take a moment and check for any strangeness and lemme know if
you find anything.
May still be a bit more work to get the multiple car muck working...
but until I have something that is actually using the plugin that I
can peek at I can't really fix it.
I left the Deployer code asis... though my hunch is that some of this
is not needed (the jar and manifest bits primarily)... and if someone
knows if we use those bits anywhere else please speak up, else we
should
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree with
your thinking here. But...IIUC...in the web app, if you are
including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI
driven in JEE).
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever -- perhaps
detecting that correctly-named JPA GBeans already exist in the parent
tree so it's not necessary to redefine them for the web app. In fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put the
JPA resources in there so EJBs or Servlets that have persistence.xml
files in their archives can use them. I like your idea on checking
to see if a gbean is already defined and not redefining it (it being
the JPA factory). From a spec perspective, I can find anything that
requires this. Have you found something? Best I can find is that
the persistence classes themselves (i.e. your persistent pojo
classes) have to come from the same classloader and can't be reloaded
in a child classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static
declarations or
componanents like Spring, then it really shouldn't be an
issue. If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons
Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a
web app in
the same EAR has a separate persistence.xml? If we just
look in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of
the WAR. Is
there a good way to distinguish resource in my
ClassLoader from
resources in my ClassLoader tree?
Thanks,
Aaron
Re: car plugin changes... geronimo-plugin.xml, etc.
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote: Can you point me at the build for one of these external plugins? OK, first check out and build the prerequisite: https://svn.sourceforge.net/svnroot/gplugins/common/trunk Then check out and build https://svn.sourceforge.net/svnroot/gplugins/quartz/trunk There are several modules in that one, it should build base/scheduler, base/deployer, and base/console (the JAR/WAR artifacts) and then plugins/scheduler (the first CAR artifact which makes a CAR out of the base/scheduler JAR). It's the plugins/scheduler build I'm testing with, which I want to create a CAR file with embedded META-INF/geronimo-plugin.xml file. On the trunk build, I did the clean, and the build is going now. If it works, I'll look at the output for the welcome app CAR. Thanks, Aaron On Aug 12, 2006, at 8:05 AM, Aaron Mulder wrote: Another issue... When I run the car-maven-plugin on an external plugin, the execution fails because the internal deployment can't resolve a dependency (say, geronimo-security). This can't be listed as a dependency in the POM because we don't want it to be written into the target plan. But it has to be in the M2 repository for the car-maven-plugin to work. My solution so far is to add a bunch of extraneous dependencies to the module that builds the service JAR in the first place, where the plugin module is separate and builds a plugin out of the service JAR. The problem is, there are a *lot* of these dependencies. For a simple service plugin that depends only on geronimo-gbean-deployer being listed for the car-maven-plugin, I've run into these and I'm still going (you disover them one build failure at a time): - geronimo-core - geronimo-transaction - geronimo-security - geronimo-util - geronimo-webservices - howl-logger I don't know what the right way to do this is, but I'd really like it if something under the covers caused all the necessary dependencies to be downloaded so I don't have to clutter up my build with all this stuff. (web services?!?) I'm tempted to create a dummy build with all these dependencies that you run once just to suck all the stuff into your repo and I can leave it out of my real build. Thanks, Aaron On 8/12/06, Aaron Mulder [EMAIL PROTECTED] wrote: Uh-oh. I updated and tried to build just the car-maven-plugin and it failed with a compile error. So I ran a full ./build and it failed with a test error -- some TransactionContextManager test which I would have thought was obsolete. Anyway, I ran a ./build -Dmaven.test.skip=true and it got further, but failed in the first config, which I expect means something isn't quite right with the car-maven-plugin. Results below. It seems to fail on building the GBean deployer, complaining that the GBean deployer already exists. Thanks, Aaron [INFO] - --- [INFO] Building Geronimo :: Configs [INFO]task-segment: [install] [INFO] - --- [INFO] [site:attach-descriptor] [INFO] [install:install] [INFO] Installing /data/cvs/geronimo/configs/pom.xml to /home/ammulder/.m2/repository/org/apache/geronimo/configs/configs/ 1.2-SNAPSHOT/configs-1.2-SNAPSHOT.pom [INFO] - --- [INFO] Building Geronimo Configs :: GBean Deployer [INFO]task-segment: [install] [INFO] - --- ... [INFO] [car:prepare-plan] [INFO] Generated: /data/cvs/geronimo/configs/geronimo-gbean- deployer/target/plan [INFO] [car:package] Packaging configuration /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan/ plan.xml ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2- SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. org.apache.geronimo.common.DeploymentException: Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car already exists in the server. Try to undeploy it first or use the redeploy command. at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:254) at org.apache.geronimo.deployment.Deployer$ $FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke (BasicKernel.java:239) at
[jira] Closed: (XBEAN-43) The metadata generator should create the spring.schemas property file
[ http://issues.apache.org/jira/browse/XBEAN-43?page=all ] Guillaume Nodet closed XBEAN-43. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Sat Aug 12 16:03:59 2006 New Revision: 431110 URL: http://svn.apache.org/viewvc?rev=431110view=rev Log: XBEAN-43: The metadata generator should create the spring.schemas property file Modified: geronimo/xbean/trunk/maven-xbean-plugin/src/main/java/org/apache/xbean/maven/XBeanMojo.java geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/generator/MappingGeneratorTask.java geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/generator/XmlMetadataGenerator.java The metadata generator should create the spring.schemas property file - Key: XBEAN-43 URL: http://issues.apache.org/jira/browse/XBEAN-43 Project: XBean Issue Type: Bug Components: spring, maven-plugin Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.6 See http://static.springframework.org/spring/docs/2.0.x/reference/extensible-xml.html#d0e29434 -- 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: car plugin changes... geronimo-plugin.xml, etc.
Common builds fine... but quartz is complaining:
snip
[INFO]
[INFO] Building Geronimo Plugin :: Quartz Scheduler
[INFO]task-segment: [install]
[INFO]
[INFO] [clean:clean {execution: default}]
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target/classes
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target/test-classes
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/jason/ws/geronimo/gplugins/quartz/plugins/
scheduler/target/plan/plan.xml
Downloading: http://www.ibiblio.org/maven/geronimo/poms/geronimo-
gbean-deployer-1.1.pom
[WARNING] Unable to get resource from repository ibiblio-maven-1
(http://www.ibiblio.org/maven)
Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
deployer/1.1/geronimo-gbean-deployer-1.1.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
Downloading: http://www.ibiblio.org/maven/geronimo/cars/geronimo-
gbean-deployer-1.1.car
[WARNING] Unable to get resource from repository ibiblio-maven-1
(http://www.ibiblio.org/maven)
Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
deployer/1.1/geronimo-gbean-deployer-1.1.car
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) geronimo:geronimo-gbean-deployer:car:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=geronimo -
DartifactId=geronimo-gbean-deployer \
-Dversion=1.1 -Dpackaging=car -Dfile=/path/to/file
Path to dependency:
1) gplugins:quartz-scheduler-plugin:car:0.2.1
2) geronimo:geronimo-gbean-deployer:car:1.1
--
1 required artifact is missing.
for artifact:
gplugins:quartz-scheduler-plugin:car:0.2.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
ibiblio-maven-1 (http://www.ibiblio.org/maven)
/snip
Also, I notice that these are using 1.1 deps... and I have no idea
how the 1.2-SNAPSHOT car plugin is going to like that...
--jason
On Aug 12, 2006, at 3:49 PM, Aaron Mulder wrote:
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you point me at the build for one of these external plugins?
OK, first check out and build the prerequisite:
https://svn.sourceforge.net/svnroot/gplugins/common/trunk
Then check out and build
https://svn.sourceforge.net/svnroot/gplugins/quartz/trunk
There are several modules in that one, it should build base/scheduler,
base/deployer, and base/console (the JAR/WAR artifacts) and then
plugins/scheduler (the first CAR artifact which makes a CAR out of the
base/scheduler JAR).
It's the plugins/scheduler build I'm testing with, which I want to
create a CAR file with embedded META-INF/geronimo-plugin.xml file.
On the trunk build, I did the clean, and the build is going now. If
it works, I'll look at the output for the welcome app CAR.
Thanks,
Aaron
On Aug 12, 2006, at 8:05 AM, Aaron Mulder wrote:
Another issue...
When I run the car-maven-plugin on an external plugin, the
execution
fails because the internal deployment can't resolve a dependency
(say,
geronimo-security). This can't be listed as a dependency in the
POM
because we don't want it to be written into the target plan.
But it
has to be in the M2 repository for the car-maven-plugin to work.
My solution so far is to add a bunch of extraneous dependencies
to the
module that builds the service JAR in the first place, where the
plugin module is separate and builds a plugin out of the service
JAR.
The problem is, there are a *lot* of these dependencies. For a
simple
service plugin that depends only on geronimo-gbean-deployer being
listed for the car-maven-plugin, I've run into these and I'm still
going (you disover them one build failure at a time):
- geronimo-core
- geronimo-transaction
- geronimo-security
- geronimo-util
- geronimo-webservices
- howl-logger
I don't know what the right way to do this is, but I'd really
like it
if something under the covers caused all the necessary
dependencies to
be downloaded so I don't have to clutter up my build with all this
stuff. (web services?!?) I'm tempted to create a dummy build with
all these dependencies that you run once just to suck all the stuff
into your repo and I
Re: car plugin changes... geronimo-plugin.xml, etc.
Thanks Jason, after the full build and a little IRC help, all is working now!!!
To summarize...
I finished a full build of trunk, and then the car-maven-plugin
started working for me. The only remaining problem was that it put
too many JARs in the target plan.xml, so I put in a change to ignore
JARs with scope=provided (which it was already doing for CARs) and now
all is good!
There are two longer-term issues:
1) It's annoying that the main JAR/WAR/etc. build and the CAR build
must have different artifact names. e.g. jetty-builder vs.
jetty-deployer. For plugins, I'm thinking of using foo-service for
the JAR/WAR and foo for the plugin, since the name for the plugin is
what you're actually going to see when you select and install it. I
hoped that foo/bar/1.0/jar and foo/bar/1.0/car would be different
enough, but Maven didn't necessarily agree.
2) Currently, the M2 car-maven-plugin works when used to build a
Geronimo 1.1 plugin. I'd like to keep that capability. Ideally, we'd
release a version of that plugin with its minimal dependencies
(geronimo-kernel, geronimo-system, etc.) so I could refer to that
specific version when building G 1.1 plugins. Jason's offered to push
a new SNAPSHOT and I'll try that and see how it goes, but I wish we
could have a proper release. I'm afraid that if we change some kernel
or deployer interface for 1.2, the updated car-maven-plugin may stop
working for 1.1 plugins. (I use the G 1.2 car-maven-plugin for G 1.1
plugins because they use Maven 2 builds so I can't use the G 1.1 M1
plugins.) I think I remember in G 1.1 we had certain partial
releases like geronimo-kernel-123456.jar that we put out just so the
plugins could refer to them. Does anyone know more about that?
Thanks,
Aaron
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
Common builds fine... but quartz is complaining:
snip
[INFO]
[INFO] Building Geronimo Plugin :: Quartz Scheduler
[INFO]task-segment: [install]
[INFO]
[INFO] [clean:clean {execution: default}]
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target/classes
[INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
plugins/scheduler/target/test-classes
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /Users/jason/ws/geronimo/gplugins/quartz/plugins/
scheduler/target/plan/plan.xml
Downloading: http://www.ibiblio.org/maven/geronimo/poms/geronimo-
gbean-deployer-1.1.pom
[WARNING] Unable to get resource from repository ibiblio-maven-1
(http://www.ibiblio.org/maven)
Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
deployer/1.1/geronimo-gbean-deployer-1.1.pom
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
Downloading: http://www.ibiblio.org/maven/geronimo/cars/geronimo-
gbean-deployer-1.1.car
[WARNING] Unable to get resource from repository ibiblio-maven-1
(http://www.ibiblio.org/maven)
Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
deployer/1.1/geronimo-gbean-deployer-1.1.car
[WARNING] Unable to get resource from repository central (http://
repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) geronimo:geronimo-gbean-deployer:car:1.1
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=geronimo -
DartifactId=geronimo-gbean-deployer \
-Dversion=1.1 -Dpackaging=car -Dfile=/path/to/file
Path to dependency:
1) gplugins:quartz-scheduler-plugin:car:0.2.1
2) geronimo:geronimo-gbean-deployer:car:1.1
--
1 required artifact is missing.
for artifact:
gplugins:quartz-scheduler-plugin:car:0.2.1
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
ibiblio-maven-1 (http://www.ibiblio.org/maven)
/snip
Also, I notice that these are using 1.1 deps... and I have no idea
how the 1.2-SNAPSHOT car plugin is going to like that...
--jason
On Aug 12, 2006, at 3:49 PM, Aaron Mulder wrote:
On 8/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
Can you point me at the build for one of these external plugins?
OK, first check out and build the prerequisite:
https://svn.sourceforge.net/svnroot/gplugins/common/trunk
Then check out and build
https://svn.sourceforge.net/svnroot/gplugins/quartz/trunk
There are several modules in that one, it should build base/scheduler,
base/deployer, and base/console (the JAR/WAR
RE: XBEAN-39 - what's next?
Thanks for that! :-) -- Stefan Kleineikenscheidt tel. +49 (711) 99 33 035 Rosenbergstr. 58 mob. +49 (172) 130 54 77 70176 Stuttgart (GERMANY) [EMAIL PROTECTED] From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 8:01 PM To: dev@geronimo.apache.org Subject: Re: XBEAN-39 - what's next? There is no need to review for bugfixes. I will commit it asap. Thanks for this patch. On 8/11/06, Stefan Kleineikenscheidt [EMAIL PROTECTED] wrote: Hi all, I've attached a second version of patch to XBEAN-39 with the changes Guillaume suggested. As far as I understand the process PMC members have to review and vote for the patch. So, I please have a look at it - and vote for it... :-) - http://issues.apache.org/jira/browse/XBEAN-39 Cheers, -Stefan -- Stefan Kleineikenscheidt tel. +49 (711) 99 33 035 Rosenbergstr. 58 mob. +49 (172) 130 54 77 70176 Stuttgart (GERMANY) [EMAIL PROTECTED] -- Cheers, Guillaume Nodet
Re: Build failure on branches/1.1.1
I have hit the same road block building 1.1.1 :o(( VamsiOn 8/13/06, Aaron Mulder [EMAIL PROTECTED] wrote: I just tried to build this branche from scratch and I get a dependencyfailure in the OpenEJB deployer on Axis.I confirmed that my OpenEJBis http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2 .Thanks, Aaron+| configurations openejb Configuration for performing J2EE deployments| Memory: 14M/25M+ DEPRECATED: the default goal should be specified in the buildsection of project.xml instead of maven.xmlDEPRECATED: the default goal should be specified in the buildsection of project.xml instead of maven.xmlbuild:end:You are working offline so the build will continue, butgeronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date!You are working offline so the build will continue, butopenejb-builder-2.1.1-SNAPSHOT.jar may be out of date!build:start:multiproject:install-callback:[echo] Running car:install for openejb Configuration forperforming J2EE deploymentscar:prepare-plan:car:package:[delete] Deleting directory /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repository[mkdir] Created dir:/data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/repositoryPackaging configuration/data/cvs/geronimo- 1.1.1/configs/openejb-deployer/target/plan/plan.xml15:14:17,919 ERROR [Deployer] Deployment failed due tojava.lang.NoClassDefFoundError: org/apache/axis/Handlerat java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141)at org.openejb.server.axis.WSContainerGBean.class$(WSContainerGBean.java:61)at org.openejb.server.axis.WSContainerGBean.clinit(WSContainerGBean.java :61)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo(GBeanInfo.java:70)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanData (ServiceConfigBuilder.java:295)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(ServiceConfigBuilder.java:290)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration (ServiceConfigBuilder.java:256)at org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfiguration(ServiceConfigBuilder.java:211)at org.apache.geronimo.deployment.service.ServiceConfigBuilder$$FastClassByCGLIB$$9f173be6.invoke (generated)at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122)at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35)at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5a100f07.buildConfiguration (generated)at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302)at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated)at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122)at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)at org.apache.geronimo.plugin.packaging.PackageBuilder.invokeDeployer(PackageBuilder.java:472)at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:332)at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:324)at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute(PackageBuilderShell.java:291)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke (Method.java:324)at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:180)at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:102)at org.apache.commons.jelly.impl.ScriptBlock.run (ScriptBlock.java:95)at
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
David Blevins wrote:
Seems like I'm walking in mid-conversation, but I hope I can add some
details.
On Aug 11, 2006, at 8:30 PM, Aaron Mulder wrote:
On 8/11/06, Jeff Genender [EMAIL PROTECTED] wrote:
Ok, I understand where you are going with this. I totally agree with
your thinking here. But...IIUC...in the web app, if you are including
your own PU, you likely wouldn't be using the JNDI (and thus the
container) for this and would be declaring use of the spi bootstrap
directly:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory(mywebpersistenceunit)
That's one way any component (servlet, ejb, ee app client, or java se
app) can get an EntityManagerFactory. But as Aaron says, anyone
(servlet, ejb, ee app client) who wants a DataSource managed by the
container has to use JNDI or dependecy injection (which is JNDI driven
in JEE).
Well...that wasn't my point ;-) My point was there was no reason to
access the JNDI to get an EMF for a stand alone web app. However, there
is nothing wrong with the persistence.xml declaring access to the JNDI
for the datasource...even in a stand alone web app... i.e:
persistence
persistence-unit name=myPU transaction-type=JTA
jta-data-sourcejava:/MySQLDS/jta-data-source
...
In this case...the code I showed could still apply to get a container
managed datasource...as does yours ;-)
Jeff
E.g. a Servlet with this:
public class MySerlvet extends HttpServlet {
@Resource EntityManagerFactory myEmf;
}
Or the equivalent EJB:
@Stateful public class ShoppingCart {
@Resource EntityManagerFactory myEmf;
}
At this moment it won't be a problem, since the plugin only supports
web apps, but with Blevins' expertise it should be easy enough to
support EJB JARs too. Eventually we'll need to get clever -- perhaps
detecting that correctly-named JPA GBeans already exist in the parent
tree so it's not necessary to redefine them for the web app. In fact,
that's probably the way to go.
Happy to help in whatever approach you're taking. As I mentioned my
current thinking is to wrap JNDI with an extended JNDI and put the JPA
resources in there so EJBs or Servlets that have persistence.xml files
in their archives can use them. I like your idea on checking to see if
a gbean is already defined and not redefining it (it being the JPA
factory). From a spec perspective, I can find anything that requires
this. Have you found something? Best I can find is that the
persistence classes themselves (i.e. your persistent pojo classes) have
to come from the same classloader and can't be reloaded in a child
classloader if they were also listed in a parent classloader.
-David
Thanks,
Aaron
And when using the EJB, you would call the JNDI. Therefore, I don't
think this is a problem at all.
Thanks,
Aaron
But unless
the spi jar uses some sort of mechanism using static declarations or
componanents like Spring, then it really shouldn't be an issue.
If it
is, I think its reasonable to claim storage of duplicate PUs in
the same
package causing the problem (again, like the Spring Commons Logging
problem).
Thanks,
Aaron
Aaron Mulder wrote:
So what happens if an EJB JAR has a persistence.xml and a web
app in
the same EAR has a separate persistence.xml? If we just look
in the
class loader, when we go to deploy the web app, we'll see
them both
because the EJB JAR is added to the parent classpath of the
WAR. Is
there a good way to distinguish resource in my ClassLoader
from
resources in my ClassLoader tree?
Thanks,
Aaron
