[jira] Created: (GERONIMODEVTOOLS-331) Geronimo classpath container not included by default
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: Tim McConnell 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 type HelloWorld/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] Assigned: (GERONIMODEVTOOLS-254) Spaces in server pathname causes problems for the Eclipse Plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-254: Assignee: Tim McConnell (was: Shiva Kumar H R) Spaces in server pathname causes problems for the Eclipse Plugin Key: GERONIMODEVTOOLS-254 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0 Environment: Windows Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 When there are spaces in the Geronimo server pathname (on Windows), the Eclipse Plugin will have problems deploying and EAR File. For example the following error will occur: 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 message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-254) Spaces in server pathname causes problems for the Eclipse Plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589838#action_12589838 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-254: -- For reference: I tried this with both Sun JDK IBM JDK and problem occurs with both of them. Spaces in server pathname causes problems for the Eclipse Plugin Key: GERONIMODEVTOOLS-254 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0 Environment: Windows Reporter: Tim McConnell Assignee: Shiva Kumar H R Fix For: 2.1.0 When there are spaces in the Geronimo server pathname (on Windows), the Eclipse Plugin will have problems deploying and EAR File. For example the following error will occur: 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 message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-272) Description of core feature confusing
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shiva Kumar H R reassigned GERONIMODEVTOOLS-272:
Assignee: Tim McConnell (was: Shiva Kumar H R)
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Tim McConnell
Fix For: 2.1.0
Attachments: GD-272.patch
When you install the eclipse plugin with the eclipse update manager, you get
a choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development
tools for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development
tools for {color:red}this specific version of the{color} Apache Geronimo
server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the
user finds out about them, but they can probably be removed from the core
feature, if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-256) Publish operation after an Eclipse restart deletes a deployed Web Service's server-config.wsdd file
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589841#action_12589841
]
Shiva Kumar H R commented on GERONIMODEVTOOLS-256:
--
https://bugs.eclipse.org/bugs/show_bug.cgi?id=119964 say this is fixed in WTP
3.0M6. However when I tried with WTP 3.0M6 used Web Services Wizard, I keep
hitting the following error:
IWAB0489E Error when deploying Web service to Axis runtime
axis-admin failed with {http://xml.apache.org/axis/}HTTP
(404)/HelloWS/services/AdminService
This seems to be some other issue in WTP (see same error reported in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=201061 ) and need to report it /
follow-up in WTP bugzilla.
Publish operation after an Eclipse restart deletes a deployed Web Service's
server-config.wsdd file
-
Key: GERONIMODEVTOOLS-256
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0.0
Environment: AG 2.0.2 + Geronimo Eclipse Plug-in v2.0 + WTP 2.0.1
Reporter: Shiva Kumar H R
Assignee: Shiva Kumar H R
Fix For: 2.1.0
Steps to recreate:
1) Create a Web Service as per the instructions at
http://www.eclipse.org/webtools/jst/components/ws/1.5/tutorials/BottomUpWebService/BottomUpWebService.html
2) Test the web service using (the auto launched) Web Service Explorer.
Everything works fine.
3) Shut down server and restart the server. Again launch the web service. It
runs fine without any error.
4) Shut down server, close eclipse, restart eclipse, start server. This time
try to access the web service and you will not be able to access it.
An initial analysis shows that in Step-4 (after a Eclipse Server restart)
the Publish operation of Eclipse is deleting server-config.wsdd from
GERONIMO_HOME\repository\path-to-deployed-EAR\war name\WEB-INF
directory.
You will get the following error in the console:
17:01:56,218 ERROR [EngineConfigurationFactoryServlet] Unable to find config
file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd
Is this related to the issue reported in
http://mail-archive.ow2.org/jonas-team/2006-08/msg00046.html ? Needs to be
explored.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-256) Publish operation after an Eclipse restart deletes a deployed Web Service's server-config.wsdd file
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-256: - Fix Version/s: (was: 2.1.0) 2.1.x As said before, this will only be available in WTP 3.0. As a workaround until then, with GEP 2.1.0 WTP 2.0.1, we will have to request users to manually do these: Use Web Services Wizard to create deploy web-services. Then, 1) Go to the below deployed path on Geronimo server: GERONIMO_HOME\repository\path-to-deployed-EAR\war name\WEB-INF ex.: E:\AG-Servers\geronimo-tomcat6-javaee5-2.1\repository\default\HelloWorldEAR\1.0\HelloWorldEAR-1.0.car\HelloWorld.war\WEB-INF 2) Copy server-config.wsdd from here into the following path on your eclipse workspace: eclipse-workspace-path\web-project-containing-webservice\WebContent\WEB-INF ex: E:\IDEworkspaces\testWebService\HelloWorld\WebContent\WEB-INF (or you can easily drag-n-drop server-config.wsdd into the above workspace path). That's it and all further deploy/redeploy will work correctly even across eclipse restarts. Publish operation after an Eclipse restart deletes a deployed Web Service's server-config.wsdd file - Key: GERONIMODEVTOOLS-256 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-256 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0.0 Environment: AG 2.0.2 + Geronimo Eclipse Plug-in v2.0 + WTP 2.0.1 Reporter: Shiva Kumar H R Assignee: Shiva Kumar H R Fix For: 2.1.x Steps to recreate: 1) Create a Web Service as per the instructions at http://www.eclipse.org/webtools/jst/components/ws/1.5/tutorials/BottomUpWebService/BottomUpWebService.html 2) Test the web service using (the auto launched) Web Service Explorer. Everything works fine. 3) Shut down server and restart the server. Again launch the web service. It runs fine without any error. 4) Shut down server, close eclipse, restart eclipse, start server. This time try to access the web service and you will not be able to access it. An initial analysis shows that in Step-4 (after a Eclipse Server restart) the Publish operation of Eclipse is deleting server-config.wsdd from GERONIMO_HOME\repository\path-to-deployed-EAR\war name\WEB-INF directory. You will get the following error in the console: 17:01:56,218 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd Is this related to the issue reported in http://mail-archive.ow2.org/jonas-team/2006-08/msg00046.html ? Needs to be explored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3705) Maven 2.0.8 causes build problems
[ https://issues.apache.org/jira/browse/GERONIMO-3705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3705. -- Resolution: Fixed Fixed 2.1.1 rev 648987 Maven 2.0.8 causes build problems - Key: GERONIMO-3705 URL: https://issues.apache.org/jira/browse/GERONIMO-3705 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: Jason Dillon Assignee: David Jencks Priority: Critical Fix For: 2.1.1, 2.1.x, 2.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] GEP 2.1 support for v1.1
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] 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
[BUILD] trunk: Failed for Revision: 648985
Geronimo Revision: 648985 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 32 minutes 6 seconds [INFO] Finished at: Thu Apr 17 03:59:28 EDT 2008 [INFO] Final Memory: 330M/732M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/logs-0300-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/logs-0300-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 74.027 sec FAILURE! Samples: trunk = Log: http://people.apache.org/builds/geronimo/server/binaries/trunk/20080417/samples-0300.log Build status: OK
Re: [DISCUSS] Policy for granting write access to our Wiki
I am supportive of Erik's suggestion. I am absolutely against a process involving the submission of an iCLA. Is a checkbox really required? Isn't a disclaimer enough to protect IP rights? Thanks, Gianny On 17/04/2008, at 4:01 AM, Jason Warner wrote: I'd be more inclined to do something akin to what Erik suggested. I'm concerned that the process to gain access to editing the wiki would deter many of the people that add a page here and there that describes something they've done. A number of our contributions come from people who are just making a one time edit. I can't imagine many of them would go through the effort to gain contributor access to add a single page. On Wed, Apr 16, 2008 at 1:57 PM, Erik B. Craig [EMAIL PROTECTED] wrote: I agree that we definitely need to address IP issues around documentation/the wiki... but isn't there any way to accomplish this without adding barriers to users editing content? Can we do something like wikipedia does for editing content where there is a checkbox or a notice or something saying You agree to license your contributions under the Apache Software License (similar to how JIRA is currently) -- Erik B. Craig On Wed, Apr 16, 2008 at 9:00 AM, Kevan Miller [EMAIL PROTECTED] 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 -- ~Jason Warner
Re: Geronimo specs jars in OSGi
On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? Unless I'm mistaken it shouldn't cause any troubles on non-osgi environments and big +1 for the upcoming changes. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: remote ejb scalability issue
Hi, It would be great to have only one TCP/IP connection opened between an EJB client and the EJB server and this across multiple requests. My understanding is that at the moment a TCP/IP connection is negotiated for each EJB request which is very expensive especially based on the rather small size of the payload being passed back and forth over TCP/IP. Thanks, Gianny On 17/04/2008, at 12:27 PM, Kevan Miller wrote: On Apr 16, 2008, at 6:30 PM, Trygve Hardersen wrote: I checked out the 2.1.1 branch that is using openejb 3.0, but I'm still getting the error. It seems less frequent though, but it's still bad. The stack trace is different, but the root cause is the same: Hi Trygve, I'm guessing that you're running on a Windows? I've only seen this type of error happen on a Windows. Note that this is a client socket (not a server socket). We aren't assigning the port address... It's being assigned to the socket dynamically. One possibility is that you are exhausting the available user port numbers. When a socket is closed, it goes into a TIME_WAIT state and isn't actual closed until some delay time. By default, the max user port address is 5000 and the TIME_WAIT delay is 4 minutes. So, it's not too difficult to exhaust all possible user port addresses. You have to update the Windows Registry to change these values. Here's a Windows 2000 doc on the registry settings -- http:// technet.microsoft.com/en-us/library/bb726981.aspx MaxUserPorts controls the upper range for user ports. TcpTimedWaitDelay controls the TIME_WAIT delay. Hopefully, increasing MaxUserPorts (e.g. 65534) and decreasing TcpTimedWaitDelay (e.g. 30)will fix your problem. If not, then I also recall a problem where Windows would assign the same dynamic port address to 2 (or more) newly created sockets. It was then a race to see which one would be activated first and the other one would get a bind failure. Not sure there's anything we can do about that... --kevan
Re: [DISCUSS] Policy for granting write access to our Wiki
On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote: I am supportive of Erik's suggestion. I am absolutely against a process involving the submission of an iCLA. Is a checkbox really required? Isn't a disclaimer enough to protect IP rights? Well, I think we can assume that a checkbox was a requirement for Jira- based submissions (a disclaimer was not sufficient). Since, Wiki submissions are essentially the same, I don't think a simple disclaimer will be sufficient... --kevan
[jira] Created: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21
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 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.
Re: remote ejb scalability issue
On Apr 17, 2008, at 8:31 AM, Gianny Damour wrote: Hi, It would be great to have only one TCP/IP connection opened between an EJB client and the EJB server and this across multiple requests. My understanding is that at the moment a TCP/IP connection is negotiated for each EJB request which is very expensive especially based on the rather small size of the payload being passed back and forth over TCP/IP. Definitely agree it's something to look into. I had thought about that, but got focussed on getting this guy past his immediate problem. You should make this suggestion on [EMAIL PROTECTED] --kevan
[jira] Updated: (GERONIMO-3959) Freeze during deploying OrderEAR sample from GMOxDOC21
[ https://issues.apache.org/jira/browse/GERONIMO-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michał Kudła updated GERONIMO-3959: --- Attachment: GMOxDOC21_Order.zip - sources, - binaries, - geronimo logs 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.
[jira] Updated: (GERONIMO-3900) Add runtime support for non-Sun JVMs
[ https://issues.apache.org/jira/browse/GERONIMO-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3900: --- Fix Version/s: (was: 2.1.1) 2.1.x Donald, I have to assume that this issue is not yet resolved for 2.1.1. If it is in fact resolved, please correct the fix version and mark it as resolved. Thanks, Joe Add runtime support for non-Sun JVMs Key: GERONIMO-3900 URL: https://issues.apache.org/jira/browse/GERONIMO-3900 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: common Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.0.x, 2.1.x, 2.2 Add support for non-Sun JVMs. The IBM JVM needs a different cert handler setup. Will also add initial Harmony support, which will need to be refined once the TCK is running against it. Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM vs. Harmony specific property settings. Will also add a JvmVendor class, to properly detect the JVM being used at runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3930) IllegalArgumentException reading Transaction Log
[ https://issues.apache.org/jira/browse/GERONIMO-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn updated GERONIMO-3930: --- Fix Version/s: (was: 2.1.1) 2.1.x Kevan, It appears this issue will not be resolved for 2.1.1 so I'm moving the fix version to 2.1.x. Joe IllegalArgumentException reading Transaction Log Key: GERONIMO-3930 URL: https://issues.apache.org/jira/browse/GERONIMO-3930 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Kevan Miller Priority: Critical Fix For: 2.0.x, 2.1.x, 2.2 Beniamin has reported the following problem on [EMAIL PROTECTED] After processing 20k request to my webservice whose are translated to ~120k XA transactions (postgres + jms) Geronimo hangs up and does not respond on requests via HTTP, request to JMS engine (from HermesJMS) and ignores tries to shutdown server. I stopped Geronimo with kill -9 and tried to start it again and got exception: Module 11/69 org.apache.geronimo.configs/activemq-ra/2.1-SNAPSHOT/car 10:22:15,325 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.1-SNAPSHOT/car,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.IllegalArgumentException: Negative position at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:613) at org.objectweb.howl.log.BlockLogBuffer.read(BlockLogBuffer.java:412) at org.objectweb.howl.log.LogFileManager.read(LogFileManager.java:641) at org.objectweb.howl.log.LogBufferManager.replay(LogBufferManager.java:869) at org.objectweb.howl.log.Logger.replay(Logger.java:396) at org.objectweb.howl.log.xa.XALogger.open(XALogger.java:897) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:224) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:534) 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:597) 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:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at
Re: [DISCUSS] Policy for granting write access to our Wiki
Just as Dan said, I think a lightweight process would be a good idea. Not to deter users from contributing, nor hinder those approving. If we haven't had a problem with the Jira check-box format for IP reasons, this seems like not only a lightweight process but a familiar one at that. -Joseph Leong On Thu, Apr 17, 2008 at 8:37 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote: I am supportive of Erik's suggestion. I am absolutely against a process involving the submission of an iCLA. Is a checkbox really required? Isn't a disclaimer enough to protect IP rights? Well, I think we can assume that a checkbox was a requirement for Jira-based submissions (a disclaimer was not sufficient). Since, Wiki submissions are essentially the same, I don't think a simple disclaimer will be sufficient... --kevan
[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=12590035#action_12590035 ] Kevan Miller commented on GERONIMO-3959: Wow. Thanks for pointing this out... Here's the culprit: RMI TCP Connection(5)-0:0:0:0:a01:0:efe1:5803%266 daemon prio=5 tid=0x11c44420 nid=0x935400 runnable [0xb1a23000..0xb1a25d90] at java.lang.Class.getClassLoader0(Native Method) at java.lang.ClassLoader.getCallerClassLoader(ClassLoader.java:1411) at java.lang.Class.getDeclaredMethods(Class.java:1762) at org.apache.openejb.config.rules.CheckCallbacks.getMethods(CheckCallbacks.java:197) at org.apache.openejb.config.rules.CheckCallbacks.checkCallback(CheckCallbacks.java:169) at org.apache.openejb.config.rules.CheckCallbacks.validate(CheckCallbacks.java:86) at org.apache.openejb.config.rules.ValidationBase.validate(ValidationBase.java:43) at org.apache.openejb.config.AppValidator.validate(AppValidator.java:82) at org.apache.openejb.config.ValidateModules.deploy(ValidateModules.java:31) at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:141) at org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:425) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:638) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbJarInfo(EjbModuleBuilder.java:575) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext(EjbModuleBuilder.java:497) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) 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:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342) 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:867) 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:1410) at javax.management.remote.rmi.RMIConnectionImpl.access$100(RMIConnectionImpl.java:81) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1247) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1350) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:784) 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at
Re: Geronimo specs jars in OSGi
On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need to reference the implementation from the bundle. The spec jar bundle activator will use OSGi to find the META-INF/services/ entries each time a bundle is installed and if an implementation is used, will load the class through OSGi API, using the implementation bundle classloader instead of the spec jar classloader. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? Unless I'm mistaken it shouldn't cause any troubles on non-osgi environments and big +1 for the upcoming changes. Exactly, the behavior should be exactly the same in non OSGi environment. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
On Wed, Apr 16, 2008 at 5:49 PM, David Jencks [EMAIL PROTECTED] wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) Fair enough ;-) I may ping someone, as I've never worked on the TCK so far. I wonder if a package name with osgi in it somewhere would be more appropriate? Agreed. There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. I guess you are talking about the PolicyConfigurationFactory in jacc. I suppose we could extend the mechanism to include searching through the META-INF/services/xxx stuff instead of simply relying on a system property. However, the mechanism I'm thinking about is quite specific to OSGi (at least in its implementation). thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
On Thursday 17 April 2008, Jacek Laskowski wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? I'll provide an example that I'm running into In my OSGi app, if I do something like MessageFactory.newInstance() to create a new SAAJ MessageFactory, the current spec implementations check the contextClassLoader for the META-INF/services/javax.xml.soap.MessageFactory file. Outside of OSGi, that would be properly picked up from the implementation jar. Inside OSGi, the file isn't available, so it defaults to whatever version is hardcoded into the saaj-api jar, which may not even be available. Basically, in OSGi, you cannot have multiple jars/bundles export the META-INF/services directory. That won't work. Thus, the whole META-INF/services thing that all the specs rely on just doesn't work. (IMO: this is a big deficiency in the OSGi spec, but that's my opinion) The goal is to allow the default that is hard coded into the saaj-api jar to be replaced/augmented at runtime based on information the bundle listener finds in the other bundles that are available. Thus, when we call MessageFactory.newInstance(), it would probably still check META-INF/services/javax.xml.soap.MessageFactory (so someone COULD put that in their application bundle and possibly get it), but if not found, use a default value that can actually have a chance of succeeding. Dan The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? Unless I'm mistaken it shouldn't cause any troubles on non-osgi environments and big +1 for the upcoming changes. Jacek -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan
Re: Geronimo specs jars in OSGi
On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. I'm looking forward to seeing what you have in mind. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan
Re: Geronimo specs jars in OSGi
Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan
Re: Geronimo specs jars in OSGi
Do you mean your -1 only apply to extending the behavior of the spec in the J2EE environment, and does not apply to extending the behavior in an OSGi environment ? I'm not sure to completely understand your reasoning. On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Policy for granting write access to our Wiki
Back on the check box option, we can customize Confluence so it includes an additional step (the check box) before enabling to save the page. There are two approaches, one is to create a Confluence plugin to replace the current editpage.action and the other is to create a new custom editpage velocity macro and make some changes in Confluence configs to use this new functionality. In either case we'll need to ASF infra blessing to implement this change. I think all ASF projects using Confluence can benefit from this change. Any velocity/confluence folk monitoring this thread that want to volunteer !? ;-) I'm just not having the spare cycles to investigate this more in detail. Cheers! Hernan Joseph Leong wrote: Just as Dan said, I think a lightweight process would be a good idea. Not to deter users from contributing, nor hinder those approving. If we haven't had a problem with the Jira check-box format for IP reasons, this seems like not only a lightweight process but a familiar one at that. -Joseph Leong On Thu, Apr 17, 2008 at 8:37 AM, Kevan Miller [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Apr 16, 2008, at 7:34 PM, Gianny Damour wrote: I am supportive of Erik's suggestion. I am absolutely against a process involving the submission of an iCLA. Is a checkbox really required? Isn't a disclaimer enough to protect IP rights? Well, I think we can assume that a checkbox was a requirement for Jira-based submissions (a disclaimer was not sufficient). Since, Wiki submissions are essentially the same, I don't think a simple disclaimer will be sufficient... --kevan
Re: Geronimo specs jars in OSGi
On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need to reference the implementation from the bundle. The spec jar bundle activator will use OSGi to find the META-INF/services/ entries each time a bundle is installed and if an implementation is used, will load the class through OSGi API, using the implementation bundle classloader instead of the spec jar classloader. I think, just my personal opinion, that scouring bundles' META-INF/ services entries is kinda klunky. Could we not use a service/ whiteboard approach that is common in OSGi? When in Rome, do as the Romans do. Let's assume that we go with the virgin spec jar wrapped in a bundle paradigm I spoke of in a previous post. Here the bundles that use the stax api would register stax api service implementations. The stax api would catch those service registrations and properly configure the factory. A bit cleaner imo and you don't have to search every bundle. Regards, Alan
Re: Geronimo specs jars in OSGi
On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. Non OSGi environments use the vanilla jar as they currently do. OSGi environments load the spec bundle. Doesn't seem confusing to me. On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-( On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need to reference the implementation from the bundle. The spec jar bundle activator will use OSGi to find the META-INF/services/ entries each time a bundle is installed and if an implementation is used, will load the class through OSGi API, using the implementation bundle classloader instead of the spec jar classloader. I think, just my personal opinion, that scouring bundles' META-INF/services entries is kinda klunky. Could we not use a service/whiteboard approach that is common in OSGi? When in Rome, do as the Romans do. Let's assume that we go with the virgin spec jar wrapped in a bundle paradigm I spoke of in a previous post. Here the bundles that use the stax api would register stax api service implementations. The stax api would catch those service registrations and properly configure the factory. A bit cleaner imo and you don't have to search every bundle. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: Geronimo specs jars in OSGi
IIUC, they're not entirely legacy, i.e. you at least put in the OSGi manifest entries. You do so using the maven/BND plugin I suspect. This strikes me as a common service discovery pattern. Off the top of my head I would think that a plugin that adds the necessary BundleActivator for legacy modules would be useful. Another thought that flashed in my head is that in a buttoned down environment getting service notifications might be easier than getting access to every Bundle's class loader. Regards, Alan On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-( On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need to reference the implementation from the bundle. The spec jar bundle activator will use OSGi to find the META-INF/services/ entries each time a bundle is installed and if an implementation is used, will load the class through OSGi API, using the implementation bundle classloader instead of the spec jar classloader. I think, just my personal opinion, that scouring bundles' META-INF/ services entries is kinda klunky. Could we not use a service/whiteboard approach that is common in OSGi? When in Rome, do as the Romans do. Let's assume that we go with the virgin spec jar wrapped in a bundle paradigm I spoke of in a previous post. Here the bundles that use the stax api would register stax api service implementations. The stax api would catch those service registrations and properly configure the factory. A bit cleaner imo and you don't have to search every bundle. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMO-3960) Make the spec jars OSGi friendly
Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo specs jars in OSGi
Sorry. This is for David's idea: I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. Another reason to wrap the spec jar in a bundle is that we won't be seen as extending the spec, something that is explicitly prohibited in the licensing of the JSRs. Regards, Alan On Apr 17, 2008, at 7:17 AM, Guillaume Nodet wrote: Do you mean your -1 only apply to extending the behavior of the spec in the J2EE environment, and does not apply to extending the behavior in an OSGi environment ? I'm not sure to completely understand your reasoning. On Thu, Apr 17, 2008 at 4:15 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Sorry, I meant to say: On Apr 17, 2008, at 7:11 AM, Alan D. Cabrera wrote: On Apr 16, 2008, at 8:49 AM, David Jencks wrote: I'd like to see an example in action before I commit myself but so far I don't see any problems with this. I assume you have already or will soon verify this doesn't cause problems with the tck :-) I wonder if a package name with osgi in it somewhere would be more appropriate? There are some specs (jacc for instance) that use a system property to figure out what to create. I've always thought this was a less than brilliant idea and wonder if we can do something similar for those. I also wonder if there is a way to generalize the osgi method so it might work in some non-osgi environments. -1 technical veto These are spec jars and extending the behavior of these jars on an ad hoc basis is bad and possibly violates the licenses of the JSRs they implement. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Updated: (GERONIMO-3960) Make the spec jars OSGi friendly
[ https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-3960: -- Attachment: stax-osgi.diff Examples of OSGi friendly spec for stax Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Attachments: stax-osgi.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly
[ https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590045#action_12590045 ] Alan Cabrera commented on GERONIMO-3960: What about bundle updates? I don't think that this code will handle those situations. Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Attachments: stax-osgi.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo specs jars in OSGi
i don't mean legacy jars but legacy *code*. If you have a jar which uses javax.xml.stream.XMLInputFactory.newInstance() somewhere deep in the code, I don't really understand how using a whiteboard pattern will solve the problem. I'm not trying to make people rewrite everything, but rather make things easy for them to deploy their application and keep the behavior they are used to see. it could be you want to deploy the jaxws-ri, jersey or any other xml related technology that could use SAAJ, Stax, Jaxb2 ... On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: IIUC, they're not entirely legacy, i.e. you at least put in the OSGi manifest entries. You do so using the maven/BND plugin I suspect. This strikes me as a common service discovery pattern. Off the top of my head I would think that a plugin that adds the necessary BundleActivator for legacy modules would be useful. Another thought that flashed in my head is that in a buttoned down environment getting service notifications might be easier than getting access to every Bundle's class loader. Regards, Alan On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-( On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need to reference the implementation from the bundle. The spec jar bundle activator will use OSGi to find the
Re: Geronimo specs jars in OSGi
I must be missing something. That legacy code would not need to change. The whiteboard pattern only obviates the need to scavenge every bundle the META-INF/services entries. The rest works as you say. But, as I think about it some more, I'm thinking that this is over engineering it. Let's drop this aspect of the thread. I still feel strongly that the virgin spec jar should be wrapped in a bundle. Regards, Alan On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote: i don't mean legacy jars but legacy *code*. If you have a jar which uses javax.xml.stream.XMLInputFactory.newInstance() somewhere deep in the code, I don't really understand how using a whiteboard pattern will solve the problem. I'm not trying to make people rewrite everything, but rather make things easy for them to deploy their application and keep the behavior they are used to see. it could be you want to deploy the jaxws-ri, jersey or any other xml related technology that could use SAAJ, Stax, Jaxb2 ... On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: IIUC, they're not entirely legacy, i.e. you at least put in the OSGi manifest entries. You do so using the maven/BND plugin I suspect. This strikes me as a common service discovery pattern. Off the top of my head I would think that a plugin that adds the necessary BundleActivator for legacy modules would be useful. Another thought that flashed in my head is that in a buttoned down environment getting service notifications might be easier than getting access to every Bundle's class loader. Regards, Alan On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-( On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? This is the tricky part. The work we've done on the specs so far means that each spec is an OSGi bundle. In OSGi, each bundle has each own classloader and classloaders are not organized in a simple tree: if bundle A requires bundle B and bundle B requires bundle C, it does not mean that C will be accessible to A. Following so far ? So, let's say I create a bundle that references the Stax Api. My bundle will have the geronimo stax api in its classpath. The stax implementation that I deploy will also have the stax api in its classpath, but it won't be available to either the the stax api or my bundle. The problem happens when the stax api needs to find and create the implementation. Usually, the existing code won't be able to do that at all, because the META-INF/services and the implementation class are not available from the stax api classloader. One way to work around that is (if the api uses the thread context classloader) to make sure my bundle includes the implementation in its classloader and make sure the thread context classloader is correctly set. This usually involves copying the META-INF/services/xx stuff in our bundle and explicitely referencing the implementation to make sure the classloader includes it. The problem is that it's a bit annoying to do that on all the bundles and it does prevent swicthing implementations. So now, there is no need
[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly
[ https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590053#action_12590053 ] Guillaume Nodet commented on GERONIMO-3960: --- Yeah, not sure what events are exactly sent, but looking at the figure 4.26 (section 4.3.2 of the osgi r4 core spec), it seems like a bundle that is resolved will go back to the install stated after an update or a refresh, then back to the resolved state. If this is true, then the code should handle it correctly. I guess this would need to be property checked though. Make the spec jars OSGi friendly Key: GERONIMO-3960 URL: https://issues.apache.org/jira/browse/GERONIMO-3960 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Attachments: stax-osgi.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo specs jars in OSGi
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I must be missing something. That legacy code would not need to change. The whiteboard pattern only obviates the need to scavenge every bundle the META-INF/services entries. The rest works as you say. You mean, having each implementation jar register a service in the osgi registry ? Yeah, doable. Just requires more work. But, as I think about it some more, I'm thinking that this is over engineering it. Let's drop this aspect of the thread. I still feel strongly that the virgin spec jar should be wrapped in a bundle. I can understand that there is legal problems changing the behavior of the spec, but I'm not sure how repackaging it would lead to a different conclusion: the behavior would still be changed. If we do use a separate bundle, I would lean towards removing the existing manifest headers so that there is no confusion, but I don't really see the benefit of doing this. The added code would not run in a non-osgi environment, so there is not much risk there. Regards, Alan On Apr 17, 2008, at 7:54 AM, Guillaume Nodet wrote: i don't mean legacy jars but legacy *code*. If you have a jar which uses javax.xml.stream.XMLInputFactory.newInstance() somewhere deep in the code, I don't really understand how using a whiteboard pattern will solve the problem. I'm not trying to make people rewrite everything, but rather make things easy for them to deploy their application and keep the behavior they are used to see. it could be you want to deploy the jaxws-ri, jersey or any other xml related technology that could use SAAJ, Stax, Jaxb2 ... On Thu, Apr 17, 2008 at 4:40 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: IIUC, they're not entirely legacy, i.e. you at least put in the OSGi manifest entries. You do so using the maven/BND plugin I suspect. This strikes me as a common service discovery pattern. Off the top of my head I would think that a plugin that adds the necessary BundleActivator for legacy modules would be useful. Another thought that flashed in my head is that in a buttoned down environment getting service notifications might be easier than getting access to every Bundle's class loader. Regards, Alan On Apr 17, 2008, at 7:30 AM, Guillaume Nodet wrote: Cleaner, but the main problem is that it does not work with legacy code. Will you rewrite the jaxb2 implementation to do that instead of using the stax factory ? ;-) We've got tons of legacy stuff that use stax, or jaxb2 and i don't see rewriting the whole lot as realistic. it would also mean having an OSGi specific thing everywhere we use a factory from a j2ee spec :-( On Thu, Apr 17, 2008 at 4:24 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 17, 2008, at 6:54 AM, Guillaume Nodet wrote: On Thu, Apr 17, 2008 at 1:27 PM, Jacek Laskowski [EMAIL PROTECTED] wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism.
Re: Geronimo 2.1.1 RELEASE-NOTE README questions.
I've created an initial version of the Release Notes in the wiki at this location: http://cwiki.apache.org/GMOxDOC21/release-notes-211txt.html If there are no issues I will go ahead and include this exact same content in a RELEASE-NOTES-2.1.1.TXT for the 2.1.1 branch. Any opinion on which of the 2 locations I mentioned earlier is the correct location for the RELEASE-NOTES? If I don't hear anything I'll just include it in both places as we did for 2.1. Ditto for the README.TXT and it's 2 locations (after I get them both in sync). Joe
[jira] Updated: (GERONIMODEVTOOLS-266) GEP automation testsuite
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed updated GERONIMODEVTOOLS-266: --- Attachment: GERONIMODEVTOOLS-259e.patch GERONIMODEVTOOLS-259e.patch to add the test for all values for building an Application Client XML file. GEP automation testsuite Key: GERONIMODEVTOOLS-266 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-266 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: Tim McConnell Attachments: GERONIMO-259a.patch, GERONIMODEVTOOLS-259b.patch, GERONIMODEVTOOLS-259c.patch, GERONIMODEVTOOLS-259d.patch, GERONIMODEVTOOLS-259e.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3961) Upgrade GShell to use the latest Groovy 1.5.x release
Upgrade GShell to use the latest Groovy 1.5.x release - Key: GERONIMO-3961 URL: https://issues.apache.org/jira/browse/GERONIMO-3961 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: dependencies Affects Versions: 2.1.x, 2.2 Reporter: Donald Woods Fix For: 2.1.x, 2.2 It seems that we used an old groupId for the groovy-all GShell depend. The latest groovy releases (1.1-1.5.5) were published using a new groupId - org.codehaus.groovy and can be found under - http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/ We should upgrade to a 1.5.x version of groovy, so we are current with their releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo specs jars in OSGi
On Thursday 17 April 2008, Alan D. Cabrera wrote: On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. Non OSGi environments use the vanilla jar as they currently do. OSGi environments load the spec bundle. Doesn't seem confusing to me. Well, it IS confusing when you have projects that are required to work in both OSGi and non-OSGi environments. Suddenly, they have to ship two versions of the same jar so downloads are bigger. They have to document when they can use one versus the other. You have to deal with users that don't read the docs and try to do something with the wrong one, etc... Not fun. There are also issues with maven and dependencies (must depend on the non-osgi for compiling, but the non-osgi for testing/shipping?), but that's a completely different issue. Dan On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
[jira] Resolved: (GERONIMO-3416) make some -test artifacts that for instance start up a mock server suitable for testing deployment parts
[ https://issues.apache.org/jira/browse/GERONIMO-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMO-3416. Resolution: Fixed This has been inactive for about 8 months since the patch was applied, so marking it as resolved. Please reopen if there is more work required. make some -test artifacts that for instance start up a mock server suitable for testing deployment parts Key: GERONIMO-3416 URL: https://issues.apache.org/jira/browse/GERONIMO-3416 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: David Jencks Assignee: David Jencks Fix For: 2.1 There's a lot of duplicated code among the deployer tests. A lot of it could be simplified if we had one or two -test.jar artifacts from appropriate modules (kernel and system come to mind) that for instance set up a mock server with config stores, repos, etc etc started. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3756) Blank screen in Security Realms portlet if wrong file path is specified
[ https://issues.apache.org/jira/browse/GERONIMO-3756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3756: --- Fix Version/s: (was: 2.0.x) Blank screen in Security Realms portlet if wrong file path is specified --- Key: GERONIMO-3756 URL: https://issues.apache.org/jira/browse/GERONIMO-3756 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.2 Environment: All Reporter: Manu T George When I try to create a property file realm from the security realms portlet and I give a wrong file path for the user and group files, I get a blank screen on clicking next. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1.1 RELEASE-NOTE README questions.
Sorry, started typing this yesterday and got distracted... On Apr 16, 2008, at 5:04 PM, Hernan Cunico wrote: Joe Bohn wrote: RELEASE_NOTES: 1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files in our source. They are both identical. One is in our root ... branches/2.1.1/RELEASE-NOTES-2.1.txt. The other is branches/2.1.1/ assemblies/geronimo-boilerplate-minimal/src/main/underlay/ RELEASE_NOTES-2.1.txt. Are both of these necessary? If not, which one is really required? The one in branches/2.1.1/ is for source distributions. The copy in underlay/ is for binary distributions. If you can figure out how to include the branches/2.1.1/ copy into our binary distributions, then just that one is sufficient. Otherwise, we should have both... 2) How elaborate do the release notes need to be for a maintenance release like 2.1.1? For example, our 2.1 release notes included a list of enhancements explaining each. I was just planning to list the JIRAs that were included in the release since most items are bug fixes and remove the 2.1 enhancement content. Is that sufficient and what we have done in the past? If it is only bug fixes then that should be the focus, no need to include the Geronimo 2.1 Enhancements again I guess. We need to make sure we clearly mention this is a maintenance release and that no new functionality has been introduced Personally, I'd make the bug fixes cumulative -- 2.1 enhancements + 2.1.1 bug fixes. Next service release we add 2.1.2 bug fixes. 3) Why is the version number in the name? I assume that I need to rename the current one to reflect that this is 2.1.1 ... but it might be better to just remove the version number completely when I rename it. For one, it help us develop/maintain the release notes in the wiki (can't have 2 files with the same name). Second, I guess it's the fastest way to know the installed version. Specially when you have multiple installs and have been chopping the geronimo_home directory to single characters to run worry free on certain platform ;-) Cheers! Hernan README.txt: 4) As with the RELEASE_NOTES we also have 2 instances of the README.txt file in our source. One is in our root ... branches/ 2.1.1/README.txt. The other is branches/2.1.1/assemblies/geronimo- boilerplate-minimal/src/main/underlay/README.txt. There is one minor difference between the 2 files. Are both of these necessary and if not, which one is required? Same reason as above... --kevan
[jira] Updated: (GERONIMO-3466) car-maven-plugin can not generate server plugin which includes EJB
[
https://issues.apache.org/jira/browse/GERONIMO-3466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-3466:
---
Affects Version/s: 2.2
2.1.x
2.1.1
2.0.x
2.1
Fix Version/s: (was: 2.0.x)
car-maven-plugin can not generate server plugin which includes EJB
--
Key: GERONIMO-3466
URL: https://issues.apache.org/jira/browse/GERONIMO-3466
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: car-maven-plugin
Affects Versions: 2.0.1, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2
Reporter: YunFeng Ma
Assignee: David Jencks
Attachments: calculator-stateless-ear.zip
openejb-deployer configuration depends on openejb configuration, and openejb
configuration depends on j2ee-server configuration. That means
car-maven-plugin has to start all the depended configurations, not only the
openejb-deployer configuration. This caused the following error.
{code}
[INFO] Scanning for projects...
[INFO]
-
---
[INFO] Building daytrader-derby-tomcat
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [dependency:unpack {execution: unpack-distribution}]
[INFO] Configured Artifact:
org.apache.geronimo.daytrader:daytrader-ear:2.0:ear
[INFO] daytrader-ear-2.0.ear already unpacked.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
F:\WASCE\samples_v2\plugins\daytrader-derby-tomcat\target\plan
\plan.xml
log4j:WARN No appenders could be found for logger
(org.codehaus.mojo.pluginsuppo
rt.logging.Logging).
log4j:WARN Please initialize the log4j system properly.
[INFO] [car:package]
[INFO] Packaging module configuration:
F:\WASCE\samples_v2\plugins\daytrader-der
by-tomcat\target\plan\plan.xml
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] start of org.apache.geronimo.configs/openejb-deployer/2.0.1/car failed
Configuration org.apache.geronimo.configs/j2ee-system/2.0.1/car failed to
start
due to the following reasons:
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=GBean,name=ServerInfo did not start because Could not determine
geronimo
installation directory
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=Repository,name=Repository did not start because
org.apache.geronimo.conf
igs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/
2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ConfigurationStore,name=Local did not start because
org.apache.geronimo.c
onfigs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-syst
em/2.0.1/car,j2eeType=Repository,name=Repository did not start.
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=AttributeStore,name=AttributeManager did not start because
org.apache.ger
onimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2
ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ArtifactResolver,name=ArtifactResolver did not start because
org.apache.g
eronimo.configs/j2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/
j2ee-system/2.0.1/car,j2eeType=GBean,name=ServerInfo did not start.
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=ConfigurationManager,name=ConfigurationManager did not start because
the
following dependent services did not start:
[org.apache.geronimo.configs/j2ee-sy
stem/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j
2eeType=ArtifactResolver,name=ArtifactResolver,
org.apache.geronimo.configs/j2ee
-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/ca
r,j2eeType=AttributeStore,name=AttributeManager]
The service
ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1/car,j2
eeType=SystemLog,name=Logger did not start because
org.apache.geronimo.configs/j
2ee-system/2.0.1/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0.1
/car,j2eeType=GBean,name=ServerInfo did not start.
[INFO]
[jira] Updated: (GERONIMO-3392) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth
[ https://issues.apache.org/jira/browse/GERONIMO-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3392: --- Affects Version/s: 2.1.x 2.1.1 2.0.1 2.0.2 2.1 Fix Version/s: (was: 2.2) (was: 2.0.x) CA Helper App - Unable to find HTTPS Connector configured for ClientAuth Key: GERONIMO-3392 URL: https://issues.apache.org/jira/browse/GERONIMO-3392 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2 Environment: G 2.0 Tomcat Reporter: Vamsavardhana Reddy The CA Helper application is unable to find HTTPS Connector configured for ClientAuth. This is because the new Tomcat HTTPS Connector GBeans no longer implement TomcatSecureConnector and so AbstractNameQuery(SecureConnector.class.getName()) will not help fetch Tomcat SSL Connectors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3389) console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector
[ https://issues.apache.org/jira/browse/GERONIMO-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3389: --- Affects Version/s: 2.2 2.1.x 2.1.1 2.0.1 2.0.2 Fix Version/s: (was: 2.0.x) console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector - Key: GERONIMO-3389 URL: https://issues.apache.org/jira/browse/GERONIMO-3389 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation, Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2 Environment: Windows xp sp2, IE, Firefox Reporter: Song Click on Save button after entering all necessary parameters for creating a new Tomcat APR HTTP Connector test_APR_HTTP, it returned to the Network Listeners list page. However,the Protocol for test_APR_HTTP is empty, State is failed. And java.lang.UnsatisfiedLinkError is thrown from the server started console and server.log. Same error to creating Tomcat APR HTTPS Connetor. Detailed error as below: -- 13:33:46,515 WARN [ConnectorGBean] test_APR_HTTP connector failed 13:33:46,515 ERROR [Connector] Coyote connector has not been started 13:33:46,515 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car,j2eeType=GBean,name=test_APR_HTTP java.lang.UnsatisfiedLinkError: org/apache/tomcat/jni/Pool.create(J)J at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:579) at org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.java:121) at org.apache.catalina.connector.Connector.initialize(Connector.java:1059) at org.apache.catalina.core.StandardService.addConnector(StandardService.java:267) at org.apache.catalina.startup.Embedded.addConnector(Embedded.java:327) at org.apache.geronimo.tomcat.TomcatContainer.addConnector(TomcatContainer.java:383) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$fa3733e1.addConnector(generated) at org.apache.geronimo.tomcat.connector.ConnectorGBean.doStart(ConnectorGBean.java:95) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.connector.Http11APRProtocol$$EnhancerByCGLIB$$abc46ac2.startRecursive(generated) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:146) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at
[jira] Updated: (GERONIMO-3244) Tasklist for adding new marshalling/unmarshalling testset(s) to the Corba testsuite
[ https://issues.apache.org/jira/browse/GERONIMO-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3244: --- Affects Version/s: 2.2 2.1.x Fix Version/s: (was: 2.0.x) setting Fix Versions to unknown, until this work starts up again Tasklist for adding new marshalling/unmarshalling testset(s) to the Corba testsuite --- Key: GERONIMO-3244 URL: https://issues.apache.org/jira/browse/GERONIMO-3244 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.0.x, 2.1.x, 2.2 Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3900) Add runtime support for non-Sun JVMs
[ https://issues.apache.org/jira/browse/GERONIMO-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3900: --- Fix Version/s: (was: 2.1.x) (was: 2.0.x) 2.1.1 Still need to apply the updates to trunk (2.2.) Removing 2.0.x as a target fix release. Add runtime support for non-Sun JVMs Key: GERONIMO-3900 URL: https://issues.apache.org/jira/browse/GERONIMO-3900 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: common Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.1.1, 2.2 Add support for non-Sun JVMs. The IBM JVM needs a different cert handler setup. Will also add initial Harmony support, which will need to be refined once the TCK is running against it. Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM vs. Harmony specific property settings. Will also add a JvmVendor class, to properly detect the JVM being used at runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-3962: -- Attachment: jaxws-2.0.diff AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Geronimo 2.1.1 RELEASE-NOTE README questions.
Kevan Miller wrote: Sorry, started typing this yesterday and got distracted... On Apr 16, 2008, at 5:04 PM, Hernan Cunico wrote: Joe Bohn wrote: RELEASE_NOTES: 1) I've noticed that we actually have 2 RELEASE_NOTES-2.1.txt files in our source. They are both identical. One is in our root ... branches/2.1.1/RELEASE-NOTES-2.1.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/RELEASE_NOTES-2.1.txt. Are both of these necessary? If not, which one is really required? The one in branches/2.1.1/ is for source distributions. The copy in underlay/ is for binary distributions. If you can figure out how to include the branches/2.1.1/ copy into our binary distributions, then just that one is sufficient. Otherwise, we should have both... 2) How elaborate do the release notes need to be for a maintenance release like 2.1.1? For example, our 2.1 release notes included a list of enhancements explaining each. I was just planning to list the JIRAs that were included in the release since most items are bug fixes and remove the 2.1 enhancement content. Is that sufficient and what we have done in the past? If it is only bug fixes then that should be the focus, no need to include the Geronimo 2.1 Enhancements again I guess. We need to make sure we clearly mention this is a maintenance release and that no new functionality has been introduced Personally, I'd make the bug fixes cumulative -- 2.1 enhancements + 2.1.1 bug fixes. Next service release we add 2.1.2 bug fixes. I was originally thinking the same thing ... then I checked back at 2.0.2 and 2.0 to discover that the original enhancements were not included in subsequent release notes. However, since we were both thinking the same thing I'll go with my original intent and update the release notes the wiki to include both. 3) Why is the version number in the name? I assume that I need to rename the current one to reflect that this is 2.1.1 ... but it might be better to just remove the version number completely when I rename it. For one, it help us develop/maintain the release notes in the wiki (can't have 2 files with the same name). Second, I guess it's the fastest way to know the installed version. Specially when you have multiple installs and have been chopping the geronimo_home directory to single characters to run worry free on certain platform ;-) Cheers! Hernan README.txt: 4) As with the RELEASE_NOTES we also have 2 instances of the README.txt file in our source. One is in our root ... branches/2.1.1/README.txt. The other is branches/2.1.1/assemblies/geronimo-boilerplate-minimal/src/main/underlay/README.txt. There is one minor difference between the 2 files. Are both of these necessary and if not, which one is required? Same reason as above... --kevan
[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590128#action_12590128 ] Jarek Gawor commented on GERONIMO-3962: --- I would be happier if I knew that this JAX-WS 2.0 api was scp copy-ied from Axis2 1_3 branch first before the OSGi modifications are added in. Can you please create the jaxws spec module from Axis2 code base first (although I'm still against this duplication between Geronimo and Axis2)? AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3961) Upgrade GShell to use the latest Groovy 1.5.x release
[ https://issues.apache.org/jira/browse/GERONIMO-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GERONIMO-3961: -- Assignee: Jason Dillon Upgrade GShell to use the latest Groovy 1.5.x release - Key: GERONIMO-3961 URL: https://issues.apache.org/jira/browse/GERONIMO-3961 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.1.x, 2.2 Reporter: Donald Woods Assignee: Jason Dillon Fix For: 2.1.x, 2.2 It seems that we used an old groupId for the groovy-all GShell depend. The latest groovy releases (1.1-1.5.5) were published using a new groupId - org.codehaus.groovy and can be found under - http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/ We should upgrade to a 1.5.x version of groovy, so we are current with their releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3900) Add runtime support for non-Sun JVMs
[ https://issues.apache.org/jira/browse/GERONIMO-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3900. -- Resolution: Fixed Merged in earlier updates from 2.1.1 into trunk (2.2) via revision 649215. Add runtime support for non-Sun JVMs Key: GERONIMO-3900 URL: https://issues.apache.org/jira/browse/GERONIMO-3900 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: common Affects Versions: 1.x, 2.0.x, 2.1, 2.1.1, 2.2 Reporter: Donald Woods Assignee: Donald Woods Fix For: 2.1.1, 2.2 Add support for non-Sun JVMs. The IBM JVM needs a different cert handler setup. Will also add initial Harmony support, which will need to be refined once the TCK is running against it. Will reuse the SystemProperties GBean, but extend it to support Sun vs. IBM vs. Harmony specific property settings. Will also add a JvmVendor class, to properly detect the JVM being used at runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3962) AL2 and OSGi friendy JAX-WS 2.0 spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590142#action_12590142 ] Guillaume Nodet commented on GERONIMO-3962: --- Agreed, I'll do that. Actually, i thought axis was using the sun jar too so i rewrote that one quickly but it does not pass the tck. I'll create a patch from the axis2 version. And I agree with the duplication, but since there are so many spec jars in geronimo already, it makes more sense to move them here imho. AL2 and OSGi friendy JAX-WS 2.0 spec jar Key: GERONIMO-3962 URL: https://issues.apache.org/jira/browse/GERONIMO-3962 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: specs Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: jaxws-2.0.diff -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] branches/2.1: Failed for Revision: 649202
Geronimo Revision: 649202 built with tests included See the full build-1400.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/build-1400.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 35 minutes 27 seconds [INFO] Finished at: Thu Apr 17 14:44:22 EDT 2008 [INFO] Final Memory: 305M/1013M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/logs-1400-tomcat/test.log Assembly: jetty = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/logs-1400-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 77.03 sec FAILURE! Samples: branches/2.1 = Log: http://people.apache.org/builds/geronimo/server/binaries/2.1/20080417/samples-1400.log Build status: OK
[jira] Created: (GERONIMO-3963) Remote deployment using the --inPlace option
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.
Re: Geronimo specs jars in OSGi
On Thu, Apr 17, 2008 at 5:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I must be missing something. That legacy code would not need to change. The whiteboard pattern only obviates the need to scavenge every bundle the META-INF/services entries. The rest works as you say. But, as I think about it some more, I'm thinking that this is over engineering it. Let's drop this aspect of the thread. Actually it may be a good idea. I think it would allow running multiple versions concurrently. This would be true for jaxb 2.0 / 2.1 I think. The reason is that the way I've done that, if you deploy a jaxb 2.1 spec jar, it could try to create a jaxb 2.0 implementation. However, using the whiteboard pattern, the implementation bundle would register its own factory in OSGi, while the spec jar would listen for compatible services. The benefit is that OSGi can check the service implementation wrt to classloader constraints and would not allow the jaxb 2.1 spec bundle to see a service implementing jaxb 2.0. This would only work if we use the versions on the packages, but it may be worth the extra work. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
[jira] Created: (GERONIMO-3964) Concentrate spec security setup for webapps into one class. Consider not using excluded permissions
Concentrate spec security setup for webapps into one class. Consider not using excluded permissions --- Key: GERONIMO-3964 URL: https://issues.apache.org/jira/browse/GERONIMO-3964 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: security Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 The security building code is a bit spread out between the jetty/tomcat web module builders, the parent AbstractWebModuleBuilder, and some classes in geronimo-security. (1) reorganize this so its easier to understand with all the code in a single package in the abstract web module builder module. Also, only use one call to do all the building. (2) Theoretically, excluded permissions are a bit weird why not simple not hand out those permissions in the first place? After the reorganization I'm planning to investigate how plausible this is. No excluded permissions fit better into a standard rbac framework and are much easier to think about IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3965) Custom LoginModule uses wrong classloader
Custom LoginModule uses wrong classloader - Key: GERONIMO-3965 URL: https://issues.apache.org/jira/browse/GERONIMO-3965 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Affects Versions: 2.1, 2.0.2 Environment: Windows XP, JDK 1.5 Reporter: Kory Markevich When specifying a custom LoginModule implementation in a geronimo-application.xml file, the class cannot be loaded if it is in the EAR. Debugging, the classloader being used belongs to OpenEJB rather than the one for the application. I have tried both versions 2.0.2 and 2.1. This bug was discovered and discussed in the mailing lists (http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html) but I couldn't find any JIRA's for it. Note that the workaround discussed in the thread cannot be used in our application, though I tried it anyway and couldn't get it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3965) Custom LoginModule uses wrong classloader
[ https://issues.apache.org/jira/browse/GERONIMO-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-3965: -- Assignee: David Jencks Custom LoginModule uses wrong classloader - Key: GERONIMO-3965 URL: https://issues.apache.org/jira/browse/GERONIMO-3965 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Environment: Windows XP, JDK 1.5 Reporter: Kory Markevich Assignee: David Jencks When specifying a custom LoginModule implementation in a geronimo-application.xml file, the class cannot be loaded if it is in the EAR. Debugging, the classloader being used belongs to OpenEJB rather than the one for the application. I have tried both versions 2.0.2 and 2.1. This bug was discovered and discussed in the mailing lists (http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html) but I couldn't find any JIRA's for it. Note that the workaround discussed in the thread cannot be used in our application, though I tried it anyway and couldn't get it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3965) Custom LoginModule uses wrong classloader
[ https://issues.apache.org/jira/browse/GERONIMO-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590225#action_12590225 ] David Jencks commented on GERONIMO-3965: Contrary to the comments on the mailing list thread, this isn't an openejb problem. Login modules are global resources and we need to set a thread context classloader suitable for a realm before trying to use it. Kinda messy but we didn't write the jaas spec. Openejb doesn't know which app you might be interested in at the point it is trying to authenticate you here, so it wouldn't know what to do anyway. I'd like to know what problems you found with the configuration suggestion I made in the thread. The user list would be a good place to discuss that. Custom LoginModule uses wrong classloader - Key: GERONIMO-3965 URL: https://issues.apache.org/jira/browse/GERONIMO-3965 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.1 Environment: Windows XP, JDK 1.5 Reporter: Kory Markevich Assignee: David Jencks When specifying a custom LoginModule implementation in a geronimo-application.xml file, the class cannot be loaded if it is in the EAR. Debugging, the classloader being used belongs to OpenEJB rather than the one for the application. I have tried both versions 2.0.2 and 2.1. This bug was discovered and discussed in the mailing lists (http://www.nabble.com/Custom-LoginModule-classloading-issue-in-gernimo-2.0.2-td14404472s134.html) but I couldn't find any JIRA's for it. Note that the workaround discussed in the thread cannot be used in our application, though I tried it anyway and couldn't get it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3964) Concentrate spec security setup for webapps into one class. Consider not using excluded permissions
[ https://issues.apache.org/jira/browse/GERONIMO-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590233#action_12590233 ] David Jencks commented on GERONIMO-3964: Reorganization done in rev 649325 Concentrate spec security setup for webapps into one class. Consider not using excluded permissions --- Key: GERONIMO-3964 URL: https://issues.apache.org/jira/browse/GERONIMO-3964 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 The security building code is a bit spread out between the jetty/tomcat web module builders, the parent AbstractWebModuleBuilder, and some classes in geronimo-security. (1) reorganize this so its easier to understand with all the code in a single package in the abstract web module builder module. Also, only use one call to do all the building. (2) Theoretically, excluded permissions are a bit weird why not simple not hand out those permissions in the first place? After the reorganization I'm planning to investigate how plausible this is. No excluded permissions fit better into a standard rbac framework and are much easier to think about IMO. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3966) Spaces in server installation directory causes deployment problems when using JMX to deploy
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.1, 2.0.2, 2.0.1 Environment: Platform independenct -- not Windows-specific as originally thought Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 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] 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=12590274#action_12590274 ] Jay D. McHugh commented on GERONIMO-3931: - This appears to be fixed in trunk. I will check to see if it is corrected in 2.1.1 tomorrow (or possibly later tonight). 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] Resolved: (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 resolved GERONIMO-3966. - Resolution: Fixed All codebase strings returned from the public methods in RMIClassLoaderSpiImpl are now normalized. There was one leg in the getClassAnnotation() method where the codebase was not getting normalized and was causing the problem. Fixed with revision 649354. 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.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] Resolved: (GERONIMODEVTOOLS-254) Spaces in server pathname causes problems for the Eclipse Plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell resolved GERONIMODEVTOOLS-254. Resolution: Fixed Fixed with revision 649354 and GERONIMO-3966 Spaces in server pathname causes problems for the Eclipse Plugin Key: GERONIMODEVTOOLS-254 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-254 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 2.0.0 Environment: Windows Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 When there are spaces in the Geronimo server pathname (on Windows), the Eclipse Plugin will have problems deploying and EAR File. For example the following error will occur: 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 message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
