Re: yoko deps in repository module
So... should these be removed from the repository/pom.xml? --jason On Apr 22, 2008, at 4:04 AM, Rick McGuire wrote: Jason Dillon wrote: Why are there yoko deps listed in the repository module, but there are no artifacts for org/apache/yoko checked in there? Looks like it was just a missed update when trunk was switched back to pick up the snapshot dependency. We've been shipping with a new pinned yoko version in the repository when we've been spinning a new G. release Rick 8 dependency groupIdorg.apache.yoko/groupId artifactIdyoko-core/artifactId /dependency dependency groupIdorg.apache.yoko/groupId artifactIdyoko-rmi-impl/artifactId /dependency dependency groupIdorg.apache.yoko/groupId artifactIdyoko-rmi-spec/artifactId /dependency dependency groupIdorg.apache.yoko/groupId artifactIdyoko-spec-corba/artifactId /dependency 8 This causes the repository module build to pull them from a remote repository... which isn't really the purpose of this module at at... its only to install those artifacts which are under repository/* into the local repo cache. Anyone know whats up with this? --jason
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
Great work david!!! I think some of these people are axis committers ... the ones with opensource.lk email addresses. If they are, do we need another CLA? Or did you already look and my idea that they are committers on another project is wrong? thanks david jencks On Apr 21, 2008, at 10:00 PM, David Blevins wrote: On Apr 21, 2008, at 8:47 PM, Jason Warner wrote: This may be a dumb question, but what happens if a user submitted content and then submitted a CLA sometime later on. Are CLA's retroactive or does the content submitted before a CLA need to be resubmitted? Definitely not a dumb question. In the concrete case of someone making contributions to project A then filing a CLA and later becoming a committer to project A, I'd think the CLA would cover all contributions. Similarly, if someone made some contributions and we asked them to file a CLA and they did, I'd count that as good enough. Likely some other scenarios which are less clear, but those two cover the common cases. And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. -David
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
On Apr 22, 2008, at 12:24 AM, David Jencks wrote: Great work david!!! I think some of these people are axis committers ... the ones with opensource.lk email addresses. If they are, do we need another CLA? Or did you already look and my idea that they are committers on another project is wrong? I did a manual look for CLA by last name for everyone who made any edits. They might be there under a different name/spelling and possibly I missed them. -David On Apr 21, 2008, at 10:00 PM, David Blevins wrote: On Apr 21, 2008, at 8:47 PM, Jason Warner wrote: This may be a dumb question, but what happens if a user submitted content and then submitted a CLA sometime later on. Are CLA's retroactive or does the content submitted before a CLA need to be resubmitted? Definitely not a dumb question. In the concrete case of someone making contributions to project A then filing a CLA and later becoming a committer to project A, I'd think the CLA would cover all contributions. Similarly, if someone made some contributions and we asked them to file a CLA and they did, I'd count that as good enough. Likely some other scenarios which are less clear, but those two cover the common cases. And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. -David
[jira] Created: (GERONIMO-3982) WADI cluster fails to distribute the installed application to all the nodes in the same cluster
WADI cluster fails to distribute the installed application to all the nodes in
the same cluster
---
Key: GERONIMO-3982
URL: https://issues.apache.org/jira/browse/GERONIMO-3982
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.x
Environment: Windows, IBM JDK
Reporter: YunFeng Ma
Fix For: 2.1.1, 2.1.x
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster, I
can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine in
Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
David Blevins wrote: And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. Egads, I'm on the list! I see the forms for Contributor License Agreements at http://www.apache.org/licenses/. However, from reading the FAQ I do not see where to submit or record the form. Can someone point me to the process? -- Thanks, Dan Becker
[jira] Created: (GERONIMO-3983) Update JMS Resource portlet to show the Destination statistics
Update JMS Resource portlet to show the Destination statistics -- Key: GERONIMO-3983 URL: https://issues.apache.org/jira/browse/GERONIMO-3983 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Reporter: Anish Pathadan Update the JMS Resource portlet to show the destination statistics such as Consumer Count,Queue Size,Enqueue Count and Dequeue Count for each Queues/Topics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3983) Update JMS Resource portlet to show the Destination statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3983: - Attachment: screenshot-1.jpg Update JMS Resource portlet with Consumer Count and Queue Size. Update JMS Resource portlet to show the Destination statistics -- Key: GERONIMO-3983 URL: https://issues.apache.org/jira/browse/GERONIMO-3983 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: Anish Pathadan Attachments: screenshot-1.jpg Update the JMS Resource portlet to show the destination statistics such as Consumer Count,Queue Size,Enqueue Count and Dequeue Count for each Queues/Topics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3983) Update JMS Resource portlet to show the Destination statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anish Pathadan updated GERONIMO-3983: - Attachment: JMS Resource Portlet_Statistics.patch Attached is the patch for updating JMS Resource portlet to include Destination statistics Consumer Count and Queue Size. Update JMS Resource portlet to show the Destination statistics -- Key: GERONIMO-3983 URL: https://issues.apache.org/jira/browse/GERONIMO-3983 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: Anish Pathadan Attachments: JMS Resource Portlet_Statistics.patch, screenshot-1.jpg Update the JMS Resource portlet to show the destination statistics such as Consumer Count,Queue Size,Enqueue Count and Dequeue Count for each Queues/Topics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3983) Update JMS Resource portlet to show the Destination statistics
[ https://issues.apache.org/jira/browse/GERONIMO-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591292#action_12591292 ] Anish Pathadan commented on GERONIMO-3983: -- Currently I have disabled showing enqueue/dequeue count for ActiveMQ queues and Topics due to the following defect in ActiveMQ https://issues.apache.org/activemq/browse/AMQ-1368 Once that defect is fixed, the list.jsp in activemq-portlet can be edited to include these fields also. Update JMS Resource portlet to show the Destination statistics -- Key: GERONIMO-3983 URL: https://issues.apache.org/jira/browse/GERONIMO-3983 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Reporter: Anish Pathadan Attachments: JMS Resource Portlet_Statistics.patch, screenshot-1.jpg Update the JMS Resource portlet to show the destination statistics such as Consumer Count,Queue Size,Enqueue Count and Dequeue Count for each Queues/Topics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3982) WADI cluster fails to distribute the installed application to all the nodes in the same cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bohn updated GERONIMO-3982:
---
Description:
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster, I
can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine in
Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
was:
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster, I
can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine in
Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
Fix Version/s: (was: 2.1.1)
2.2
Please do not mark 2.1.1 as a fix version for new JIRAs. 2.1.1 is frozen and
we are generating a image for a vote and release.
WADI cluster fails to distribute the installed application to all the nodes
in the same cluster
---
Key: GERONIMO-3982
URL: https://issues.apache.org/jira/browse/GERONIMO-3982
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.x
Environment: Windows, IBM JDK
Reporter: YunFeng Ma
Fix For: 2.1.x, 2.2
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster,
I can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine
in Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-repository
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
On Apr 22, 2008, at 9:06 AM, Dan Becker wrote: David Blevins wrote: And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. Egads, I'm on the list! I see the forms for Contributor License Agreements at http://www.apache.org/licenses/ . However, from reading the FAQ I do not see where to submit or record the form. Can someone point me to the process? That info is in the ICLA, itself: If you have not already done so, please complete and send an original signed Agreement to The Apache Software Foundation, 1901 Munsey Drive, Forest Hill, MD 21050-2747, U.S.A. If necessary, you may send it by facsimile to the Foundation at +1-919-573-9199. --kevan
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
You can also send a scanned copy to secretary at apache dot org as noted on the licenses page Dan mentioned earlier, if that's any easier for anyone. On Tue, Apr 22, 2008 at 9:31 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Apr 22, 2008, at 9:06 AM, Dan Becker wrote: David Blevins wrote: And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.loghttp://people.apache.org/%7Edblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. Egads, I'm on the list! I see the forms for Contributor License Agreements at http://www.apache.org/licenses/. However, from reading the FAQ I do not see where to submit or record the form. Can someone point me to the process? That info is in the ICLA, itself: If you have not already done so, please complete and send an original signed Agreement to The Apache Software Foundation, 1901 Munsey Drive, Forest Hill, MD 21050-2747, U.S.A. If necessary, you may send it by facsimile to the Foundation at +1-919-573-9199. --kevan -- ~Jason Warner
Re: Doc IP Clearance (was Re: [DISCUSS] Policy for granting write access to our Wiki)
On Apr 22, 2008, at 3:24 AM, David Jencks wrote: Great work david!!! I think some of these people are axis committers ... the ones with opensource.lk email addresses. If they are, do we need another CLA? Or did you already look and my idea that they are committers on another project is wrong? A CLA is ASF-wide, not project specific. So, it would definitely cover the changes... On Apr 21, 2008, at 10:00 PM, David Blevins wrote: On Apr 21, 2008, at 8:47 PM, Jason Warner wrote: This may be a dumb question, but what happens if a user submitted content and then submitted a CLA sometime later on. Are CLA's retroactive or does the content submitted before a CLA need to be resubmitted? Definitely not a dumb question. In the concrete case of someone making contributions to project A then filing a CLA and later becoming a committer to project A, I'd think the CLA would cover all contributions. Similarly, if someone made some contributions and we asked them to file a CLA and they did, I'd count that as good enough. Likely some other scenarios which are less clear, but those two cover the common cases. And speaking of CLAs, here's a report of users, and their edits, for whom I could not find a CLA: http://people.apache.org/~dblevins/gmo-revisions-no-cla.log I think the easiest thing is to just ask for CLAs from everyone on this list (definitely some familiar faces in that list). Afterwards we can deal with what's left which will be a process of evaluating the contributions and making a judgment call on if they fall under either the minor patch or the major contribution category. Getting CLA on file certainly seems to help reduce any concerns. Not sure if a CLA applies retroactively to prior submissions. --kevan
[jira] Commented: (GERONIMO-3982) WADI cluster fails to distribute the installed application to all the nodes in the same cluster
[
https://issues.apache.org/jira/browse/GERONIMO-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591304#action_12591304
]
Gianny Damour commented on GERONIMO-3982:
-
Hello,
WADI is not involved at all in farming, i.e. deployment of modules to multiple
Geronimo instances. You need to follow the instructions provided by this WIKI
page http://cwiki.apache.org/confluence/display/GMOxDOC21/Farming.
The idea is to add a new GBean to the farming configuration for your second
node.
Thanks,
Giany
WADI cluster fails to distribute the installed application to all the nodes
in the same cluster
---
Key: GERONIMO-3982
URL: https://issues.apache.org/jira/browse/GERONIMO-3982
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1.1, 2.1.x
Environment: Windows, IBM JDK
Reporter: YunFeng Ma
Fix For: 2.1.x, 2.2
1. Start two Geronimo servers (Node1 and Node2) which are in a WADI cluster,
I can see the following message in the geronmo launch console:
{noformat}
2008-4-22 14:16:49 org.codehaus.wadi.tribes.WadiMemberInterceptor memberAdded
信息: memberAdded:tcp://ZS01:4000
{noformat}
2. Deploy an application to Node1, verify the application and it works fine
in Node1
3. I can see the deployed application in Node1_Home\cluster-repository and
Node1_Home\master-repository, but there is no the application in
Node2_Home\cluster-repository and Node2_Home\master-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-3972) Monitering Graphics failed to represent in IE 6 SP2
[ https://issues.apache.org/jira/browse/GERONIMO-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik B. Craig reassigned GERONIMO-3972: --- Assignee: Erik B. Craig Monitering Graphics failed to represent in IE 6 SP2 --- Key: GERONIMO-3972 URL: https://issues.apache.org/jira/browse/GERONIMO-3972 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: monitoring Affects Versions: 2.1.1, 2.2 Environment: Windows Reporter: YunFeng Ma Assignee: Erik B. Craig Fix For: 2.1.x, 2.2 There is a JavaScript error in IE 6 SP2: Error: 'text' is null or not an object -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3966) Spaces in server installation directory causes deployment problems when using JMX to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-3966: Fix Version/s: (was: 2.2) 2.1 Spaces in server installation directory causes deployment problems when using JMX to deploy --- Key: GERONIMO-3966 URL: https://issues.apache.org/jira/browse/GERONIMO-3966 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0.1, 2.0.2, 2.1 Environment: Platform independenct -- not Windows-specific as originally thought Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1 MalformedURLExceptions will result whenever JMX is used to deploy to a Geronimo server installed in a path with spaces (e.g., C:\Program File\Geronimo). The problem appears to be due to Sun's RMI codebase implementation, which uses a space as a delimiter between filenames in the codebase. An example failure is shown below: Distribution of configuration failed. See log for details. Error unmarshaling return; nested exception is: java.net.MalformedURLException: no protocol: Files/IBM/WebSphere/AppServerCommunityEdition/repository/org/apache/geronimo/modules/geronimo-common/2.0.1/geronimo-common-2.0.1.jar This is a Geronimo jira to correspond to the GERONIMODEVTOOLS-254. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: branches/2.1.1 in prep for a 2.1.1 release
Hi Joe, the fix has been applied to branches\2.1 and the build works with it. How a TCK run is scheduled/invoked is unclear to me though. Please advise if there is something I need to do for that to occur. Thanks much. Joe Bohn wrote: So here is what I understand: - This is exclusively a G server problem and will not impact the GEP 2.1 release. However, GEP 2.1 could reference Geronimo 2.1.1 if it is released in time and hence could potentially benefit from this fix if included in Geronimo 2.1.1 - This is a long time problem that was never identified as a show stopper for Geronimo (2.1.1 or otherwise). Of course, having a fix certainly changes the urgency to get it in :-) - This change is currently integrated into trunk and not branches/2.1 or branches/2.1.1 - The fix is in a kernel module and as such could potentially affect various areas in Geronimo (hence the caution of validation via full TCK runs). Is this worth further delaying the 2.1.1 release to include this fix? I was ready to create the release candidate now but this would delay us several more days before we could even get anything out for a vote. (BTW, I have already updated the version numbers in branches/2.1.1 to remove SNAPSHOT in prep for the release). If we were to pursue this fix we should do the following: 1) Put the change in branches/2.1 first. (it really needs to go there anyway and it makes much more sense to merge from branches/2.1 to branches/2.1.1 than from trunk to branches/2.1.1) - We should do this now regardless of the plans for 2.1.1 2) Validate TCK on branches/2.1 (2.1.2-SNAPSHOT) 3) IIF things look good in 2.1.2-SNAPSHOT we would move the fix to 2.1.1 Joe Tim McConnell wrote: Hi Kevan/Joe, yes GERONIMO-3966 has been classified as a show-stopper for GEP 2.1, but I think we were assuming the problem was in the GEP and not the server itself. However, it's apparently been a long-term problem in the server, and is not a windows-only problem, so I'm not certain that it should be considered a show-stopper for the GEP. Finally, I really wouldn't feel comfortable propagating it elsewhere until we have clean TCK run against it since it involves a change in the geronimo-kernel module. Thanks. Kevan Miller wrote: On Apr 21, 2008, at 9:09 AM, Joe Bohn wrote: Shiva, The same answer applies here that I just sent to Gianny. I've included it here as well just so that you don't have to go hunting branches/2.1.1 is closed to new changes beyond those which would prevent us from shipping. I had intended to have images up for vote a few days ago, but I'm having some difficulty creating those images. They will hopefully be out for a vote later today. You should include these changes in branches/2.1 (which has been updated for 2.1.2-SNAPSHOT). Sorry to be hard nosed about cutting the release ... but we have to cut sometime and are always more more items coming in to include. Hopefully we can get better at releasing smaller releases with more frequency and 2.1.2 won't be long off. Joe, I totally understand the sentiment. However, I believe that GERONIMO-3966 has been classified as a must fix problem for the pending release of GEP 2.1. I'd like to hear from Tim/Shiva/etc whether or not that's true... If true, I think we need to consider including... If we do pick it up, we should probably grab Gianny's change... --kevan -- Thanks, Tim McConnell
[jira] Updated: (GERONIMO-3966) Spaces in server installation directory causes deployment problems when using JMX to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-3966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller updated GERONIMO-3966: --- Fix Version/s: (was: 2.1) 2.2 2.1.2 I added 2.1.2 release to Jira. Note that fix version cannot be an already released version (unless the fix was already in the release...). Spaces in server installation directory causes deployment problems when using JMX to deploy --- Key: GERONIMO-3966 URL: https://issues.apache.org/jira/browse/GERONIMO-3966 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0.1, 2.0.2, 2.1 Environment: Platform independenct -- not Windows-specific as originally thought Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2, 2.2 MalformedURLExceptions will result whenever JMX is used to deploy to a Geronimo server installed in a path with spaces (e.g., C:\Program File\Geronimo). The problem appears to be due to Sun's RMI codebase implementation, which uses a space as a delimiter between filenames in the codebase. An example failure is shown below: Distribution of configuration failed. See log for details. Error unmarshaling return; nested exception is: java.net.MalformedURLException: no protocol: Files/IBM/WebSphere/AppServerCommunityEdition/repository/org/apache/geronimo/modules/geronimo-common/2.0.1/geronimo-common-2.0.1.jar This is a Geronimo jira to correspond to the GERONIMODEVTOOLS-254. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-331) Geronimo classpath container not included by default
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-331: Assignee: Shiva Kumar H R (was: Tim McConnell) Geronimo classpath container not included by default Key: GERONIMODEVTOOLS-331 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Priority: Critical Fix For: 2.1.0 When I create a simple Dynamic Web Project and try adding a servlet inside it, I hit compilation errors for all J2EE APIs like: HttpServletRequest cannot be resolved to a type HelloWorld/src/test TestServlet.java javax.servlet cannot be resolved to a typeHelloWorld/src/test TestServlet.java ServletException cannot be resolved to a type HelloWorld/src/test TestServlet.java In Project Explorer view, when I expand web-app-project - Java Resources: src - Libraries, I see that there is no library listed for Apache Geronimo! And I will have to manually add it as below to resolve above compilation errors: Right click on web-project - Properties - Java Build Path - Libraries - Add Library - Server Runtime - Next - Apache Geronimo v2.1 - Finish - OK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-331) Geronimo classpath container not included by default
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591339#action_12591339 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-331: -- Looks like this is a regression out of http://svn.apache.org/viewvc?view=revrevision=643980 . Upon reverting back that commit, above problem is getting fixed! Geronimo classpath container not included by default Key: GERONIMODEVTOOLS-331 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Priority: Critical Fix For: 2.1.0 When I create a simple Dynamic Web Project and try adding a servlet inside it, I hit compilation errors for all J2EE APIs like: HttpServletRequest cannot be resolved to a type HelloWorld/src/test TestServlet.java javax.servlet cannot be resolved to a typeHelloWorld/src/test TestServlet.java ServletException cannot be resolved to a type HelloWorld/src/test TestServlet.java In Project Explorer view, when I expand web-app-project - Java Resources: src - Libraries, I see that there is no library listed for Apache Geronimo! And I will have to manually add it as below to resolve above compilation errors: Right click on web-project - Properties - Java Build Path - Libraries - Add Library - Server Runtime - Next - Apache Geronimo v2.1 - Finish - OK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: branches/2.1.1 in prep for a 2.1.1 release
Thanks Tim, We have some scheduled tck runs that include a small subset of the tests which would highlight any major/pervasive issues. Since we haven't noticed any issues on trunk I doubt we would hit any in branches/2.1 either. For a full run I or somebody else would have to manually kick it off. I can do that but I might have to wait a few days until I can get a machine free to try this out. Regarding the change it general and 2.1.1 ... It looks like we are ok to leave this wait until 2.1.2 based upon your input and Kevan's comments. So at this point I do not anticipate including this in 2.1.1 (which I hope I will have available for vote later today ... yes, I know I said that yesterday too :-( ). Joe Tim McConnell wrote: Hi Joe, the fix has been applied to branches\2.1 and the build works with it. How a TCK run is scheduled/invoked is unclear to me though. Please advise if there is something I need to do for that to occur. Thanks much. Joe Bohn wrote: So here is what I understand: - This is exclusively a G server problem and will not impact the GEP 2.1 release. However, GEP 2.1 could reference Geronimo 2.1.1 if it is released in time and hence could potentially benefit from this fix if included in Geronimo 2.1.1 - This is a long time problem that was never identified as a show stopper for Geronimo (2.1.1 or otherwise). Of course, having a fix certainly changes the urgency to get it in :-) - This change is currently integrated into trunk and not branches/2.1 or branches/2.1.1 - The fix is in a kernel module and as such could potentially affect various areas in Geronimo (hence the caution of validation via full TCK runs). Is this worth further delaying the 2.1.1 release to include this fix? I was ready to create the release candidate now but this would delay us several more days before we could even get anything out for a vote. (BTW, I have already updated the version numbers in branches/2.1.1 to remove SNAPSHOT in prep for the release). If we were to pursue this fix we should do the following: 1) Put the change in branches/2.1 first. (it really needs to go there anyway and it makes much more sense to merge from branches/2.1 to branches/2.1.1 than from trunk to branches/2.1.1) - We should do this now regardless of the plans for 2.1.1 2) Validate TCK on branches/2.1 (2.1.2-SNAPSHOT) 3) IIF things look good in 2.1.2-SNAPSHOT we would move the fix to 2.1.1 Joe Tim McConnell wrote: Hi Kevan/Joe, yes GERONIMO-3966 has been classified as a show-stopper for GEP 2.1, but I think we were assuming the problem was in the GEP and not the server itself. However, it's apparently been a long-term problem in the server, and is not a windows-only problem, so I'm not certain that it should be considered a show-stopper for the GEP. Finally, I really wouldn't feel comfortable propagating it elsewhere until we have clean TCK run against it since it involves a change in the geronimo-kernel module. Thanks. Kevan Miller wrote: On Apr 21, 2008, at 9:09 AM, Joe Bohn wrote: Shiva, The same answer applies here that I just sent to Gianny. I've included it here as well just so that you don't have to go hunting branches/2.1.1 is closed to new changes beyond those which would prevent us from shipping. I had intended to have images up for vote a few days ago, but I'm having some difficulty creating those images. They will hopefully be out for a vote later today. You should include these changes in branches/2.1 (which has been updated for 2.1.2-SNAPSHOT). Sorry to be hard nosed about cutting the release ... but we have to cut sometime and are always more more items coming in to include. Hopefully we can get better at releasing smaller releases with more frequency and 2.1.2 won't be long off. Joe, I totally understand the sentiment. However, I believe that GERONIMO-3966 has been classified as a must fix problem for the pending release of GEP 2.1. I'd like to hear from Tim/Shiva/etc whether or not that's true... If true, I think we need to consider including... If we do pick it up, we should probably grab Gianny's change... --kevan
[jira] Commented: (GERONIMODEVTOOLS-331) Geronimo classpath container not included by default
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591352#action_12591352 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-331: -- Please see below discussion on wtp-dev: http://dev.eclipse.org/mhonarc/lists/wtp-dev/msg04141.html an excerpt from above link When you defined your JBI runtime, you probably copied something like this into your plugin.xml file: extension point=org.eclipse.wst.common.project.facet.core.runtimes ... adapter runtime-component id=org.eclipse.jst.server.tomcat/ factory class=org.eclipse.jst.server.core.internal.RuntimeClasspathProvider$Factory/ type class=org.eclipse.jst.common.project.facet.core.IClasspathProvider/ /adapter ... /extension This sets up the classpath provider associated with the runtime component type (tomcat in this case). If you look in the RuntimeClasspathProvider class you will see that it only knows about the module facets that ship with WTP. You will need to either subclass or replace the classpath provider for the JBI runtime in order to get ClasspathHelper.addClasspathEntries setup classpath for the JBI facet. Geronimo classpath container not included by default Key: GERONIMODEVTOOLS-331 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Priority: Critical Fix For: 2.1.0 When I create a simple Dynamic Web Project and try adding a servlet inside it, I hit compilation errors for all J2EE APIs like: HttpServletRequest cannot be resolved to a type HelloWorld/src/test TestServlet.java javax.servlet cannot be resolved to a typeHelloWorld/src/test TestServlet.java ServletException cannot be resolved to a type HelloWorld/src/test TestServlet.java In Project Explorer view, when I expand web-app-project - Java Resources: src - Libraries, I see that there is no library listed for Apache Geronimo! And I will have to manually add it as below to resolve above compilation errors: Right click on web-project - Properties - Java Build Path - Libraries - Add Library - Server Runtime - Next - Apache Geronimo v2.1 - Finish - OK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-331) Geronimo classpath container not included by default
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R closed GERONIMODEVTOOLS-331. Resolution: Fixed Regression: [Regression] So, the adapter element that was commented out in Revision 643980 is very much required and is restored back. Completed: At revision: 650572 Geronimo classpath container not included by default Key: GERONIMODEVTOOLS-331 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-331 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Priority: Critical Fix For: 2.1.0 When I create a simple Dynamic Web Project and try adding a servlet inside it, I hit compilation errors for all J2EE APIs like: HttpServletRequest cannot be resolved to a type HelloWorld/src/test TestServlet.java javax.servlet cannot be resolved to a typeHelloWorld/src/test TestServlet.java ServletException cannot be resolved to a type HelloWorld/src/test TestServlet.java In Project Explorer view, when I expand web-app-project - Java Resources: src - Libraries, I see that there is no library listed for Apache Geronimo! And I will have to manually add it as below to resolve above compilation errors: Right click on web-project - Properties - Java Build Path - Libraries - Add Library - Server Runtime - Next - Apache Geronimo v2.1 - Finish - OK. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-334) Download and Install fails, and hoses eclipse for plugin development
Download and Install fails, and hoses eclipse for plugin development -- Key: GERONIMODEVTOOLS-334 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-334 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: windows Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.0 Following instructions for http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html, I launched the plugin, defined a server, and used the download and install button to download the server. In the launching eclipse, I got these messages: org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- Featureorg.apache.geronimo.installableruntime.tomcat.feature 2.1.0has successfully been installed org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.468 -- Server UI plugin stop -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.468 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.515 Removing runtime lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.640 -- Server Core plugin shutdown -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.640 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager Unhandled event loop exception during blocked modal context. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:934) at org.eclipse.wst.server.ui.internal.wizard.TaskWizardPage.run(TaskWizardPage.java:108) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1.widgetSelected(GeronimoRuntimeWizardFragment.java:209) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.wst.server.ui.internal.actions.LaunchWizardAction.run(LaunchWizardAction.java:57) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:546) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
[jira] Updated: (GERONIMODEVTOOLS-334) Download and Install fails, and hoses eclipse for plugin development
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-334: --- Attachment: download21problem.txt I am attaching my complete log file, from which I extracted the errors above. One of my machines is completely unrecoverable from the dreaded unable to save configuration file problem, ever after all of these steps: 1. erase contents of workspace directory 2. reboot machine 3. perform all of the steps in http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html Download and Install fails, and hoses eclipse for plugin development -- Key: GERONIMODEVTOOLS-334 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-334 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: windows Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.0 Attachments: download21problem.txt Following instructions for http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html, I launched the plugin, defined a server, and used the download and install button to download the server. In the launching eclipse, I got these messages: org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- Featureorg.apache.geronimo.installableruntime.tomcat.feature 2.1.0has successfully been installed org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.468 -- Server UI plugin stop -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.468 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.515 Removing runtime lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.640 -- Server Core plugin shutdown -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.640 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager Unhandled event loop exception during blocked modal context. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:934) at org.eclipse.wst.server.ui.internal.wizard.TaskWizardPage.run(TaskWizardPage.java:108) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1.widgetSelected(GeronimoRuntimeWizardFragment.java:209) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.wst.server.ui.internal.actions.LaunchWizardAction.run(LaunchWizardAction.java:57) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at
[jira] Commented: (GERONIMODEVTOOLS-334) Download and Install fails, and hoses eclipse for plugin development
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591412#action_12591412 ] Ted Kirby commented on GERONIMODEVTOOLS-334: After a reboot, I even removed my .m2 repo, and did an mvn clean install, and redid the steps, and that did not fix the problem either. :-( Download and Install fails, and hoses eclipse for plugin development -- Key: GERONIMODEVTOOLS-334 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-334 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Environment: windows Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.0 Attachments: download21problem.txt Following instructions for http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html, I launched the plugin, defined a server, and used the download and install button to download the server. In the launching eclipse, I got these messages: org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Loading .installableRuntimes extension point -- org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.20 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.tomcat.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 Loaded installableRuntime: org.apache.geronimo.runtime.jetty.21 org.eclipse.wst.server.core EXTENSION 22/04/08 12:13.18.531 -- Done loading .installableRuntimes extension point -- Featureorg.apache.geronimo.installableruntime.tomcat.feature 2.1.0has successfully been installed org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.468 -- Server UI plugin stop -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.468 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.515 Removing runtime lifecycle listener [EMAIL PROTECTED] from Server resource manager org.eclipse.wst.server.core CONFIG22/04/08 12:18.09.640 -- Server Core plugin shutdown -- org.eclipse.wst.server.core LISTENERS 22/04/08 12:18.09.640 Removing server lifecycle listener [EMAIL PROTECTED] from Server resource manager Unhandled event loop exception during blocked modal context. org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.NullPointerException) at org.eclipse.swt.SWT.error(SWT.java:3563) at org.eclipse.swt.SWT.error(SWT.java:3481) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:158) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:326) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:934) at org.eclipse.wst.server.ui.internal.wizard.TaskWizardPage.run(TaskWizardPage.java:108) at org.apache.geronimo.st.ui.internal.GeronimoRuntimeWizardFragment$1.widgetSelected(GeronimoRuntimeWizardFragment.java:209) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:227) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3682) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3293) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.wst.server.ui.internal.actions.LaunchWizardAction.run(LaunchWizardAction.java:57) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:546) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490) at
Oracle 10g RAC / Geronimo 2.0
Hi, I need to access an Oracle Rac (cluster) from Geronimo. For that, I need to setup a datasource with a few additional properties to specify the hosts part of the cluster. However, I also need to setup an Oracle specific connection pool that manages the fail overs (the swithc between the rac servers). In the web console, the connection pools are limited to using the standard connection pool. Is there another way to specify the connection pool class and its properties? Thanks Xav -- View this message in context: http://www.nabble.com/Oracle-10g-RAC---Geronimo-2.0-tp16827659s134p16827659.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Resolved: (GERONIMODEVTOOLS-333) Error when deploying the Geronimo calculator-stateless-pojo sample
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-333. Resolution: Fixed The org.apache.geronimo.jee.openejb package is now based on the http://openejb.apache.org/xml/ns/openejb-jar-2.2 namespace (instead of the http://geronimo.apache.org/xml/ns/j2ee/ejb/openejb-2.0). As it is now there is no factory method for creating a geronimo-openejb.xml file, thus only openejb-jar.xml files can be created from the GEP). Error when deploying the Geronimo calculator-stateless-pojo sample -- Key: GERONIMODEVTOOLS-333 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-333 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 Distribution of module failed. See log for details. Failed parsing descriptors for module: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deploymentUtil39788.jar org.apache.geronimo.common.DeploymentException: Failed parsing descriptors for module: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deploymentUtil39788.jar at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:299) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule(EjbModuleBuilder.java:228) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:786) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:295) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:226) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) 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.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:849) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) at sun.reflect.GeneratedMethodAccessor160.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:849) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1245) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1348) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:782) at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at
