[jira] Commented: (GERONIMO-3963) Remote deployment using the --inPlace option
[ https://issues.apache.org/jira/browse/GERONIMO-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590319#action_12590319 ] Jacques Le Roux commented on GERONIMO-3963: --- I did not test it completly, but I suppose that it can work also in an heterogeneous environment, at least from Windows to Linux. you will then have to create a directory structure like for instance : on Windows (default) C:\Program Files\IBM\WebSphere\AppServerCommunityEdition on Linux C\Program Files\IBM\WebSphere\AppServerCommunityEdition\var\config The same should also work in reverse side. Maybe as David Jencks suggested in http://www.nabble.com/Re%3A-Remote-deployment-using---inPlace-option-p16751482s134.html it should be better to update the documentation to avoid other bad experiences. For instance make clear that RMI will not look back at the client inPlace structure from the server. Thanks Remote deployment using the --inPlace option Key: GERONIMO-3963 URL: https://issues.apache.org/jira/browse/GERONIMO-3963 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.x Environment: Tested on Windows XP but Linux should be the same except the drive constraint Reporter: Jacques Le Roux Priority: Minor Remote deployment using the --inPlace option (for a totally exploded EAR with exploded and only exploded WARs inside) is only possible if you exactly replicate the deployed directory structure on both the client and the server machine. If you are on Windows you must even replicate the drive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21
[ https://issues.apache.org/jira/browse/GERONIMO-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590332#action_12590332 ] Michał Kudła commented on GERONIMO-3959: I removed from ejb-jar.xml stanza interceptors interceptor interceptor-class examples.session.stateless_dd.RetrieveOrderCallbacks /interceptor-class post-construct lifecycle-callback-method construct /lifecycle-callback-method /post-construct pre-destroy lifecycle-callback-method destroy /lifecycle-callback-method /pre-destroy /interceptor /interceptors after that, OrderEAR was loaded successfully. Freeze during deploying OrderEAR sample from GMOxDOC21 --- Key: GERONIMO-3959 URL: https://issues.apache.org/jira/browse/GERONIMO-3959 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.1 Environment: Gentoo Linux 2.6.22, Java IBM J9 2.4 Linux x86-32 jvmxi3260-20071121_15015 Reporter: Michał Kudła Priority: Blocker Attachments: GMOxDOC21_Order.zip I created EAR according to http://cwiki.apache.org/GMOxDOC21/deployment-plans.html. But, unedr deployment, Geronimo stoped without any messages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Fwd: Cron [EMAIL PROTECTED] /home/jdillon/ws/site/bin/sync
Getting a fairly constant spam from the website sync script... --jason Begin forwarded message: From: [EMAIL PROTECTED] (Cron Daemon) Date: April 18, 2008 7:19:18 PM GMT+07:00 To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] /home/jdillon/ws/site/bin/sync chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/ MANIFEST.MF: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/LICENSE: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/NOTICE: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.AnnotationInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.ClassInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.FieldInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.Info.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.InfoBuildingVisitor.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.MethodInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.PackageInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ResourceFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/UrlSet.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.AnnotationInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.ClassInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.FieldInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.Info.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.InfoBuildingVisitor.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.MethodInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.PackageInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-frame.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-summary.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-tree.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-use.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ResourceFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/UrlSet.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/resources/ inherit.gif: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/resources: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/src-html/org/ apache/xbean/finder/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/src-html/org/ apache/xbean/finder/ClassFinder.AnnotationInfo.html: Operation not
Re: Dequeue count in JMS Resource portlet
Anish, Those statistics sounds great, but I do not think we should give the admin wrong statistics (esp if we know it's wrong). However, maybe you could include it for now, but disable them, so that when the bug is fixed you can enable it later. Thanks, Viet On Fri, Apr 18, 2008 at 8:37 AM, anish pathadan [EMAIL PROTECTED] wrote: Hi, I am trying to update the JMS Resource portlet with the queue statistics. I am adding the following information Consumer Count, Enqueue Count ,Dequeue Count and Queue Size. There is a bug in ActiveMQ https://issues.apache.org/activemq/browse/AMQ-1368 due to which each time after browsing messages the dequeue count becomes wrong. I want to know whether I should create the patch with the dequeue count hoping somebody will solve the issue later or not to show the dequeue count at all. -- Best Regards, Anish Pathadan
Dequeue count in JMS Resource portlet
Hi, I am trying to update the JMS Resource portlet with the queue statistics. I am adding the following information Consumer Count, Enqueue Count ,Dequeue Count and Queue Size. There is a bug in ActiveMQ https://issues.apache.org/activemq/browse/AMQ-1368 due to which each time after browsing messages the dequeue count becomes wrong. I want to know whether I should create the patch with the dequeue count hoping somebody will solve the issue later or not to show the dequeue count at all. -- Best Regards, Anish Pathadan
[jira] Created: (GERONIMO-3967) Servlet filters do not get executed on /j_security_check
Servlet filters do not get executed on /j_security_check Key: GERONIMO-3967 URL: https://issues.apache.org/jira/browse/GERONIMO-3967 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1 Environment: Geronimo-Jetty 2.1, Seems to be there in older versions too. Reporter: Boris Georgiev The J2EE Servlet Filters do not get executed, when the request path is /j_security_check. Looks like this type of request is intercepted and executed before anything else. The J2EE specification does not mention that the requests to /j_security_check should be exempt from servlet filter execution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEP 2.1.0 Branch Notification
Hi Donald, I'll make sure everything in the pom is in sycn with the 2.1.1 server. Thanks for pointing out these discrepancies Donald Woods wrote: Can we update the depends to match the same levels used by the 2.1.1 server? Like - xstream-1.2.1 -- 1.2.2 xpp3-1.1.3.3 -- 1.1.3.4.O I'd update these myself, but I know they are also specified in some other non-maven Eclipse specific files... Also, we should replace the javax.activation depend with geronimo-activation_1.1_spec-1.0.2 and add the proper maven excludes. There are several maven plugins which don't have a groupId or version set, which I'll update in the next few minutes. -Donald Tim McConnell wrote: Hi, As soon as the following JIRA is resolved sometime today, I intend to branch (i.e., devtools/eclipse-plugin/branches/2.1.0) in preparation for the release 2.1.0 of the Geronimo Eclipse Plugin. Does anyone have any objections or know of any other reason we shouldn't do so ?? - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 -- Thanks, Tim McConnell
Re: GEP 2.1.0 Branch Notification
I classify GERONIMODEVTOOLS-323 as a must fix/resolve before cutting GEP 2.1.0. On Fri, Apr 18, 2008 at 10:31 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi Donald, I'll make sure everything in the pom is in sycn with the 2.1.1 server. Thanks for pointing out these discrepancies Donald Woods wrote: Can we update the depends to match the same levels used by the 2.1.1 server? Like - xstream-1.2.1 -- 1.2.2 xpp3-1.1.3.3 -- 1.1.3.4.O I'd update these myself, but I know they are also specified in some other non-maven Eclipse specific files... Also, we should replace the javax.activation depend with geronimo-activation_1.1_spec-1.0.2 and add the proper maven excludes. There are several maven plugins which don't have a groupId or version set, which I'll update in the next few minutes. -Donald Tim McConnell wrote: Hi, As soon as the following JIRA is resolved sometime today, I intend to branch (i.e., devtools/eclipse-plugin/branches/2.1.0) in preparation for the release 2.1.0 of the Geronimo Eclipse Plugin. Does anyone have any objections or know of any other reason we shouldn't do so ?? - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 -- Thanks, Tim McConnell
Re: GEP 2.1.0 Branch Notification
Hi Ted, that's fair -- will look at it today. Thanks. Ted Kirby wrote: I classify GERONIMODEVTOOLS-323 as a must fix/resolve before cutting GEP 2.1.0. On Fri, Apr 18, 2008 at 10:31 AM, Tim McConnell [EMAIL PROTECTED] wrote: Hi Donald, I'll make sure everything in the pom is in sycn with the 2.1.1 server. Thanks for pointing out these discrepancies Donald Woods wrote: Can we update the depends to match the same levels used by the 2.1.1 server? Like - xstream-1.2.1 -- 1.2.2 xpp3-1.1.3.3 -- 1.1.3.4.O I'd update these myself, but I know they are also specified in some other non-maven Eclipse specific files... Also, we should replace the javax.activation depend with geronimo-activation_1.1_spec-1.0.2 and add the proper maven excludes. There are several maven plugins which don't have a groupId or version set, which I'll update in the next few minutes. -Donald Tim McConnell wrote: Hi, As soon as the following JIRA is resolved sometime today, I intend to branch (i.e., devtools/eclipse-plugin/branches/2.1.0) in preparation for the release 2.1.0 of the Geronimo Eclipse Plugin. Does anyone have any objections or know of any other reason we shouldn't do so ?? - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 -- Thanks, Tim McConnell -- Thanks, Tim McConnell
Webservices injections failing
Hi there,
i'm having an issue trying to call an EJB from a webservices. I have 3
modules, one EJB, one EAR and one WAR. In the WAR i have the webservices and
a test servlet. The test servlet works fine.
The Webservicesis like:
[...]
@WebService()
public class WSInterface {
@EJB
DonateInterface donateSession;
public Funds getFund(String name) {
System.out.println(Name: + name);
System.out.println(donateSession: + donateSession);
Funds fund = donateSession.getFund(name);
System.out.println(fund);
return fund;
}
[...]
I can successfully call that webservices but it looks like the session bean
is never injected, here is the logs:
Name: sasdfas
donateSession: null
11:11:14,544 ERROR [RPCMessageReceiver] Exception occurred while trying to
invoke service method getFund
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at
org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:98)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
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.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:401)
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:810)
Caused by:
java.lang.NullPointerException
at br.learn.WSInterface.getFund(WSInterface.java:24)
... 29 more
Anyone knows what's wrong? Why i can't get the injections in it?
--
View this message in context:
http://www.nabble.com/Webservices-injections-failing-tp16764007s134p16764007.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Webservices injections failing
Rafael,
You cannot use WTP plugin to create and deploy JAX-WS web services.
WTP plugin is very Axis2 specific and right now is not very JAX-WS
aware. Also, when you develop a web service in WTP and deploy it to
your application server, it actaully deploys the entire Axis2 engine
with it. Since the entire Axis2 engine is deployed with your Axis2 web
service using its own custom deployment descriptors, the application
server has no knowledge of your web service and therefore cannot
perform injection. If the tooling would use standard deployment
descriptors and relied on the web service engine provided by the
application server injection would (and will) work.
You can still do the usual JNDI lookup to get the EJB reference in
this case, but if you need injection working you can't really use WTP.
I think NetBeans has some support for JAX-WS web services but I'm not
100% sure about it.
Hope this helps,
Jarek
On Fri, Apr 18, 2008 at 2:42 PM, Rafael Coutinho
[EMAIL PROTECTED] wrote:
Hi there,
i'm having an issue trying to call an EJB from a webservices. I have 3
modules, one EJB, one EAR and one WAR. In the WAR i have the webservices and
a test servlet. The test servlet works fine.
The Webservicesis like:
[...]
@WebService()
public class WSInterface {
@EJB
DonateInterface donateSession;
public Funds getFund(String name) {
System.out.println(Name: + name);
System.out.println(donateSession: + donateSession);
Funds fund = donateSession.getFund(name);
System.out.println(fund);
return fund;
}
[...]
I can successfully call that webservices but it looks like the session bean
is never injected, here is the logs:
Name: sasdfas
donateSession: null
11:11:14,544 ERROR [RPCMessageReceiver] Exception occurred while trying to
invoke service method getFund
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at
org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
at
org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:98)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:120)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
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.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:401)
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:810)
Caused by:
java.lang.NullPointerException
at br.learn.WSInterface.getFund(WSInterface.java:24)
... 29 more
Anyone knows what's wrong? Why i can't get the injections in it?
--
View this message in context:
[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590587#action_12590587 ] Jay D. McHugh commented on GERONIMO-3931: - It also works in branches/2.1 (2.1.2-Snapshot) which probably means that it works in 2.1.1 I will check branches/2.1.1 just to make sure. Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3931: --- Assignee: Jay D. McHugh Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain Assignee: Jay D. McHugh While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console
[ https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590612#action_12590612 ] Jay D. McHugh commented on GERONIMO-3931: - Also working in branches/2.1.1. If someone can show that this is a problem, please update the JIRA. Otherwise, I'll close it on 4/21 at about 5:00 PM CDT. Unable to delete a datasource from administrative console - Key: GERONIMO-3931 URL: https://issues.apache.org/jira/browse/GERONIMO-3931 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 2.1 Environment: Windows XP, AG2.1 Reporter: Ashish Jain While trying to delete a datasource from Administrative console I get the following error in the command prompt 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! In geronimo.log I get the following error 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful! 13:02:10,359 INFO [SupportedModesServiceImpl] Portlet mode 'edit' not found for portletId: '/system-database.DBWizard!1134683811|0' Steps to recreate the issue 1) Create a DerbyEmbedded database pool. 2) Delete the pool Workaround is to manually remove the entries from config.xml and repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Policy for granting write access to our Wiki
It's already ASF policy that an ICLA be on file for anyone to get write access to a confluence space used for official documentation or a website (plain wiki usage is exempt). Updated a good 40~ cwiki spaces to use the asf-cla group instead of confluence-users, including ours, a couple weeks ago after some abuse so we're compliant with the minimum policy. Some groups, like the Incubator, are talking that you need to be a committer to get write access -- not just have a CLA on file. I'm not sure I see the need for raising the bar that high. I like the idea of the check box as an alternate to having a CLA on file, assuming this is kosher with infra. -David On Apr 16, 2008, at 7:00 AM, Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
If we are going to restrict access to our wiki doc then we should limit grating access to the project members. I'm not in favor of a massive asf-cla group cheers! hernan David Blevins wrote: It's already ASF policy that an ICLA be on file for anyone to get write access to a confluence space used for official documentation or a website (plain wiki usage is exempt). Updated a good 40~ cwiki spaces to use the asf-cla group instead of confluence-users, including ours, a couple weeks ago after some abuse so we're compliant with the minimum policy. Some groups, like the Incubator, are talking that you need to be a committer to get write access -- not just have a CLA on file. I'm not sure I see the need for raising the bar that high. I like the idea of the check box as an alternate to having a CLA on file, assuming this is kosher with infra. -David On Apr 16, 2008, at 7:00 AM, Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: [DISCUSS] GEP 2.1 support for v1.1
Hi Shiva, yes I think the consensus is option #3, and the removal of the v1.1 plug-ins is on my pre-release tasklist. Thanks for the reminder Shiva Kumar H R wrote: So are we finally going in for #3? If yes, we must drop v1.1 plug-ins before we release GEP 2.1.0 as most of them may not be working as expected! On Sat, Mar 29, 2008 at 11:49 AM, Tim McConnell [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, The JAXB refactoring of the GEP 2.1.x code is almost complete for the 2.0.x and 2.1.x versions of the Geronimo servers. Most major functions are now working and we are much better positioned to handle future schema changes in a more timely manner. Traditionally, the GEP has supported 3 to 4 versions of the Geronimo server (primarily to provide a migration/upgrade path), and we had originally planned on supporting v1.1, v2.0.x, v2.1.x. However, since we are almost 2 months behind the release of the v2.1 Geronimo server I would like to discuss some possible alternatives for supporting the v1.1 Geronimo server in this release of the GEP: #1. Proceed with the JAXB refactoring work for the v1.1 code (obviously the most expensive in terms of time and testing required) #2. Leave the v1.1 support in the current EMF implementation (i.e., the JAXB and EMF implementations would co-exist) #3. Remove support altogether for v1.1 in this release of the GEP -- support only the v2.0 and v2.1 Geronimo servers (the least expensive in terms of time and testing required) I'm now of the opinion that we should pursue alternative #3 and remove v1.1 support entirely. My primary rationale is that the the old 2.0 release of the GEP can still be used to provide v1.1 server support, and still provides a migration path from v1.1 to v2.0. It's true that we would lose the v1.1 to v2.1 migration path, but this is mitigated somewhat since the support in the GEP for the v2.0 and v2.1 versions of the server is almost identical. Equally important is that we could then focus entirely on fixing the few remaining JIRAs and augmenting our JUnit testcases, and release the GEP 2.1 quicker (i.e., in the next week or 10 days). Thoughts ?? -- Thanks, Tim McConnell -- Thanks, Shiva -- Thanks, Tim McConnell
Re: Webservices injections failing
I have figured out (thanks to Jarek's help). The problem is that i'm using WTP tooling to create the webservices. WTP creates a Axis2 container inside your application WAR, and you run the webservices inside that container. That container is separated from the WASCE container (even from WASCE Axis2 container) so it can't inject anything in it. The workaround is (as usual) don't use Wizards, do it manually. Here is a reference on how to do it: http://cwiki.apache.org/GMOxDOC21/developing-a-simple-calculator-web-service.html -- View this message in context: http://www.nabble.com/Webservices-injections-failing-tp16764007s134p16765827.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Policy for granting write access to our Wiki
Personal preference I guess. Only 60~ people in that group and everyone in it has full name, address, telephone, etc. on file. Seems very restricted already. We have to review all the edits anyway, even if they come from other committers, so I don't really see an upside unless we start to get a lot of low quality contributions -- which IMHO would be a good problem to have. I definitely think our website should remain restricted to committers. I sort of see that as separate from the rest of our spaces. -David On Apr 18, 2008, at 3:03 PM, Hernan Cunico wrote: If we are going to restrict access to our wiki doc then we should limit grating access to the project members. I'm not in favor of a massive asf-cla group cheers! hernan David Blevins wrote: It's already ASF policy that an ICLA be on file for anyone to get write access to a confluence space used for official documentation or a website (plain wiki usage is exempt). Updated a good 40~ cwiki spaces to use the asf-cla group instead of confluence-users, including ours, a couple weeks ago after some abuse so we're compliant with the minimum policy. Some groups, like the Incubator, are talking that you need to be a committer to get write access -- not just have a CLA on file. I'm not sure I see the need for raising the bar that high. I like the idea of the check box as an alternate to having a CLA on file, assuming this is kosher with infra. -David On Apr 16, 2008, at 7:00 AM, Kevan Miller wrote: All, To properly protect the IP rights of our Wiki-based documentation, we need to stop allowing unrestricted write access to our Wiki. Wiki contributors should be required to have an ICLA on file with the ASF. I also think that we need to hold a PMC vote before granting this access. I'll also take this opportunity to remind the community that Wiki updates are sent to [EMAIL PROTECTED] These updates need to be reviewed by the community, just like all code updates. IMO, we don't want this to be a heavy-weight process. We don't want there to be a significant hurdle to contributing documentation. For code updates, patch files attached to Jira's with the Grant license to ASF button checked takes care of these IP concerns. To my knowledge, there's no patch file equivalent for updates to a Wiki. We could require that documentation updates be contributed in the form of simple ascii text files that are attached to a Jira. This would address our IP concerns, but is not ideal IMO. To keep this as light-weight as possible, I propose we formalize the concept of contributor. A contributor would have write access to our Wiki documentation as well as the ability to assign Jira's to him/herself. I think the process would go something like this... 0. Reset write access to our wiki to be only the current set of committers on the project. 1. New documentation contributions from non-committers/ contributors must be submitted via a Jira, with the Grant License to the ASF box checked. This is just like any code/bug-fix submission. 2. Once a new participant has expressed interest in contributing to the project and/or has contributed documentation or bug fixes, a PMC vote will be called to grant the new participant contributor rights. As all PMC votes, this vote is a majority vote, require a minimum of 3 +1 votes, and will last for a minimum of 72 hours. 3. Once a vote has passed, the participant will be invited to join the project as a 'contributor'. Assuming he/she accepts, the participant must then submit an ICLA to the ASF. Once the ICLA is on file, the new 'contributor' will give given write access to our wiki and the ability to assign Jira's. 4. The new contributor will be announced to the community. I've grouped Jira rights with wiki rights in the above. This is not strictly necessary, but grouping the two seems like a reasonable step. This is my first pass at a proposal. We can tweak this process in a number of ways and there are alternatives. I think the hard requirements are 1) the PMC must vote and 2) an ICLA must be filed with the ASF. Until we resolve this issue, we need to restrict Wiki write access to be the current set of Geronimo committers. --kevan
Re: Cron [EMAIL PROTECTED] /home/jdillon/ws/site/bin/sync
My bad! On Apr 18, 2008, at 5:43 AM, Jason Dillon wrote: Getting a fairly constant spam from the website sync script... --jason Begin forwarded message: From: [EMAIL PROTECTED] (Cron Daemon) Date: April 18, 2008 7:19:18 PM GMT+07:00 To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] /home/jdillon/ws/site/bin/sync chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/ MANIFEST.MF: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/ LICENSE: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF/NOTICE: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/META-INF: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.AnnotationInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.ClassInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.FieldInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.Info.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.InfoBuildingVisitor.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.MethodInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ClassFinder.PackageInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/ResourceFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use/UrlSet.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/class-use: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.AnnotationInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.ClassInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.FieldInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.Info.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.InfoBuildingVisitor.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.MethodInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ClassFinder.PackageInfo.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-frame.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-summary.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-tree.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/package-use.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/ResourceFinder.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder/UrlSet.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/xbean/ finder: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache/ xbean: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org/apache: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/org: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/resources/ inherit.gif: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/resources: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/src-html/org/ apache/xbean/finder/ClassFinder.Annotatable.html: Operation not permitted chmod: /www/geronimo.apache.org/xbean/xbean-finder/src-html/org/
Webservices not co existing with Servlets
Hi, i'm having an issue to have Webservices and simple Servlets in the same WAR project. I basically have a @Webservices annotated bean and in the WAR i use it i can't refer to any servlets anylonger in the web.xml only the mapping of the Webservices bean. If I add a mapping to an actual servlet I get an error saying that there's no bean implementing that mapping: http://rifers.org/paste/show/7145 http://rifers.org/paste/show/7145 Here is the web.xml file, in it I have the Webservices mapping (DonateService) and a servlet mapping (DonateServlet). I've commented out the service-ref tags, but still fails. http://rifers.org/paste/show/7146 http://rifers.org/paste/show/7146 Here is the geronimo.xml (I have also commented out the webesrvices part of it): http://rifers.org/paste/show/7147 http://rifers.org/paste/show/7147 And finally the webservice interface: http://rifers.org/paste/show/7148 http://rifers.org/paste/show/7148 If I remove all actual Servlets mappings and leave only the Webservice servlet mapping it works fine. If I remove the @Webservices annotation from the interface (and the implementation) and re enable the actual servlet mappings it looks like to handle it again as actual servlet mappings. I'm using WASCE 2.0.0.2 Do you have any idea what's going on? i'm doing anything wrong? -- View this message in context: http://www.nabble.com/Webservices-not-co-existing-with-Servlets-tp16766049s134p16766049.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[BUILD] trunk: Failed for Revision: 649734
Geronimo Revision: 649734 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080418/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080418/unit-test-reports Building Geronimo trunk at Revision: 649734 java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode) + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown POM Location: /home/geronimo/geronimo/trunk/pom.xml Reason: Parse error reading POM. Reason: Unrecognised tag: 'plugin' (position: START_TAG seen .../plugins\n\nplugin... @2138:21) for project unknown at /home/geronimo/geronimo/trunk/pom.xml [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: Unrecognised tag: 'plugin' (position: START_TAG seen .../plugins\n\n plugin... @2138:21) for project unknown at /home/geronimo/geronimo/trunk/pom.xml at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.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) Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: Unrecognised tag: 'plugin' (position: START_TAG seen .../plugins\n\nplugin... @2138:21) for project unknown at /home/geronimo/geronimo/trunk/pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1422) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1379) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:477) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:553) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:467) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:364) ... 11 more Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: 'plugin' (position: START_TAG seen .../plugins\n\n plugin... @2138:21) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parsePluginManagement(MavenXpp3Reader.java:3198) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseBuild(MavenXpp3Reader.java:738) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2224) at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1418) ... 17 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Fri Apr 18 21:08:38 EDT 2008 [INFO] Final Memory: 1M/504M [INFO]
Re: Webservices not co existing with Servlets
Actually it's not as simple as i've stated. I've tried to do that scenario and it worked. Then i've tried exactly my scenario.. then it failed. It seems that we need a EJB project in the play too. So i have a WAR project with a servlet and a Webservices. And the servlet uses a session bean using annotations. I've exported the projects and attached here: http://www.nabble.com/file/p16766985/WSxServletsSample.zip WSxServletsSample.zip -- View this message in context: http://www.nabble.com/Webservices-not-co-existing-with-Servlets-tp16766049s134p16766985.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Created: (GERONIMO-3968) context-priority-classloader commented :(
context-priority-classloader commented :( - Key: GERONIMO-3968 URL: https://issues.apache.org/jira/browse/GERONIMO-3968 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment Affects Versions: 2.1, 2.0.2, 2.0.1, 2.0 Reporter: Bruno Braga Priority: Blocker 1) open file http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 2) search for context-priority-classloader 3) results: !--xs:element name=context-priority-classloader type=xs:boolean minOccurs=0/-- COMMENTED? The same applies to: http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 How to use this parameter? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3968) context-priority-classloader commented :(
[ https://issues.apache.org/jira/browse/GERONIMO-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590666#action_12590666 ] Bruno Braga commented on GERONIMO-3968: --- same to: http://geronimo.apache.org/xml/ns/j2ee/web-1.1 http://geronimo.apache.org/xml/ns/j2ee/web-2.0 http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1 context-priority-classloader commented :( - Key: GERONIMO-3968 URL: https://issues.apache.org/jira/browse/GERONIMO-3968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1 Reporter: Bruno Braga Priority: Blocker 1) open file http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 2) search for context-priority-classloader 3) results: !--xs:element name=context-priority-classloader type=xs:boolean minOccurs=0/-- COMMENTED? The same applies to: http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 How to use this parameter? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3968) context-priority-classloader commented :(
[ https://issues.apache.org/jira/browse/GERONIMO-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590667#action_12590667 ] Bruno Braga commented on GERONIMO-3968: --- It's cause xml problem for web app . Caused by: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors: error: cvc-complex-type.2.4a: Expected elements '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/naming-1.2 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.2 [EMAIL PROTECTED]://java.sun.com/xml/ns/persistence' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1' here context-priority-classloader commented :( - Key: GERONIMO-3968 URL: https://issues.apache.org/jira/browse/GERONIMO-3968 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1 Reporter: Bruno Braga Priority: Blocker 1) open file http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 2) search for context-priority-classloader 3) results: !--xs:element name=context-priority-classloader type=xs:boolean minOccurs=0/-- COMMENTED? The same applies to: http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.1 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0 http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-2.0.1 How to use this parameter? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
