[jira] Assigned: (SM-987) Binding Component archetype - can't build
[ https://issues.apache.org/activemq/browse/SM-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Co reassigned SM-987: Assignee: Adrian Co Should we remove the checkstyle for the archetype or maybe for this specific error only? Binding Component archetype - can't build - Key: SM-987 URL: https://issues.apache.org/activemq/browse/SM-987 Project: ServiceMix Issue Type: Bug Affects Versions: 3.2 Environment: linux, normal pc Reporter: Eduardo Burgos Assignee: Adrian Co revision: 551635 cd trunk svn up at revision 551635 when I try to build everything it has this error: [INFO] Building ServiceMix :: Archetypes :: BindingComponent [INFO]task-segment: [clean, install] [INFO] . . . [INFO] Starting audit... /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyEndpointType.java:17: Missing package declaration. /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyComponent.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyBootstrap.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyConsumerEndpoint.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyProviderEndpoint.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/test/java/MySpringComponentTest.java:19:1: Got an exception - expecting EOF, found 'import' Audit done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-990) FilePoller with Archiving
FilePoller with Archiving - Key: SM-990 URL: https://issues.apache.org/activemq/browse/SM-990 Project: ServiceMix Issue Type: Improvement Components: servicemix-components, servicemix-file Affects Versions: 3.1 Reporter: Juergen Mayrbaeurl Priority: Minor The various FilePoller implementations should archive the files before deleting them (e.g. by copying them to another directory) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: patch0629.txt This patch 1. test CXF bc work with CXF se to handle external request, return the correct Fault type defined by wsdl 2. support config interceptors in xbean.xml Since this patch depend on some changes from cxf, so need mvn -U install to build it CXF based Service Engine and Bnding Component - Key: SM-939 URL: https://issues.apache.org/activemq/browse/SM-939 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Freeman Fang Priority: Critical Fix For: 3.2 Attachments: patch.txt, patch0627.txt, patch0629.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SM-991) servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml
servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml Key: SM-991 URL: https://issues.apache.org/activemq/browse/SM-991 Project: ServiceMix Issue Type: Bug Components: servicemix-saxon Affects Versions: 3.2, incubation Reporter: Piotr Bzdyl Attachments: servicemix-saxon-service-unit-analyzer.diff.txt Due to lack of Service unit analyzer in the servicemix-saxon component, generated jbi.xml file doesn't contain services provided by saxon service unit (there is no problem with consumed services since saxon endpoints are only providers). I am attaching patch containing very simple service unit analyzer and change in pom.xml adding this analyzer to the built component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: servicemix-sca: updating tuscany dependency
Sounds good. If you already have something set up...that's fine with me. Kit Brian O'Neill wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Brian O'Neill wrote: OK, per Guillaume's suggestion perhaps we start anew basing everything on 0.90 sca. So, what are peoples thoughts towards the design of the translation layer? Should we leverage Tuscany's parsing capabilities to read in the SCA contribution? Then, from the parsed structure generate the service-unit JBI artifacts? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- Jean-Sebastien
Re: servicemix-sca: updating tuscany dependency
On 6/29/07, Brian O'Neill [EMAIL PROTECTED] wrote: All, OK. So I officially started a new service engine. Guillaume, I figured I would use servicemix-bean as a template. Does that make sense to you? Sure, though I would have started with something more simple like servicemix-saxon, but servicemix-bean is closer I guess but more complicated. Anyway, I you have any questions, feel free to ask. Jean-Sebastien, thanks for the pointers. I'll get the servicemix-bean up and running with the new name of servicemix-java-sca, then incorporate the tuscany stuff. Kit, we should figure out how we are going to work together on this? I've got a spare svn repo we could work out of. -brian On 6/28/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: [snip] Brian O'Neill wrote: OK, per Guillaume's suggestion perhaps we start anew basing everything on 0.90 sca. So, what are peoples thoughts towards the design of the translation layer? Should we leverage Tuscany's parsing capabilities to read in the SCA contribution? Then, from the parsed structure generate the service-unit JBI artifacts? Just a thought about that translation layer... If you only need the SCA contribution and assembly models and the ability to read SCA assembly XML, you don't have to use the whole Tuscany runtime. We've rearchitected Tuscany SCA a few months ago to support that kind of scenario and make it easy to reuse / embed a subset of Tuscany modules in tools, generators, and platforms that are only interested in the SCA metadata without dragging the whole thing. The Tuscany modules are there: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/ For the SCA assembly, SCA contribution and policy metadata models alone, grab these modules: assembly interface contribution policy Support for Java and WSDL interfaces, and Java component implementations: interface-java interface-wsdl implementation-java Support for reading SCA assembly XML and handling SCA contributions: assembly-xml interface-java-xml (also introspects Java interfaces) interface-wsdl-xml (also introspects WSDL portTypes) implementation-java-xml contribution-impl These modules are self contained and should provide you with the ability to process SCA contributions and read SCA assembly XML, without dependencies on the Tuscany runtime, IoC container, etc. To draw an analogy with other projects, you could compare that level of function with packages like WSDL4J or Woden for WSDL for example: Models and the ability to read/write them. Hope this helps -- Jean-Sebastien -- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024 -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
[jira] Closed: (SM-977) wsdl-first example fails: XFireFault (could not unmarshal type)
[
https://issues.apache.org/activemq/browse/SM-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert Vanthienen closed SM-977.
--
Resolution: Fixed
Fix Version/s: 3.2
3.1.2
http://svn.apache.org/viewvc?view=revrevision=552098
http://svn.apache.org/viewvc?view=revrevision=552099
wsdl-first example fails: XFireFault (could not unmarshal type)
---
Key: SM-977
URL: https://issues.apache.org/activemq/browse/SM-977
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.1.2
Reporter: Gert Vanthienen
Fix For: 3.1.2, 3.2
After 'resolving' SM-960, the wsdl-first example no longer works. It throws
this exception, caused by differences in namespace. The original wsdl file
has it's GetPerson element in another namespace than the one that is being
shown when browsing for the wsdl after deployment.
{noformat}
org.codehaus.xfire.fault.XFireFault: Could not unmarshall type : unexpected
element (uri:http://servicemix.apache.org/samples/wsdl-first;,
local:GetPerson). Expected elements are
{http://servicemix.apache.org/samples/wsdl-first/types}GetPerson,{http://servicemix.apache.org/samples/wsdl-first/types}GetPersonResponse,{http://servicemix.apache.org/samples/wsdl-first/types}UnknownPersonFault
at org.codehaus.xfire.jaxb2.JaxbType.readObject(JaxbType.java:216)
at
org.codehaus.xfire.jaxws.JAXWSOperationBinding.readMessage(JAXWSOperationBinding.java:159)
at
org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42)
at
org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at
org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64)
at
org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38)
at
org.apache.servicemix.jsr181.Jsr181ExchangeProcessor.process(Jsr181ExchangeProcessor.java:113)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:538)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:490)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:171)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Geronimo-Tuscany integration
Hi Jean-Sebastien, I have put the comments inline. Vamsavardhana Reddy wrote: Hi, Myself and Manu have done some work (a small PoC) on Geronimo Tuscany integration. As a first step, we have created a plugin for Geronimo that will let the user to deploy standalone tuscany modules into Geronimo and use the deployed services by looking up in JNDI. I have put the code in Geronimo Sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/. Great! I started to look at it, I'll try to get it running but it may take a few days before I get to it. Which version of Geronimo should I use? M6 or Trunk? the full J2EE server or is Little-G sufficient? We had tried it out with Trunk. M6 will not work as we fixed a JIRA with geronimo to get this to work. I think the JIRA is not in M6. The JIRA is GERONIMO-3242. Not sure abt Little G but don't see any reason it shouldn't work. Going forward, we have the following in mind: A) Write a deploymentwatcher so that Tuscany modules can be bundled as part of J2EE artifacts. More on this below in my answer to your question (2). B) Extend the current deployer to enable Tuscany Modules deployed in Geronimo to access resources like datasources from Geronimo Will the datasources be used internally by a Data Access component runtime (like the Tuscany DAS extension) or an ODE/BPEL component integration runtime (which I think uses a database) for example? Or are you thinking about exposing the datasources to application code, and if it's the case, what will an application developer have to write to use them? What we were thinking was to expose datasources to application code. An application developer will have to use InitialContext.lookup to access the datasource. We were thinking of a JEE style of programming. If the component implementation is Java inside the implementation he can lookup datasources and use them thereby leveraging the connection pooling infrastructure of Geronimo. I am not familiar with the Tuscany DAS extension but I guess we can get it to use the Geronimo Datasource. The basic idea was to leverage the connection pooling functionality of Geronimo for sca services that use data from databases. But from what i see an SCA component developer will be using the Tuscany DAS extension and so it will be of more value if that can utilize the server connection pooling. Please correct me if I am wrong. I am yet to read up the DAS stuff. Some of the questions we have are: 1. Should we use this plugin approach and host the plugin separatley or intergrate Tuscany to be bundled as part of the Geronimo distribution? The plugin approach looks OK to me, but maybe somebody from the Geronimo project could give a more educated opinion? I believe we can start with a plugin approach but if we run into some problems with implementation as a plugin then probably we can think of full fledged integration. Can someone from the Geronimo community with expertise here, please give their opinions on this. 2. Should we have support for bundling Tuscany composites in WAR, EJB-JAR and EAR? Or should we provide for adding a separate Tuscany module in EAR? This is similar to a question you had in a previous thread, see question (1) in [1]. I had the following scenarios in mind, with my application developer hat on: Ok the below scenarios clear up a lot of questions. And first as you have mentioned we can start with (a) and (c) (a) I develop SCA components, assemble them in a composite, package them in an SCA contribution. I don't really know what a WAR or an EAR is, I'm just using the SCA programming model and packaging model. I deploy my SCA contribution to Geronimo and run it there. I think we can get this working first. Probably if there is no deployment descriptors I can give the JAR to the tuscany runtime and let it decide whether it is a valid tuscany contribution. The only issue is without (c) there is no way we can use the services in JEE artifacts. (b) I'm assembling SCA components, some of them developed using the SCA programming model (Java components, BPEL components or composite components for example) and I want to re-use an EJB module in my assembly, allowing other SCA components to talk to its session beans using the SCA programming model. That EJB module does not know anything about SCA, it only uses the EJB programming model. (c) I want to use a Web app in my SCA assembly and call SCA components from it. I should be able to declare an SCA component representing my Web app, wire that component to other SCA components in the assembly, and then magically the wired references will be available as proxies for use in my JSPs, allowing me to call an SCA component using a simple jsp:useBean tag. AFAIK this may require some extensions to tuscany as well to support implementation.web. Probably referenced service proxies should be available in the application context. (d) I want to bundle SCA
Re: Geronimo/Tuscany integration
Hi Jean-Sebastien, Thank you for the very detailed responses and links. I am still in the process of going through the SCA specs. With my current understanding I have put in responses inline On 6/27/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Raymond is away for one more week, so I'll try to answer some of these questions. Manu George wrote: Hi Raymond/Jay, I would like to join this effort. I would like to discuss what is expected of the deep integration. I will just list down my understanding of both the current and proposed integrations Understanding of the Current Integration 1) TuscanyContextListener creates an SCA domain when the servlet is created and then destroys it when the servlet is destroyed. 2) During SCA domain creation it looks up the composites and deploys them in the domain Creates a webapp module activator for registering servlet hosts. 3) Finally we have a servlet that forwards requests to the servlet registered with the Tuscany Servlet Host. 4) An SCADomain is created for each application and we can lookup the services from the SCADomain. 5) During SCADomain creation a runtime is also created for the DefaultSCADomain. 7) All tuscany classes are loaded repeatedly for each application in separate classloaders. 8) A runtime is created per application Correct. I'm assuming that you're talking about the current Webapp integration. Thanks for the clarification As a heads up the SCADomain class is probably going to change a bit to load a subset of components deployed to an actual SCA domain. The idea is to distribute an SCA domain across runtimes, each runtime running one or more domain level SCA components (and components nested in their composites). I believe there is functionality being added to even add composites to already initialized Domains. Probably we need to leverage that also in the future. Understanding/Doubts about the proposed Integration. 1) Each SCA application will have an SCA module which will be a jar with an SCDL in META-INF. This jar can also be part of an EAR. . There will be a Tuscany deployer that will take care of deploying the SCA modules. Should WAR files be also able to contain SCA jars? Will the application developer be exposed to this? If it's the case then it looks like a new programming / packaging model, different from SCA :) We changed that approach :) but still we have a geronimo-tuscany.xml file in META-INF.xml. An SCA application developer normally packages application artifacts in an SCA contribution (a form of archive described in the SCA assembly spec) and the .composite (SCDL) files are not necessarily under META-INF. in fact usually we place them with the other development artifacts, .Java, .wsdl, .groovy etc. I was hoping that the application developer wouldn't have to learn a different packaging model to run his SCA components on Geronimo. Will there be a way to deploy an SCA contribution to Geronimo natively without having to repackage it in a J2EE archive? From what I understood from the SCA Assembly spec, a jar can be one of the ways an SCA Contribution can be packaged. So ideally a jar which has tuscany artifacts should be deployable in Geronimo. There are other contributions like folder contribution etc. But I guess initially we can build in support for jar/zip file contribution. In the current POC we have a geronimo-tuscany.xml in META-INF. The SCDLs are packaged as per SCA assembly specs. The geronimo-tuscany.xml was used to specify the jndi name to which the SCA Domain was bound to as well as the Domain URI. We were not sure how to generate the Domain URI for an SCADomain deployed in Geronimo. Some suggestions here would be welcome. I guess we may be able to remove the geronimo-tuscany.xml if we need not bind the domain in JNDI. Now on reading the integration whitepaper, JEE artifacts will be able to access the services by exposing the JEE module as a contribution and declaring the services as references in the JEE artifacts. So probably the proxies to services can be bound in jndi. 2) Each App will have an SCA Domain which will be instantiated when the application starts. Is this assumption correct or can there be multiple SCADomains per app? The objects deployed to an SCA domain and which run on an SCA runtime are SCA components. There is no concept of an App like a J2EE App in SCA at the moment. Components can be implemented by a simple Java class, a BPEL process, a script, etc. or a Composite. A Composite describes an assembly of Components, allowing for nested composition of components. An SCA domain is described by a composite, describing the assembly of top level components in an administration domain. The SCA domain composite does not necessarily have to written to a single .composite file since it has to be distributed, but it is effectively modeled as a composite. So to go back to your question, objects that run on an SCA runtime are SCA
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
Hi Jean-Sebastien, I have put the comments inline. Vamsavardhana Reddy wrote: Hi, Myself and Manu have done some work (a small PoC) on Geronimo Tuscany integration. As a first step, we have created a plugin for Geronimo that will let the user to deploy standalone tuscany modules into Geronimo and use the deployed services by looking up in JNDI. I have put the code in Geronimo Sandbox at https://svn.apache.org/repos/asf/geronimo/sandbox/tuscany-integration/. Great! I started to look at it, I'll try to get it running but it may take a few days before I get to it. Which version of Geronimo should I use? M6 or Trunk? the full J2EE server or is Little-G sufficient? We had tried it out with Trunk. M6 will not work as we fixed a JIRA with geronimo to get this to work. I think the JIRA is not in M6. The JIRA is GERONIMO-3242. Not sure abt Little G but don't see any reason it shouldn't work. Going forward, we have the following in mind: A) Write a deploymentwatcher so that Tuscany modules can be bundled as part of J2EE artifacts. More on this below in my answer to your question (2). B) Extend the current deployer to enable Tuscany Modules deployed in Geronimo to access resources like datasources from Geronimo Will the datasources be used internally by a Data Access component runtime (like the Tuscany DAS extension) or an ODE/BPEL component integration runtime (which I think uses a database) for example? Or are you thinking about exposing the datasources to application code, and if it's the case, what will an application developer have to write to use them? What we were thinking was to expose datasources to application code. An application developer will have to use InitialContext.lookup to access the datasource. We were thinking of a JEE style of programming. If the component implementation is Java inside the implementation he can lookup datasources and use them thereby leveraging the connection pooling infrastructure of Geronimo. I am not familiar with the Tuscany DAS extension but I guess we can get it to use the Geronimo Datasource. The basic idea was to leverage the connection pooling functionality of Geronimo for sca services that use data from databases. But from what i see an SCA component developer will be using the Tuscany DAS extension and so it will be of more value if that can utilize the server connection pooling. Please correct me if I am wrong. I am yet to read up the DAS stuff. Some of the questions we have are: 1. Should we use this plugin approach and host the plugin separatley or intergrate Tuscany to be bundled as part of the Geronimo distribution? The plugin approach looks OK to me, but maybe somebody from the Geronimo project could give a more educated opinion? I believe we can start with a plugin approach but if we run into some problems with implementation as a plugin then probably we can think of full fledged integration. Can someone from the Geronimo community with expertise here, please give their opinions on this. 2. Should we have support for bundling Tuscany composites in WAR, EJB-JAR and EAR? Or should we provide for adding a separate Tuscany module in EAR? This is similar to a question you had in a previous thread, see question (1) in [1]. I had the following scenarios in mind, with my application developer hat on: Ok the below scenarios clear up a lot of questions. And first as you have mentioned we can start with (a) and (c) (a) I develop SCA components, assemble them in a composite, package them in an SCA contribution. I don't really know what a WAR or an EAR is, I'm just using the SCA programming model and packaging model. I deploy my SCA contribution to Geronimo and run it there. I think we can get this working first. Probably if there is no deployment descriptors I can give the JAR to the tuscany runtime and let it decide whether it is a valid tuscany contribution. The only issue is without (c) there is no way we can use the services in JEE artifacts. (b) I'm assembling SCA components, some of them developed using the SCA programming model (Java components, BPEL components or composite components for example) and I want to re-use an EJB module in my assembly, allowing other SCA components to talk to its session beans using the SCA programming model. That EJB module does not know anything about SCA, it only uses the EJB programming model. (c) I want to use a Web app in my SCA assembly and call SCA components from it. I should be able to declare an SCA component representing my Web app, wire that component to other SCA components in the assembly, and then magically the wired references will be available as proxies for use in my JSPs, allowing me to call an SCA component using a simple jsp:useBean tag. AFAIK this may require some extensions to tuscany as well to support implementation.web. Probably referenced service proxies should be available in the application context. (d) I want to bundle SCA
Re: Now that we have Lifecycle Listeners...the next step
On 6/29/07, Jeff Genender [EMAIL PROTECTED] wrote: Now that we have Lifecycle Listeners, I want to start a little discussion around some of the Tomcat listeners that come standard installed in their container and whether we include them or not in the default plan. Currently Tomcat has the following listeners attached to their standalone container: (Full package names included here for folks who want to look at the Tomcat source) org.apache.catalina.core.AprLifecycleListener org.apache.catalina.mbeans.ServerLifecycleListener org.apache.catalina.mbeans.GlobalResourcesLifecycleListener org.apache.catalina.storeconfig.StoreConfigLifecycleListener AprLifecycleListener - Init and and destroy APR. ServerLifecycleListener - Instantiates the set of MBeans associated with the components of a running instance of Catalina. GlobalResourcesLifecycleListener - Instantiates the set of MBeans associated with global JNDI resources that are subject to management. StoreConfigLifecycleListener - Load and Register StoreConfig MBean Catalina:type=StoreConfig,resource=url I think we can rewrite our own ServerLifecycleListener to have Tomcat use our mbean server instead of them creating their own. That would allow their objects show up in our server, so I think we should add something like that class. IIUC, org.apache.tomcat.util.modeler.Registry.getMBeanServer() is the method that hooks up the MBeanServer with which tomcat registers its MBeans. Also, tomcat is not creating an MBean server of its own to register its MBeans with. It is using the first one in the results from MBeanServerFactory.findMBeanServer(null) which returns all the registered MBeanServers. If there are no MBeanServers, then it creates one. Geronimo was doing the same (though not intentional??) until GERONIMO-3268. I have gone through the ServerLifecycleListener class. I could not figure how to make tomcat register its MBeans with our MBeanServer without modifying org.apache.tomcat.util.modeler.Registry. Anything you are seeing which I am failing to see. The GlobalResourcesLifecycleListener and StoreConfigLifecycleListener I am not sure if we need, but if we were to use them we may want our own impls to it follows our Object naming scheme. But most importantly I want to talk about the AprLifecycleListener. I really think we should add this as a default listener in the plan because this will allow people to use a netive APR connector and *really* get some incredible performance out of Geronimo. For those not familiar with APR, its the Apache Portable Runtime project. http://apr.apache.org/ It basically will test if you have compiled natice binaries for your platform, and if it find them, it will use those instead of hte pure java implementation. The listener is really for initialization and destruction on start/stop of the server, so there is no overhead. This can really give Geronimo a performance boost, especially for those who use it in a high load site. Thoughts and opinions on me enabling that listener? Also thoughts on some of the other listeners would be good as well. Thanks, Jeff
[jira] Created: (GERONIMO-3273) Tomcat MBeans not getting registered with MBeanServer created by Geronimo
Tomcat MBeans not getting registered with MBeanServer created by Geronimo - Key: GERONIMO-3273 URL: https://issues.apache.org/jira/browse/GERONIMO-3273 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0-M7 Environment: Geronimo Tomcat 2.0-SNAPSHOT Reporter: Vamsavardhana Reddy Fix For: 2.0-M7 When a new JMX Service is configured as given in http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html, Tomcat MBeans are not getting registered with the MBeanServer created by Geronimo. Due to this, Tomcat MBeans are not available through the JMX Service provided by Geronimo. A fix for this may not be possible until the tomcat issue http://issues.apache.org/bugzilla/show_bug.cgi?id=42759 is addressed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: patch0629.txt CXF based Service Engine and Bnding Component - Key: SM-939 URL: https://issues.apache.org/activemq/browse/SM-939 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Freeman Fang Priority: Critical Fix For: 3.2 Attachments: patch.txt, patch0627.txt, patch0629.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-987) Binding Component archetype - can't build
[ https://issues.apache.org/activemq/browse/SM-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Co resolved SM-987. -- Resolution: Fixed Fix Version/s: 3.2 Fix added: http://svn.apache.org/viewvc?view=revrev=551839 Binding Component archetype - can't build - Key: SM-987 URL: https://issues.apache.org/activemq/browse/SM-987 Project: ServiceMix Issue Type: Bug Affects Versions: 3.2 Environment: linux, normal pc Reporter: Eduardo Burgos Assignee: Adrian Co Fix For: 3.2 revision: 551635 cd trunk svn up at revision 551635 when I try to build everything it has this error: [INFO] Building ServiceMix :: Archetypes :: BindingComponent [INFO]task-segment: [clean, install] [INFO] . . . [INFO] Starting audit... /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyEndpointType.java:17: Missing package declaration. /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyComponent.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyBootstrap.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyConsumerEndpoint.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/main/java/MyProviderEndpoint.java:19:1: Got an exception - expecting EOF, found 'import' /src/servicemix/trunk/archetypes/servicemix-binding-component/src/main/resources/archetype-resources/src/test/java/MySpringComponentTest.java:19:1: Got an exception - expecting EOF, found 'import' Audit done. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
Hi All, Can someone review and apply this patch? patch0629.txt Thanks very much Freeman Freeman Fang (JIRA) wrote: [ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: (was: patch0629.txt) CXF based Service Engine and Bnding Component - Key: SM-939 URL: https://issues.apache.org/activemq/browse/SM-939 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Freeman Fang Priority: Critical Fix For: 3.2 Attachments: patch.txt, patch0627.txt
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: (was: patch0629.txt) CXF based Service Engine and Bnding Component - Key: SM-939 URL: https://issues.apache.org/activemq/browse/SM-939 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Assignee: Freeman Fang Priority: Critical Fix For: 3.2 Attachments: patch.txt, patch0627.txt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Now that we have Lifecycle Listeners...the next step
On Jun 28, 2007, at 5:10 PM, Jeff Genender wrote: snip But most importantly I want to talk about the AprLifecycleListener. I really think we should add this as a default listener in the plan because this will allow people to use a netive APR connector and *really* get some incredible performance out of Geronimo. For those not familiar with APR, its the Apache Portable Runtime project. http://apr.apache.org/ It basically will test if you have compiled natice binaries for your platform, and if it find them, it will use those instead of hte pure java implementation. The listener is really for initialization and destruction on start/stop of the server, so there is no overhead. This can really give Geronimo a performance boost, especially for those who use it in a high load site. Thoughts and opinions on me enabling that listener? Also thoughts on some of the other listeners would be good as well. Nice. I like the idea. I see no reason not to enable this feature in Geronimo and good reasons to include it! So, would you propose including tomcat-native.tar.gz in our assembly? A little doc on building native libs and how to enable APR (if user desires). IIUC, everything runs fine out-of-the-box (we create APR connectors, but they can't load native libs and run exactly as the current connectors run today). If a user wants to enable APR, it requires something like: tar zvf tomcat-native.tar.gz cd tomcat-native ant start geronimo --kevan
Re: svn commit: r551608 - in /geronimo/server/trunk: assemblies/geronimo-boilerplate-minimal/src/main/resources/bin/ maven-plugins/geronimo-maven-plugin/src/main/java/org/apache/geronimo/mavenplugins/
On Jun 28, 2007, at 5:54 PM, David Jencks wrote: This looks to me like a dreadful approach. Did you try including the property in defaultPersistenceUnitProperties in the persistence builder config module xmlns=http://geronimo.apache.org/xml/ns/deployment-1.1; gbean name=PersistenceUnitBuilder class=org.apache.geronimo.persistence.builder.PersistenceUnitBuilder attribute name=defaultPersistenceProviderClassNameorg.apache.openjpa.persiste nce.PersistenceProviderImpl/attribute attribute name=extendedEntityManagerRegistryName? name=ExtendedEntityManagerRegistry#org.apache.geronimo.persistence.Ext endedEntityManagerRegistry/attribute attribute name=defaultPersistenceUnitProperties openjpa.Log=commons openjpa.ClassTransformerOptions=ScanDevPath=true openjpa.jdbc.DBDictionary=org.apache.openjpa.jdbc.sql.DerbyDictionary openjpa.jdbc.SynchronizeMappings=buildSchema (ForeignKeys=true,SchemaAction='add,deleteTableContents') openjpa.Sequence=table(Table=OPENJPASEQ, Increment=100) /attribute xml-attribute name=defaultEnvironment environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.1 dependencies dependency groupIdorg.apache.geronimo.configs/groupId artifactIdopenjpa/artifactId typecar/type /dependency /dependencies /environment /xml-attribute /gbean Setting the property on defaultPersistenceUnitProperties doesn't work. Setting the property in CmpJpaConversion.java in OpenEJB didn't work, either. I'll dig further. First, however, I'll have a look at remaining tck problems... --kevan
Re: svn commit: r550656 - /geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java
Agree. I'll update the log statement to include the stack trace. Thanks for reviewing and commenting on the change. -Donald Kevan Miller wrote: On Jun 28, 2007, at 12:11 AM, David Jencks wrote: On Jun 26, 2007, at 7:08 PM, Donald Woods wrote: Was just going on Kevan's response to YunFeng, that we shouldn't be using printStackTrace() in the code - http://www.nabble.com/Why-printStackTrace%28%29-in-the-source-codes-tf3975719s134.html Heh. Sure... Blame it all on me... ;-) I don't have a problem with logging the stack trace rather than printing it to the console, but even printStackTrace IMO is not a really big deal since the exception will only occur when someone has written a broken integration of something that needs xa. For instance I think openejb mdbs are currently broken this way. Right. I have no objections to logging stack traces, where we think they would be useful. My main point was that we should be thinking in terms of logging information, not printing. The geronimo log should contain the information needed to identify/diagnose a problem (not a random mixture of logging and direct printing to STDOUT/STDERR). --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Geronimo-Tuscany integration(Sending to both lists)
On Jun 29, 2007, at 3:11 AM, Manu George wrote: Some of the questions we have are: 1. Should we use this plugin approach and host the plugin separatley or intergrate Tuscany to be bundled as part of the Geronimo distribution? The plugin approach looks OK to me, but maybe somebody from the Geronimo project could give a more educated opinion? I believe we can start with a plugin approach but if we run into some problems with implementation as a plugin then probably we can think of full fledged integration. Can someone from the Geronimo community with expertise here, please give their opinions on this. Implementing as a plugin should not affect the technical design of this component. I don't know of anything you can do in a component integrated into Geronimo at assembly time that you cannot do in a plugin integrated after installation. A plugin is really just a component that has been preconfigured for rapid deployment and dependency downloading. It's a packaging decision. IMO new components created for Geronimo that are not required by the JEE specification should be implemented as plugins. This is a rule of thumb, and in some cases there may be justification for an exception. Like for example if we believed that almost every Geronimo user will need SOA then we should discuss full fledged integration. Another type of exception would be if we think that the component would provide useful services to Geronimo's native components. Best wishes, Paul
[jira] Resolved: (SM-963) NullPointerExceptions during JMS component initialization
[ https://issues.apache.org/activemq/browse/SM-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-963. Resolution: Fixed Fix Version/s: 3.2 3.1.2 Assignee: Guillaume Nodet URL: http://svn.apache.org/viewvc?view=revrev=551899 URL: http://svn.apache.org/viewvc?view=revrev=551900 NullPointerExceptions during JMS component initialization - Key: SM-963 URL: https://issues.apache.org/activemq/browse/SM-963 Project: ServiceMix Issue Type: Bug Components: servicemix-jms Affects Versions: 3.2, incubation Environment: Windows XP, JDK 1.5.0_11 Reporter: Piotr Bzdyl Assignee: Guillaume Nodet Fix For: 3.1.2, 3.2 Attachments: MultiplexingConsumerProcessor.java.patch Currently org.apache.servicemix.jms.AbstractJmsProcessor.start() starts JMS connection (and thus starts fetching messages on all already registered and all new registered listeners) before org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor initializes its pendingMessages map in doStart() method. It can be resolved by: 1) moving initialization of MultiplexingConsumerProcessor.pendingMessages before consumer.setMessageListener(this); Also initializing MultiplexingConsumerProcessor.channel field should be done before any message arrives via listener's onMessage method. OR 2) starting JMS connection in org.apache.servicemix.jms.AbstractJmsProcessor.start() after whole initialization in subclasses is done (after doStart()) I am attaching patch for the first solution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
jetty:run-exploded for Geronimo?
Hi, I wonder whether it's possible to run ear similarly to jetty:run-exploded with geronimo-maven-plugin. Is that doable with the current version of the plugin? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Now that we have Lifecycle Listeners...the next step
Vamsavardhana Reddy wrote: IIUC, org.apache.tomcat.util.modeler.Registry.getMBeanServer() is the method that hooks up the MBeanServer with which tomcat registers its MBeans. Also, tomcat is not creating an MBean server of its own to register its MBeans with. It is using the first one in the results from MBeanServerFactory.findMBeanServer(null) which returns all the registered MBeanServers. If there are no MBeanServers, then it creates one. Geronimo was doing the same (though not intentional??) until GERONIMO-3268. I have gone through the ServerLifecycleListener class. I could not figure how to make tomcat register its MBeans with our MBeanServer without modifying org.apache.tomcat.util.modeler.Registry. Anything you are seeing which I am failing to see. It appears the MBeans are registered in the listener with the MBeanFactor (AFAICT). I assume (yes just assuming by perusing the code) that we can swap out calls in here to register mbeans with our server. In otherwords, we could use our own MBeanFactory. In any case if its not doable then we go down the patch route which is fine. Jeff
Re: Now that we have Lifecycle Listeners...the next step
Kevan Miller wrote: On Jun 28, 2007, at 5:10 PM, Jeff Genender wrote: snip But most importantly I want to talk about the AprLifecycleListener. I really think we should add this as a default listener in the plan because this will allow people to use a netive APR connector and *really* get some incredible performance out of Geronimo. For those not familiar with APR, its the Apache Portable Runtime project. http://apr.apache.org/ It basically will test if you have compiled natice binaries for your platform, and if it find them, it will use those instead of hte pure java implementation. The listener is really for initialization and destruction on start/stop of the server, so there is no overhead. This can really give Geronimo a performance boost, especially for those who use it in a high load site. Thoughts and opinions on me enabling that listener? Also thoughts on some of the other listeners would be good as well. Nice. I like the idea. I see no reason not to enable this feature in Geronimo and good reasons to include it! Great! I'll do it. So, would you propose including tomcat-native.tar.gz in our assembly? A little doc on building native libs and how to enable APR (if user desires). I dont know about including the drivers (except for Windows) since the Unix libs would clash. But yes, I think we should have a wiki entry similar to Tomcat's found here: http://tomcat.apache.org/tomcat-6.0-doc/apr.html We could also pre-build a few of the more popular ones so people could just download them (ie. Windows, Linux 32 bit, Linux 64 bit, MacOSX, Solaris). IIUC, everything runs fine out-of-the-box (we create APR connectors, but they can't load native libs and run exactly as the current connectors run today). If a user wants to enable APR, it requires something like: tar zvf tomcat-native.tar.gz cd tomcat-native ant start geronimo Yup...exactly. I'll enable it in the plan ;-) Jeff --kevan
[jira] Assigned: (SM-991) servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml
[ https://issues.apache.org/activemq/browse/SM-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SM-991: -- Assignee: Guillaume Nodet servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml Key: SM-991 URL: https://issues.apache.org/activemq/browse/SM-991 Project: ServiceMix Issue Type: Bug Components: servicemix-saxon Affects Versions: 3.2, incubation Reporter: Piotr Bzdyl Assignee: Guillaume Nodet Fix For: 3.1.2, 3.2 Attachments: servicemix-saxon-service-unit-analyzer.diff.txt Due to lack of Service unit analyzer in the servicemix-saxon component, generated jbi.xml file doesn't contain services provided by saxon service unit (there is no problem with consumed services since saxon endpoints are only providers). I am attaching patch containing very simple service unit analyzer and change in pom.xml adding this analyzer to the built component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SM-991) servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml
[ https://issues.apache.org/activemq/browse/SM-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-991. Resolution: Fixed Fix Version/s: 3.2 3.1.2 URL: http://svn.apache.org/viewvc?view=revrev=551915 URL: http://svn.apache.org/viewvc?view=revrev=551916 servicemix-saxon component lacks ServiceUnit analyzer which results in generating incomplete jbi.xml Key: SM-991 URL: https://issues.apache.org/activemq/browse/SM-991 Project: ServiceMix Issue Type: Bug Components: servicemix-saxon Affects Versions: 3.2, incubation Reporter: Piotr Bzdyl Assignee: Guillaume Nodet Fix For: 3.1.2, 3.2 Attachments: servicemix-saxon-service-unit-analyzer.diff.txt Due to lack of Service unit analyzer in the servicemix-saxon component, generated jbi.xml file doesn't contain services provided by saxon service unit (there is no problem with consumed services since saxon endpoints are only providers). I am attaching patch containing very simple service unit analyzer and change in pom.xml adding this analyzer to the built component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r550656 - /geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java
Updated to log the stack trace as an error in revision 551929. Donald Woods wrote: Agree. I'll update the log statement to include the stack trace. Thanks for reviewing and commenting on the change. -Donald Kevan Miller wrote: On Jun 28, 2007, at 12:11 AM, David Jencks wrote: On Jun 26, 2007, at 7:08 PM, Donald Woods wrote: Was just going on Kevan's response to YunFeng, that we shouldn't be using printStackTrace() in the code - http://www.nabble.com/Why-printStackTrace%28%29-in-the-source-codes-tf3975719s134.html Heh. Sure... Blame it all on me... ;-) I don't have a problem with logging the stack trace rather than printing it to the console, but even printStackTrace IMO is not a really big deal since the exception will only occur when someone has written a broken integration of something that needs xa. For instance I think openejb mdbs are currently broken this way. Right. I have no objections to logging stack traces, where we think they would be useful. My main point was that we should be thinking in terms of logging information, not printing. The geronimo log should contain the information needed to identify/diagnose a problem (not a random mixture of logging and direct printing to STDOUT/STDERR). --kevan smime.p7s Description: S/MIME Cryptographic Signature
@Resource TimerService support
Hi, I'm deploying JBoss Seam on the latest Geronimo (unofficial) build from Prasad and am running into an issue with @Resource TimerService addnotation. 18:59:32,734 ERROR [Deployer] Deployment failed due to org.apache.geronimo.common.DeploymentException: Unable to resolve resource reference 'org.jboss.seam.async.TimerServiceDispatcher/timerService' (Could not auto-map to resource. Tr y adding a resource-ref mapping to your Geronimo deployment plan. Search conducted in current module and dependencies: [ALL: org.apache.geronimo.configs/j2ee-server//car] [ALL: org.apache.geronimo.configs/openejb//car] [ALL: org.apache.geronimo.configs/system-database//car] [ALL: org.apache.geronimo.configs/jetty6//car] [ALL: org.apache.geronimo.configs/openjpa//car] [ALL: org.apache.geronimo.configs/j2ee-corba-yoko//car] [ALL: org.apache.geronimo.configs/axis//car] [ALL: org.apache.geronimo.configs/cxf//car] [ALL: org.apache.openejb/openejb-core//jar] [ALL: org.apache.geronimo.modules/geronimo-openejb//jar] ) at org.apache.geronimo.connector.deployment.ResourceRefBuilder.buildNaming(ResourceRefBuilder.java:202) at org.apache.geronimo.connector.deployment.ResourceRefBuilder$$FastClassByCGLIB$$71dbb49e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) What can I do to work it out? I can't find any reference to TimerService in the code, but since GlassFish and OC4J work with Seam fine I don't believe it's impossible with Geronimo. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Transaction manager now tied to ejb?
This is an easy fix, thanks for noticing the problem... just need a
little more testing before I commit...
thanks
david jencks
On Jun 28, 2007, at 6:03 PM, Dain Sundstrom wrote:
It appears that the geronimo transaction manager is now tied
directly to ejb :( The TransactionManagerImpl class has the
following code:
public void setEntityManager(String persistenceUnit, Object
entityManager) {
Object oldEntityManager = entityManagers.put
(persistenceUnit, entityManager);
if (oldEntityManager != null) {
throw new EJBException(EntityManager +
oldEntityManager + for persistenceUnit + persistenceUnit +
already associated with this transaction + xid);
}
}
This makes it very difficult for me to use the tm manager in light-
weight environments. Can we remove all the JPA and EJB related
stuff from the TransactionManager classes (and module). I was able
to implement all of the JPA required functionality in OpenEJB
without needing to modify the transaction manager.
In the mean time I'll drop back to using the 1.x transaction manager.
-dain
[jira] Created: (GERONIMO-3274) JSF Core tag convertNumber causing exception
JSF Core tag convertNumber causing exception
Key: GERONIMO-3274
URL: https://issues.apache.org/jira/browse/GERONIMO-3274
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: web
Affects Versions: 2.0-M6
Environment: Ubuntu 7.0.4 Sun JDK 1.5.0_11
Reporter: David Carew
Using the JSF core tag f:convertNumber / in a page like this (where the
amount property is an instance of java.math.BigDecimal)
h:outputText value=#{moneyBean.amount}
f:convertNumber type=currency /
/h:outputText
causes the following stack trace
ERROR
org.apache.catalina.core.ContainerBase.[Geronimo].[0.0.0.0].[/jsfbug].[jsp].invoke()
- Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:334)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:801)
[WebBank] ERROR
org.apache.catalina.core.ContainerBase.[Geronimo].[0.0.0.0].[/jsfbug].[Faces
Servlet].invoke() - Servlet.service() for servlet Faces Servlet threw exception
javax.servlet.ServletException: org.apache.jasper.JasperException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
[jira] Updated: (GERONIMO-3274) JSF Core tag convertNumber causing exception
[
https://issues.apache.org/jira/browse/GERONIMO-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carew updated GERONIMO-3274:
--
Attachment: jsfbug.war
Here's a simple web app that illustrates the problem. If you comment out the
f:convertNumber in index.jsp the exception does not occur. Tried this on the
Sun Application Server 9 and it works as expected. To run the app install it
and point your browser to http://localhost:8080/jsfbug/faces/index.jsp
JSF Core tag convertNumber causing exception
Key: GERONIMO-3274
URL: https://issues.apache.org/jira/browse/GERONIMO-3274
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: web
Affects Versions: 2.0-M6
Environment: Ubuntu 7.0.4 Sun JDK 1.5.0_11
Reporter: David Carew
Attachments: jsfbug.war
Using the JSF core tag f:convertNumber / in a page like this (where the
amount property is an instance of java.math.BigDecimal)
h:outputText value=#{moneyBean.amount}
f:convertNumber type=currency /
/h:outputText
causes the following stack trace
ERROR
org.apache.catalina.core.ContainerBase.[Geronimo].[0.0.0.0].[/jsfbug].[jsp].invoke()
- Servlet.service() for servlet jsp threw exception
org.apache.jasper.JasperException
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:292)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:334)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:254)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:132)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:801)
[WebBank] ERROR
org.apache.catalina.core.ContainerBase.[Geronimo].[0.0.0.0].[/jsfbug].[Faces
Servlet].invoke() - Servlet.service() for servlet Faces Servlet threw
exception
javax.servlet.ServletException: org.apache.jasper.JasperException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
[jira] Reopened: (GERONIMO-3255) Combine reduntant plugins into larger plugins that provide the same functionality
[ https://issues.apache.org/jira/browse/GERONIMO-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reopened GERONIMO-3255: Assignee: Jason Warner (was: Paul McMahan) I checked the changes that Paul committed and realized that the punch I had provided was seriously flawed. Many of the files I had moved did not show up. After research and testing, I realized that this was caused by the svn move command. I have reworked the patch so that it now correctly adds the files. This patch can be applied directly onto the current version of j2g. My testing for the previous patch reported incorrectly that the patch functions because I had left jars from the old j2g in the eclipse plugin directory that the tool used to run succesfully. The new patch has been tested on a clean eclipse plugin directory. Combine reduntant plugins into larger plugins that provide the same functionality - Key: GERONIMO-3255 URL: https://issues.apache.org/jira/browse/GERONIMO-3255 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Jason Warner Assignee: Jason Warner Attachments: Geronimo-3255-Revised.patch, Geronimo-3255.patch The J2G conversion tool is implemented as a bunch of plugins for eclipse. Only 3 of these plugins are actually launched using eclipse and the rest are instantiated by one of those 3. The number of plugins can be reduced by consolidating the unnecessary plugins into one of the three that actually are launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3255) Combine reduntant plugins into larger plugins that provide the same functionality
[ https://issues.apache.org/jira/browse/GERONIMO-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-3255: --- Attachment: Geronimo-3255-Revised.patch New patch that includes what the old patch missed. Combine reduntant plugins into larger plugins that provide the same functionality - Key: GERONIMO-3255 URL: https://issues.apache.org/jira/browse/GERONIMO-3255 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: J2G Reporter: Jason Warner Assignee: Jason Warner Attachments: Geronimo-3255-Revised.patch, Geronimo-3255.patch The J2G conversion tool is implemented as a bunch of plugins for eclipse. Only 3 of these plugins are actually launched using eclipse and the rest are instantiated by one of those 3. The number of plugins can be reduced by consolidating the unnecessary plugins into one of the three that actually are launched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r551968 - /geronimo/server/trunk/modules/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java
After many attempts to log stack traces I think I've found that for log4j at any rate log.error(new Exception(message) just logs the message but log.error(watch this!, new Exception(message)) logs the stack trace from the exception. I had some more changes to TransactionImp so I changed to the latter style in rev 552073. thanks david jencks On Jun 29, 2007, at 10:29 AM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Fri Jun 29 10:29:18 2007 New Revision: 551968 URL: http://svn.apache.org/viewvc?view=revrev=551968 Log: GERONIMO-3259 Correctly log the stack trace in TransactionImpl.java Modified: geronimo/server/trunk/modules/geronimo-transaction/src/main/ java/org/apache/geronimo/transaction/manager/TransactionImpl.java Modified: geronimo/server/trunk/modules/geronimo-transaction/src/ main/java/org/apache/geronimo/transaction/manager/TransactionImpl.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-transaction/src/main/java/org/apache/geronimo/transaction/ manager/TransactionImpl.java?view=diffrev=551968r1=551967r2=551968 == --- geronimo/server/trunk/modules/geronimo-transaction/src/main/ java/org/apache/geronimo/transaction/manager/TransactionImpl.java (original) +++ geronimo/server/trunk/modules/geronimo-transaction/src/main/ java/org/apache/geronimo/transaction/manager/TransactionImpl.java Fri Jun 29 10:29:18 2007 @@ -17,6 +17,9 @@ package org.apache.geronimo.transaction.manager; +import java.io.PrintWriter; +import java.io.StringWriter; +import java.io.Writer; import java.util.ArrayList; import java.util.HashMap; import java.util.IdentityHashMap; @@ -709,7 +712,10 @@ // if it isn't a named resource should we really stop all processing here! // Maybe this would be better to handle else where and do we really want to prevent all processing of transactions? Throwable throwable = new IllegalStateException (Cannot log transactions as + committer + is not a NamedXAResource.); -log.error(throwable.printStackTrace()); +Writer w = new StringWriter(); +PrintWriter pw = new PrintWriter(w); +throwable.printStackTrace(pw); +log.error(w.toString()); return committer.toString(); } }
[jira] Closed: (GERONIMO-3272) Coalesce the 2 transaction modules into one
[ https://issues.apache.org/jira/browse/GERONIMO-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3272. -- Resolution: Fixed Done in rev 552073. Also fixed jpa stuff to use spec interfaces and not pull ejb spec into the tm module. Also re-fixed logging a stacktrace when a non-NamedXAResource is supplied. Coalesce the 2 transaction modules into one --- Key: GERONIMO-3272 URL: https://issues.apache.org/jira/browse/GERONIMO-3272 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 2.0-M6 Reporter: David Jencks Assignee: David Jencks Fix For: 2.0-M7 We're firmly on jdk 1.5/ javaee5 so we should coalesce the transaction managers into one module and see if anything can be simplified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Transaction manager now tied to ejb?
This should be fixed in rev 552073. Let me know if there are more
problems.
thanks
david jencks
On Jun 29, 2007, at 11:18 AM, David Jencks wrote:
This is an easy fix, thanks for noticing the problem... just need a
little more testing before I commit...
thanks
david jencks
On Jun 28, 2007, at 6:03 PM, Dain Sundstrom wrote:
It appears that the geronimo transaction manager is now tied
directly to ejb :( The TransactionManagerImpl class has the
following code:
public void setEntityManager(String persistenceUnit, Object
entityManager) {
Object oldEntityManager = entityManagers.put
(persistenceUnit, entityManager);
if (oldEntityManager != null) {
throw new EJBException(EntityManager +
oldEntityManager + for persistenceUnit + persistenceUnit +
already associated with this transaction + xid);
}
}
This makes it very difficult for me to use the tm manager in light-
weight environments. Can we remove all the JPA and EJB related
stuff from the TransactionManager classes (and module). I was
able to implement all of the JPA required functionality in OpenEJB
without needing to modify the transaction manager.
In the mean time I'll drop back to using the 1.x transaction manager.
-dain
