Re: Stable branch for ActiveMQ 4.0.x patch releases
On 5/26/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 5/25/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi folks, * We Will Need a Branch * Now that we are close to getting past the 4.0 release, I wanted to bring up the topic of how to do bug fix maintenance for it. I think that the 4.0.1 release should stay focused on only including bug fixes. Already, I think a few too many changes have been slipping into trunk which should not be in the 4.0.1 bug fix release, so trunk could not be used to produce the 4.0.1. Clearly trunk is on already on it's way to the next 4.1 release. * Proposed Branch * I propose that we copy the 4.0 tagged release: https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/activemq to: https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.0 and use that as our 4.0 stable branch which will produce the 4.0.n series of bug fix releases. If no body objects, I'll do create this branch early next week. * Bug Fix Merging?? * Also, we need to standardize how we will apply bug fixes to branches. Once we branch, when we find a bug, we will typically need to fix the bug in both the 4.0 and the trunk branch. Once school of though is apply the bug fix to the 4.0 branch and when the 4.0.1 release is done, we merge all those fixes into trunk. I'm not a big fan of that approach, I've seen it fail too many times. Reasons: - Bug fixes get done in trunk first usually. Most developers I know prefer to work in trunk: that were the cool new shiny stuff is. - Developers manually apply the fix to both the branch and the trunk. This could cause a merge conflict at the time of the merge. They do this because either they REALLY need the fix in trunk to work around something or they just didn't know that we merge fixes in to trunk on bug fix release. So I'm actually a fan of informing folks that we don't do merges on bug fix releases and that they should manually apply their patch to all the branches that they think could benefit from the fix. This has a little more up front work for the guy applying the patch (since he has to apply it to multiple branches) but I think it leads to branches that are more stable. I would prefer branch stability for bug fixes and I concur with the idea of creating branches/activemq-4.0.x from tags/activemq-4.0 and producing the 4.0.x releases from the branch. If you don't think we should merge bug fixes from branches/activemq-4.0.x to the trunk, how do you propose we get bug fixes into the next major release? Bug fixes needs to be merged manually into trunk and all other branches manually by the person committing the fix. So the net effect is that we constantly merging in bug fixes to both the stable and trunk branch at concurrently. We don't wait to 'roll up' all the bug fixes on the stable branch so they are merged into trunk. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/ -- Regards, Hiram
snapshot problem
hello, I have downloaded the latest snapshot version (incubating-servicemix-3.0-20060523.071937-3-src.zip); I use maven 2.0.4 and java 1.5. When I start maven I obtain the following erro message: C:\Program Files\incubating-servicemix-3.0-SNAPSHOT\srcmvn [INFO] Scanning for projects... Downloading: http://servicemix.org/m2-repo/org/apache/apache/1/apache-1.pom [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.servicemix:servicemix:pom:3.0-SNAPSHOT Reason: Cannot find parent: org.apache:apache for project: org.apache.servicemix :servicemix:pom:3.0-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache :apache for project: org.apache.servicemix:servicemix:pom:3.0-SNAPSHOT at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) ... .. .. thank's emilio -- View this message in context: http://www.nabble.com/snapshot+problem-t1685469.html#a4572069 Sent from the ServiceMix - Dev forum at Nabble.com.
Issues Closed: week of 05-26-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-2046] no caching implementation ** Bug * [GERONIMO-2061] Welcome app for 1.1 features 1.0 deployment plan * [GERONIMO-2060] Changes made to plugins without bumping up version * [GERONIMO-1900] Sample app links on welcome app are broken by default * [GERONIMO-2049] Jetty HTTPS edit shows no keystores in list * [GERONIMO-2056] Plugins plugin.xml has hardcoded version numbers * [GERONIMO-2051] Console Jetty HTTPS connector has wrong trust store help text * [GERONIMO-2050] Unlocking a trust store still prompts for private key selection/password * [GERONIMO-2052] Dynamically added keystores never appear as unlocked * [GERONIMO-2057] Sun specific class references in disabled test prevent building Geronimo with a non-Sun JDK * [GERONIMO-1999] commons-modeler 1.1 is broken * [GERONIMO-2055] RunningTest is not compatible with non-Sun VMs. * [GERONIMO-2006] Deploying an application with an incorrect deployment plan results in non-functional admin console panel * [GERONIMO-2038] assemblies\minimal-tomcat-server fails on windows due to file path length * [GERONIMO-2037] Build failing on some Windows boxes and Solaris x86 * [GERONIMO-2048] Keystore manager broken (by change to fix GERONIMO-1981?) * [GERONIMO-1759] getConsoleFrameworkServletPath broken * [GERONIMO-2036] SingleFileHotDeployer doesn't undeploy app on force if directory has changed * [GERONIMO-2047] JMS resource portlet broken by change to ActiveMQ RA * [GERONIMO-2039] typos in org.apache.geronimo.kernel.config.recursiveCopy(File srcDir, File destDir) * [GERONIMO-2020] Relative symlinks to the shell scripts were not handled correctly * [GERONIMO-1762] Create a derby network /embedded XA datasource via admin console fail * [GERONIMO-1846] geronimo-config-1.1.xsd needs to be changed - import element is not valid as a child of the configId element in a plan * [GERONIMO-2043] remove context-priority-classloader element, provide separate artifact and dependency elements * [GERONIMO-1784] SQL Login Modules logs null instead of the driver name
Re: build problem on 1.1 branch?
John, On Fri, May 26, 2006 at 09:51:25AM +1000, John Sisson wrote: I built Geronimo rev 409303 ok yesterday (with OpenEJB checked out at rev 2658 via maven m:fresh-checkout command) BUILD SUCCESSFUL Total time : 117 minutes 44 seconds Finished at : Friday, May 26, 2006 2:06:10 AM EDT Looks like I'm in business. Thanks for your help! Toby
[jira] Created: (GERONIMO-2064) Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org
Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org -- Key: GERONIMO-2064 URL: http://issues.apache.org/jira/browse/GERONIMO-2064 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Paul McMahan The welcome portlet contains several links to external resources such as the FAQ, Wiki, and mailing lists. Any external resources that are not hosted at geronimo.apache.org are referred to indirectly via a redirect page that is hosted at geronimo.apache.org. For example, the location of the confluence Wiki may change so instead of hardcoding its current location which is at opensource.atlassian.com the link in welcome portlet points at a page on geronimo.apache.org that automatically redirects the browser to opensource.atlassian.com. This allows Geronimo to change where the welcome portlet points its links at without patching the console. The links to the user and dev mailing lists on the right hand column of the welcome portlet use these redirects and they work fine. However, there are two additoinal links to the user and dev mailing lists in the main text of the portlet that do not use the redirects and point directly at pages hosted at marc.theaimsgroup.com. Those links should use the redirect pages at geronimo.apache.org instead. Otherwise the links may fail or lead to inappropriate content outside the control of apache.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2064) Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org
[ http://issues.apache.org/jira/browse/GERONIMO-2064?page=all ] Paul McMahan updated GERONIMO-2064: --- Attachment: GERONIMO-2064.diff Mail archive links in the Welcome portlet should use the redirects at geronimo.apache.org - Key: GERONIMO-2064 URL: http://issues.apache.org/jira/browse/GERONIMO-2064 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Paul McMahan Attachments: GERONIMO-2064.diff The welcome portlet contains several links to external resources such as the FAQ, Wiki, and mailing lists. Any external resources that are not hosted at geronimo.apache.org are referred to indirectly via a redirect page that is hosted at geronimo.apache.org. For example, the location of the confluence Wiki may change so instead of hardcoding its current location which is at opensource.atlassian.com the link in welcome portlet points at a page on geronimo.apache.org that automatically redirects the browser to opensource.atlassian.com. This allows Geronimo to change where the welcome portlet points its links at without patching the console. The links to the user and dev mailing lists on the right hand column of the welcome portlet use these redirects and they work fine. However, there are two additoinal links to the user and dev mailing lists in the main text of the portlet that do not use the redirects and point directly at pages hosted at marc.theaimsgroup.com. Those links should use the redirect pages at geronimo.apache.org instead. Otherwise the links may fail or lead to inappropriate content outside the control of apache.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
example problem
I have tried to use (with ths snapshot incubating-servicemix-3.0-20060523.071937-3-src) the example file-binding but I obtain this result: D:\ABILITIES\implemementazione\servicemix\servicemix-assembly\src\main\release\e xamples\file-bindingservicemix servicemix.xml Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classwor lds/Launcher Which is the problem? -- View this message in context: http://www.nabble.com/example+problem-t1687327.html#a4577933 Sent from the ServiceMix - Dev forum at Nabble.com.
Mail archive links in the Welcome portlet
The welcome portlet has a couple of mail archive links that should be using the redirects hosted at geronimo.apache.org instead of referring to pages hosted outside of apache control. Otherwise the link targets can't be changed without patching the console. I attached a patch to: http://issues.apache.org/jira/browse/GERONIMO-2064 This may be important (and low risk) enough to squeeze into 1.1. Paul
[jira] Updated: (GERONIMO-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=all ] Manu T George updated GERONIMO-1557: Patch Info: [Patch Available] Summary: When you enter the url of a web service in the console You should get a page showing the service name (was: When you enter the url of a web serv?ce ?n the console You should get a page show?ng the serv?ce name) When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: webservices Versions: 1.0 Environment: All Reporter: Manu T George Priority: Minor Attachments: AxisServiceBuilder.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re-migration to m2 - status and discussion.
inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
Thank you John.
Anita, the asm dependency in axis-builder/pom.xml needs version
element.
This is because your version of parent pom.xml does not have an asm
dependency element in dependency management section. Isn't this
something that should go there?
Before you regenerate the patch the next time, can you
please
set your svn as per John's instructions in the wiki page ?
The 'modules' patch I submitted contains the follwing line for each
pom.xml -
Property changes on: scripts\pom.xml
___
Name: svn:eol-style
+ native
So I guess, they are being set by my box. There are a lot of files
in svn which need to have their eol-style set. It would be very helpful
to run the script John talked about. Otherwise the new patches are very
hard to read.
Thanks
Anita
Cheers
Prasad
On 5/25/06, John Sisson [EMAIL PROTECTED] wrote:
I am guessing this is because the svn:eol-style is property is not
set
to native for the pom.xml file and that the patch was originally
created
on a *NIX box?
Can *everyone* please check that you have svn set up as discussed
in the
document :
http://wiki.apache.org/geronimo/GettingSourceCode#head-4cfe1f3516da2bace5dcb5ed105eaed7c7478afb
so that any new files you create will have the correct svn
properties.
I can run the script I put together (
https://svn.apache.org/repos/asf/geronimo/gbuild/trunk/svnpropset.sh
) that fixes the svn properties on existing files if you like.
Let me
know..
I recommend that you make a backup of any changes you haven't
committed
first just in case.. (as fixing the line endings can result in
every
line in your files being changed, possibly causing merge issues)..
After the svn properties are fixed, the patches may need to be
regenerated.
John
Prasad Kashyap wrote:
I was able to apply the same patch on linux. Wonder why not on
windows ?
Cheers
Prasad
On 5/25/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Anita,
I'm unable to apply your modules.patch using TortoiseSVN on XP.
I first get a pop-up which says,
{g_path}/modules/tomcat/pom.xml has
no URL. It then tries to retrieve version 0 of file. That fails
and
it says, patching not possible
Am I doing anything wrong here ?
Cheers
Prasad
On 5/25/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
Anita, that is okay with me.
So we shall continue to use the old JIRA G-851.
You now seem to have a uber patch, one each for the modules
and
configs. This, I believe, will contain the different patches
that we
submitted for the individual modules and configs.
You may attach those modules.patch and config.patch to the
G-851
jira.
I shall attach a similar uber patch for the applications in
the same
jira.
I will rebuild the patches against the trunk. I am still
trying to
get an m1 build for the trunk.
The pom.patch from your G-1740 couldn't be applied because
the
pom.xml
had changed in G-2053. Just fyi. You may want to redo that
pom.patch
or I can submit the changes I made.
If you have the latest dependency versions, you can
submit the
patch. I only added few o.a.g.modules and and o.a.g.plugins
dependencies and few missing dependency versions.
Thnaks
Anita
We could go ahead from there on.
Thanx
Prasad
On 5/25/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
inline..
--- Prasad Kashyap [EMAIL PROTECTED] wrote:
Now that we have a new 1.2 trunk, we can go ahead
migrating the
build
to m2 (again).
A recap:
1. The build in the old trunk was migrated to m2. It can
be
found
here
http://svn.apache.org/viewvc/geronimo/branches/dead-1.2/
2. The old migration JIRA was under the JIRA G-851.
http://issues.apache.org/jira/browse/GERONIMO-851
3. The migration status can be found here
http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Migration+Status
- All the modules (with their tests) were successfully
migrated.
- All the applications (with their tests) were
successfully
migrated.
- I believe some of the configs were migrated (Anita
?).
- The deployment and packaging plugins were migrated.
The configs and plugin patch was never applied,
because we had
decided to wait for the merge.
So now, we should starting porting those changes back
again into
the
new trunk.
Jacek, should we open a new JIRA on the lines on 851 or
should we
continue to work with 851 ?
Help assigning GERONIMO-1860
Anybody (maybe Dain) here who can help me have G-1860 assigned to me - ccardona? TIA. chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
OpenEJB for Geronimo Trunk 1.1
Is Geronimo trunk pointing to a different OpenEJB branch than Geronimo 1.1 is? (If not, I guess we shouldn't make OpenEJB changes in trunk yet?) Also, if OpenEJB moves to Apache, will the current 2.1 branch be maintained at codehaus or elsewhere so if we need a new 2.1.x release for Geronimo 1.1.1 we won't need to work through the incubator? Thanks, Aaron
Schema duplication/inconsistency in patternType
Aaron pointing out a long time ago that we have two similar elements with the same localName in our plan schemas: In geronimo-module-1.1.xsd: xs:complexType name=patternType xs:annotation xs:documentationThis group contains the components of an abstract name/xs:documentation /xs:annotation xs:sequence xs:sequence xs:element name=groupId type=xs:string minOccurs=0/ xs:element name=artifactId type=xs:string minOccurs=0/ xs:element name=version type=xs:string minOccurs=0/ xs:element name=module type=xs:string minOccurs=0/ xs:element name=type type=xs:string minOccurs=0/ xs:element name=name type=xs:string minOccurs=0/ /xs:sequence /xs:sequence /xs:complexType Let's call this one A This is used in gbean references ( reference element inside a gbean element) to locate the target gbean. In geronimo-naming-1.1.xsd: xsd:complexType name=patternType xsd:sequence xsd:element name=groupId type=xsd:string minOccurs=0/ xsd:element name=artifactId type=xsd:string minOccurs=0/ xsd:element name=version type=xsd:string minOccurs=0/ xsd:element name=module type=xsd:string minOccurs=0/ xsd:element name=name type=xsd:string/ /xsd:sequence /xsd:complexType Let's call this one B This is used in a jndi *-ref element to locate the gbean for a j2ee component that we will call a method on to get the j2ee component (or a proxy to it) that we hand out to whatever is looking up in jndi. There are 2 differences: 1. A has minOccurs=0 on name, in B it is required. I strongly suspect this is a bug in A and name should be required. This is IMO minor. 2. A has a type element missing in B. This is what Aaron is asking about. This is a very problematic element. Based on the element localName type, it could mean any of 3 things: - type of the geronimo module the target gbean is in. For a long time this had to be car and I'm not sure if this has changed. There's certainly been some discussion in favor of changing that restriction. At the moment I'm not in favor of changing it. - If the gbean is a j2ee component, it will be in a j2ee module, which means it's a j2ee component in a standalone module (ejb jar, war, or rar deployed into a car) or a module inside an ear. This module will have a type (EJBModule, WebModule, ResourceAdapterModule).Note that the module element will only be present if the gbean is in a j2ee module. Currently there's a bug in that if you specify module you will never find the target gbean since it will have something like EJBModule=foo but we will look for J2EEModule=foo. - Every abstract name we construct has a j2eeType key. type could refer to this. If you look at where the value of this element is used, it is used only in GBeanBuilder and it means the 3rd choice, j2eeType. As such it is unnecessary in B since we know the j2eeType of the target gbean for jndi refs since it is determined by the kind of ref it is (ejb-ref, resource-ref, etc). Also in B we can figure out the module type (as in the 2nd possibility) since an ejb will only be in an EJBModule, etc. --- proposal: We might be able to simplify this situation a little bit by: - To reduce duplication between similar elements, make the naming schema patternType a restriction of the module schema patternType, with type's maxOccurs=0. - To eliminate the bug in module schema when you specify the module, construct matching patterns using all possible module types (ServiceModule, EJBModule, WebModule, etc). There might be a similar bug in the naming schema when looking for a resource-ref that is in fact implemented as a plain gbean such as the MailGBean or JAXR connection factory. This needs more investigation. - Ignore/document the rather extreme ambiguity about the possible meaning of type I really don't know what to do about this part. I'll try implementing these and see how far I get. Due to very limited internet access at the moment I probably won't have anything to report until at least tomorrow (may 27). Comments and suggestions would be great. thanks david jencks
[jira] Created: (AMQ-726) Network connections do not reconnect when using static: with failover=true
Network connections do not reconnect when using static: with failover=true -- Key: AMQ-726 URL: https://issues.apache.org/activemq/browse/AMQ-726 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0, 4.0 M4, 4.0 RC2, 4.0 RC3 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1, 4.0.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
cwiki.apache.org and Geronimo web site update
Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: Move blocker GERONIMO-1960 to 1.1.1?
I think I've lost the thread and level-of-reply info due to having to use the web interface for mail, sorry copying the message I'm replying to... --original message thread... On May 24, 2006, at 12:47 PM, Dain Sundstrom wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non-invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -my reply Ok... so I spent most of my plane ride to Florida working on getting MagicGBall working again. The plans your verifier flagged were indeed very faulty. This makes me somewhat positive towards including this in 1.1. Anyone else think including it is reasonable? thanks david jencks -dain
Re: Move blocker GERONIMO-1960 to 1.1.1?
This may be no surprise, but I think including it is reasonable. :) Thanks, Aaron On 5/26/06, David Jencks [EMAIL PROTECTED] wrote: I think I've lost the thread and level-of-reply info due to having to use the web interface for mail, sorry copying the message I'm replying to... --original message thread... On May 24, 2006, at 12:47 PM, Dain Sundstrom wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non-invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -my reply Ok... so I spent most of my plane ride to Florida working on getting MagicGBall working again. The plans your verifier flagged were indeed very faulty. This makes me somewhat positive towards including this in 1.1. Anyone else think including it is reasonable? thanks david jencks -dain
RE: cwiki.apache.org and Geronimo web site update
Hernan, Wow, that sounds great! But what, considering this, would happen to http://opensource.atlassian.com/confluence/oss/display/GERONIMO ? Should all the documents be migrated from there? I own a document there, should I move it to the new Confluence immediately? Vasily Zakharov Intel Middleware Products Division -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:18 PM To: dev Subject: cwiki.apache.org and Geronimo web site update Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: Stable branch for ActiveMQ 4.0.x patch releases
On 5/25/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi folks, * We Will Need a Branch * Now that we are close to getting past the 4.0 release, I wanted to bring up the topic of how to do bug fix maintenance for it. I think that the 4.0.1 release should stay focused on only including bug fixes. Already, I think a few too many changes have been slipping into trunk which should not be in the 4.0.1 bug fix release, so trunk could not be used to produce the 4.0.1. Clearly trunk is on already on it's way to the next 4.1 release. * Proposed Branch * I propose that we copy the 4.0 tagged release: https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0/activemq to: https://svn.apache.org/repos/asf/incubator/activemq/branches/activemq-4.0 and use that as our 4.0 stable branch which will produce the 4.0.n series of bug fix releases. If no body objects, I'll do create this branch early next week. * Bug Fix Merging?? * Also, we need to standardize how we will apply bug fixes to branches. Once we branch, when we find a bug, we will typically need to fix the bug in both the 4.0 and the trunk branch. Once school of though is apply the bug fix to the 4.0 branch and when the 4.0.1 release is done, we merge all those fixes into trunk. I'm not a big fan of that approach, I've seen it fail too many times. Reasons: - Bug fixes get done in trunk first usually. Most developers I know prefer to work in trunk: that were the cool new shiny stuff is. - Developers manually apply the fix to both the branch and the trunk. This could cause a merge conflict at the time of the merge. They do this because either they REALLY need the fix in trunk to work around something or they just didn't know that we merge fixes in to trunk on bug fix release. So I'm actually a fan of informing folks that we don't do merges on bug fix releases and that they should manually apply their patch to all the branches that they think could benefit from the fix. This has a little more up front work for the guy applying the patch (since he has to apply it to multiple branches) but I think it leads to branches that are more stable. I would prefer branch stability for bug fixes and I concur with the idea of creating branches/activemq-4.0.x from tags/activemq-4.0 and producing the 4.0.x releases from the branch. If you don't think we should merge bug fixes from branches/activemq-4.0.x to the trunk, how do you propose we get bug fixes into the next major release? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
RE: cwiki.apache.org and Geronimo web site update
Haron, One more question, what is the difference between http://geronimo.apache.org/documentation and http://cwiki.apache.org/GERONIMO/home.html ? These locations have similar structure but are clearly different, and the latter has many documents from the old http://opensource.atlassian.com Wiki. Also, I wasn't able to find any way to register on the new site, is registration disabled for now? Thank you! Vasily -Original Message- From: Hernan Cunico [mailto:[EMAIL PROTECTED] Sent: Friday, May 26, 2006 8:18 PM To: dev Subject: cwiki.apache.org and Geronimo web site update Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: OpenEJB for Geronimo Trunk 1.1
Maybe you want to jump on this thread and post some thoughts. http://thread.gmane.org/gmane.comp.java.openejb.devel/3165/focus=3165 I've had a at least one person report not getting mail at [EMAIL PROTECTED] It turned out to be a matter of mail filtering, but looking around the net at the various mail archiving sites it seems they're having the same issue. Let me know if you encounter something odd mail-wise. Also, watch out for the reply-to setup, it's changed. -David On May 26, 2006, at 9:13 AM, Aaron Mulder wrote: Is Geronimo trunk pointing to a different OpenEJB branch than Geronimo 1.1 is? (If not, I guess we shouldn't make OpenEJB changes in trunk yet?) Also, if OpenEJB moves to Apache, will the current 2.1 branch be maintained at codehaus or elsewhere so if we need a new 2.1.x release for Geronimo 1.1.1 we won't need to work through the incubator? Thanks, Aaron
Re: cwiki.apache.org and Geronimo web site update
Hernan this looks great! Thanks for all your hard work. Paul On 5/26/06, Hernan Cunico [EMAIL PROTECTED] wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: cwiki.apache.org and Geronimo web site update
This looks excellent, Hernan! Great job! How can I get an account to help contribute? If I go to the standard Confluence signup URL: http://cwiki.apache.org/confluence/signup.action then I get a message about how: This installation of Confluence is not set up to permit public signup. Please contact the site administrators for more information. Cheers, Erin Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: cwiki.apache.org and Geronimo web site update
Very excellent work! Thanks to you and the guys on infra@ for making this happen. -David On May 26, 2006, at 9:17 AM, Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/ geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/ documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
[jira] Created: (AMQ-727) Cannot add a new connector using ActiveMQManagerGBean
Cannot add a new connector using ActiveMQManagerGBean - Key: AMQ-727 URL: https://issues.apache.org/activemq/browse/AMQ-727 Project: ActiveMQ Type: Bug Components: Geronimo Integration Versions: 3.2.4 Environment: activemq 3.2.4 running in geronimo 1.1 Reporter: Paul McMahan Priority: Critical Attachments: ACTIVEMQ-gbeaninfo.patch Trying to create a new connector from the Admin Console in Geronimo v1.1 fails with the following ST: 11:06:48,041 ERROR [JMSConnectorPortlet] Unable to process portlet action java.lang.IllegalArgumentException: GBeanInfo must have a source class set at org.apache.geronimo.system.configuration.GBeanOverride.init(GBeanOverride.java:76) at org.apache.geronimo.system.configuration.LocalAttributeManager.addGBean(LocalAttributeManager.java:320) at org.apache.geronimo.system.configuration.LocalAttributeManager$$FastClassByCGLIB$$b20ef545.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.PersistentConfigurationList$$EnhancerByCGLIB$$d01f9f2b.addGBean(generated) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:127) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager.addGBeanToConfiguration(EditableKernelConfigurationManager.java:60) at org.apache.geronimo.kernel.config.EditableKernelConfigurationManager$$FastClassByCGLIB$$daeffab3.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$e6ae163a.addGBeanToConfiguration(generated) at org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:207) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$1f9d3f5e.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:275) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at
Re: cwiki.apache.org and Geronimo web site update
Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation... Two other small comments (besides how much I like the new look)... A) Search doesn't seem to be working quite right. At the moment, it is linked to Google and seems to be adding the current domain as a site filter. Thus, on the front page of the documentation, it searches with site:geronimo.apache.org, and on the inside pages, it searches site:cwiki.apache.org. Neither of those options seems ideal (the first misses all the documentation, and the second will overlap with other projects and always be a few days/weeks behind while it waits for Google to reindex). Can we just hook up Confluence's built-in search functionality? That will have the added bonus of letting you search across a specific subset of spaces (e.g. v1.0 and v1.1). B) It would be good to have a way to get back to the main Geronimo site from the documentation (other than manually trimming the URL). My first expectation was that the Apache Geronimo link in the dark blue bar would take me there, but it doesn't. Perhaps that can be changed? It would also be good to have the logo be a link, and maybe even to add an explicit Back to the Project Home link to the front wiki page, just to keep everything well-connected. Cheers, Erin
[jira] Commented: (GERONIMO-2063) Stopping a TSSbean also stops the orb it's attached to
[ http://issues.apache.org/jira/browse/GERONIMO-2063?page=comments#action_12413506 ] Donald Woods commented on GERONIMO-2063: We really need MagicGBall to always work, so users can see a working example of how to setup and use CORBA in Geronimo. Without this sample app, only the people running CTS have any clue of how to get this to work Stopping a TSSbean also stops the orb it's attached to -- Key: GERONIMO-2063 URL: http://issues.apache.org/jira/browse/GERONIMO-2063 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Versions: 1.1 Reporter: David Jencks Fix For: 1.1 While working with the MagicGBall I noticed that you can't stop and start the application: when you try to start it again you get an exception saying the orb is shut down. I deployed the app using the console, the magicGBall ear, and either one of the plans in magicgball/target/plan. I stopped and tried to start the app after deployment using the console. I won't argue much if this gets taken out of 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Schema duplication/inconsistency in patternType
We can't assume that every module's type is car. That is not correct. Many have J2EE module types (rar, ear, war, etc.). In particular, if you're constructing a reference to an EJB, you probably need the module type to be jar and for a database pool or JMS resource is needs to be rar. (Though of course the ones configured with Geronimo by default are car.) So I think we need a type element to go with the groupId, artifactId, and version. To give a concrete example, let's say I have these 4 modules: console/MyPool1/1.0/rar - contains DB Pool MyPool console/AnotherPool/1.0/rar - contains DB Pool MyPool console/AnotherPool/1.0/jar - contains a thread pool MyPool aaron/test/1.0/war - dependency on console/MyPool1/1.0/rar - dependency on console/AnotherPool/1.0/rar - dependency on console/AnotherPool/1.0/jar - resource-ref type DataSource that I want to map to MyPool (the one in console/AnotherPool/1.0/rar) How do I set that resource-ref? I think it needs something like this: pattern groupIdconsole/groupId artifactIdAnotherPool/artifactId version1.0/version typerar/type nameMyPool/name /pattern If we leave out the type, either it assumes car (wrong) or it gets confused between DB pool MyPool in console/AnotherPool/1.0/rar and thread pool MyPool in console/AnotherPool/1.0/jar (2 matches). I recognize this is a completely different definition of type than we are currently using. I suggested using moduleType for that reason, but David J said he thought we should stick strictly to Maven syntax and therefore it needs to be called type. Personally, I don't think we need to stick to Maven syntax (since we are not using Maven or passing this plan to Maven for processing), but I don't feel super-strongly about it. Thanks, Aaron On 5/26/06, David Jencks [EMAIL PROTECTED] wrote: Aaron pointing out a long time ago that we have two similar elements with the same localName in our plan schemas: In geronimo-module-1.1.xsd: xs:complexType name=patternType xs:annotation xs:documentationThis group contains the components of an abstract name/xs:documentation /xs:annotation xs:sequence xs:sequence xs:element name=groupId type=xs:string minOccurs=0/ xs:element name=artifactId type=xs:string minOccurs=0/ xs:element name=version type=xs:string minOccurs=0/ xs:element name=module type=xs:string minOccurs=0/ xs:element name=type type=xs:string minOccurs=0/ xs:element name=name type=xs:string minOccurs=0/ /xs:sequence /xs:sequence /xs:complexType Let's call this one A This is used in gbean references ( reference element inside a gbean element) to locate the target gbean. In geronimo-naming-1.1.xsd: xsd:complexType name=patternType xsd:sequence xsd:element name=groupId type=xsd:string minOccurs=0/ xsd:element name=artifactId type=xsd:string minOccurs=0/ xsd:element name=version type=xsd:string minOccurs=0/ xsd:element name=module type=xsd:string minOccurs=0/ xsd:element name=name type=xsd:string/ /xsd:sequence /xsd:complexType Let's call this one B This is used in a jndi *-ref element to locate the gbean for a j2ee component that we will call a method on to get the j2ee component (or a proxy to it) that we hand out to whatever is looking up in jndi. There are 2 differences: 1. A has minOccurs=0 on name, in B it is required. I strongly suspect this is a bug in A and name should be required. This is IMO minor. 2. A has a type element missing in B. This is what Aaron is asking about. This is a very problematic element. Based on the element localName type, it could mean any of 3 things: - type of the geronimo module the target gbean is in. For a long time this had to be car and I'm not sure if this has changed. There's certainly been some discussion in favor of changing that restriction. At the moment I'm not in favor of changing it. - If the gbean is a j2ee component, it will be in a j2ee module, which means it's a j2ee component in a standalone module (ejb jar, war, or rar deployed into a car) or a module inside an ear. This module will have a type (EJBModule, WebModule, ResourceAdapterModule).Note that the module element will only be present if the gbean is in a j2ee module. Currently there's a bug in that if you specify module you will never find the target gbean since it will have something like EJBModule=foo but we will look for J2EEModule=foo. - Every abstract name we construct has a j2eeType key. type could refer to this. If you look at where the value of this element is used, it is used only in GBeanBuilder and it means the 3rd choice, j2eeType. As such it is unnecessary in B since we know the j2eeType of the target gbean for jndi refs since it is determined by the kind of ref it is (ejb-ref, resource-ref, etc). Also in B we
[jira] Resolved: (GERONIMO-2004) Hot deployment of welcome app failed
[ http://issues.apache.org/jira/browse/GERONIMO-2004?page=all ] Aaron Mulder resolved GERONIMO-2004: Resolution: Invalid Assign To: Aaron Mulder You can't hot deploy CAR files. You need to get the welcome WAR, insert the plan from either configs/welcome-jetty/target/plan/plan.xml or configs/welcome-tomcat/target/plan/plan.xml, and then put the war-with-plan into the hot deploy directory. Hot deployment of welcome app failed Key: GERONIMO-2004 URL: http://issues.apache.org/jira/browse/GERONIMO-2004 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: All Reporter: Anita Kulshreshtha Assignee: Aaron Mulder Fix For: 1.1 This is for rev 405570 and a freshly built j2ee-tomcat-server. The following trace can be produced by - 1. start the server 2. uninstall geronimo/welcome-tomcat/---/car using console. The uninstall was successful. 3. hot deploy 08:44:02,359 INFO [Hot Deployer] Deploying welcome-tomcat-1.1-SNAPSHOT.car 08:44:03,046 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.x ml deployment plan. This may or may not be a problem, depending on whether you have things like res ource references that need to be resolved. You can also give the deployer a separate deployment pla n file on the command line. 08:44:03,921 ERROR [Deployer] Deployment failed due to java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) 08:44:04,031 ERROR [Hot Deployer] Unable to deploy: java.io.IOException: Sum file already exists org.apache.geronimo.common.DeploymentException: java.io.IOException: Sum file already exists at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:349) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) ... 10 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see:
Re: cwiki.apache.org and Geronimo web site update
I'm working on it Cheers! Hernan Erin Mulder wrote: This looks excellent, Hernan! Great job! How can I get an account to help contribute? If I go to the standard Confluence signup URL: http://cwiki.apache.org/confluence/signup.action then I get a message about how: This installation of Confluence is not set up to permit public signup. Please contact the site administrators for more information. Cheers, Erin Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
Re: cwiki.apache.org and Geronimo web site update
Thanks for the feedback Erin. The answer to both comments is YES, we can :) Need to work on the export template to see how we can leverage Confluence built-in search engine. As for the link back to Geronimo's web site, we did not have any on the old moin moin wiki but we can add one. Cheers! Hernan Erin Mulder wrote: Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation... Two other small comments (besides how much I like the new look)... A) Search doesn't seem to be working quite right. At the moment, it is linked to Google and seems to be adding the current domain as a site filter. Thus, on the front page of the documentation, it searches with site:geronimo.apache.org, and on the inside pages, it searches site:cwiki.apache.org. Neither of those options seems ideal (the first misses all the documentation, and the second will overlap with other projects and always be a few days/weeks behind while it waits for Google to reindex). Can we just hook up Confluence's built-in search functionality? That will have the added bonus of letting you search across a specific subset of spaces (e.g. v1.0 and v1.1). B) It would be good to have a way to get back to the main Geronimo site from the documentation (other than manually trimming the URL). My first expectation was that the Apache Geronimo link in the dark blue bar would take me there, but it doesn't. Perhaps that can be changed? It would also be good to have the logo be a link, and maybe even to add an explicit Back to the Project Home link to the front wiki page, just to keep everything well-connected. Cheers, Erin
Re: Please try out the upgrade jar
David, Thanks for providing this tool, it's a big help. I had some problems on a test geronimo-application.xml file that includes some gbean references (for hooking up to security gbeans). The file looks like: = ?xml version=1.0 ? application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application; configId=hello parentId=geronimo/j2ee-security/1.0.1-SNAPSHOT/car gbean name=hello-realm class=org.apache.geronimo.security.realm.GenericSecurityRealm attribute name=realmNamehello-realm/attribute reference name=LoginModuleConfiguration namehello-login-chain/name /reference reference name=ServerInfo gbean-namegeronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=GBean,name=ServerInfo/gbean-name /reference reference name=LoginService gbean-namegeronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=JaasLoginService,name=JaasLoginService/gbean-name /reference /gbean gbean name=hello-login-chain class=org.apache.geronimo.security.jaas.JaasLoginModuleUse attribute name=controlFlagREQUIRED/attribute reference name=LoginModule namehello-login/name /reference /gbean gbean name=hello-login class=org.apache.geronimo.security.jaas.LoginModuleGBean attribute name=loginModuleClassreva.common.auth.TrivialLoginModule/attribute attribute name=serverSidetrue/attribute attribute name=options usersURI=var/security/demo_users.properties groupsURI=var/security/demo_groups.properties /attribute attribute name=loginDomainNamehello-realm/attribute /gbean /application = The problem seems to be the application/gbean/reference/gbean-name elements, as the error I get at offline deploy time looks like: Deployer operation failed: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4a: Expected elements '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1, error: cvc-complex-type.2.4a: Expected elements '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1 [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' instead of '[EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1' here in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/deployment-1.1] Descriptor: xml-fragment xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; dep:environment dep:moduleId dep:groupIddefault/dep:groupId dep:artifactIdhello/dep:artifactId dep:version1-default/dep:version dep:typecar/dep:type /dep:moduleId dep:dependencies dep:dependency dep:groupIdgeronimo/dep:groupId dep:artifactIdj2ee-security/dep:artifactId dep:version1.0.1-SNAPSHOT/dep:version dep:typecar/dep:type /dep:dependency /dep:dependencies dep:hidden-classes/ dep:non-overridable-classes/ /dep:environment dep:gbean name=hello-realm class=org.apache.geronimo.security.realm.GenericSecurityRealm dep:attribute name=realmNamehello-realm/dep:attribute dep:reference name=LoginModuleConfiguration dep:namehello-login-chain/dep:name /dep:reference dep:reference name=ServerInfo dep:gbean-namegeronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=GBean,name=ServerInfo/dep:gbean-name /dep:reference dep:reference name=LoginService dep:gbean-namegeronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=JaasLoginService,name=JaasLoginService/dep:gbean-name /dep:reference /dep:gbean dep:gbean name=hello-login-chain class=org.apache.geronimo.security.jaas.JaasLoginModuleUse dep:attribute name=controlFlagREQUIRED/dep:attribute dep:reference name=LoginModule dep:namehello-login/dep:name /dep:reference /dep:gbean dep:gbean name=hello-login
[jira] Updated: (GERONIMO-851) Move Geronimo Build to M2 (Maven 2)
[ http://issues.apache.org/jira/browse/GERONIMO-851?page=all ] Anita Kulshreshtha updated GERONIMO-851: Attachment: modules.patch The earlier modules.patch is needed for building configs. For building just the modules use this patch. This does not alter the deploy-tool directory, and allows subsequent maven1 builds. Move Geronimo Build to M2 (Maven 2) --- Key: GERONIMO-851 URL: http://issues.apache.org/jira/browse/GERONIMO-851 Project: Geronimo Type: Task Security: public(Regular issues) Components: buildsystem Reporter: John Sisson Assignee: Jacek Laskowski Fix For: 1.x Attachments: modules.patch, modules.patch, parentpom.patch, pom.patch, pom.patch Created this issue to keep track of the status of work to move the Geronimo build to Maven 2. Does anyone know the status of this effort? I believe some work was done in OpenEJB? When is the move to M2 planned for? 1.0 or 1.1 FYI.. In June I attempted to use Maven 1.1 beta 1 to build geronimo and got some parse exceptions in maven. As a result, some small changes were made to some project.xml files by David Jencks, which fixed the parse problem, but we then ran into another problem where we were getting a java.lang.NoSuchMethodError in maven. This should now be fixed using an updated artifact plugin, see http://jira.codehaus.org/browse/MAVEN-1625 (but I have not verified this). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Repository version precedence
I'm trying to get my head around the way that we make a version selection when multiple versions of a package are available. This will be important as users need to include different versions of packages beyond what geronimo bundles or if they need to override a package with a local version. I was working with the tomcat jars and so I was looking for ways to drop in a modified version of the jars and have them picked up without removing the 5.5.15 versions. Here are the items that I tried and which was chosen when compared to 5.5.15 1) 5.5.15.1 - Apparently any version with more than 2 dots is considered invalid and so the entire version is considered to be a qualifier (with a null for the major, minor incrementalVersion, and build - basically treated as 0.0.0-5.5.15.1). Any valid version is considered newer. - 5.5.15 is chosen over 5.5.15.1 - 5.5.10 is chosen over 5.5.15.1 2) 5.5.15-1 - The - is used to specify a qualifier or buildnumber. Since the value after the dash was numeric, it was considered to be a buildnumber. It appears that a build number is always considered newer than a package without a buildnumber. - 5.5.15-1 is chosen over 5.5.15 3) 5.5.15-01 - The code (Version.java) treats the leading 0 as a special case. This makes the last part a qualifier rather than a build number. Any qualified version is considered to be lower than a non-qualified version (such as with -SNAPSHOT). Anybody know why this special check for 0 is in there? - 5.5.15 is chosen over 5.5.15-01 4) 5.5.15-alpha - If the portion following the - starts with an alphabetic character then this last portion is considered a qualifier. Once again, the qualified release is considered older than the same version non-qualified. - 5.5.15 is chosen over 5.5.15-alpha First, we need to document this behavior very clearly for users that need to replace packages we ship (or their own packages included in the repo). Second, I would like to propose some changes: - IMO a qualified release should generally be considered *newer* than a non-qualified release. I think SNAPSHOT would be the only exception. Right now we treat that exception as the rule for all qualifiers. I think we should add specific code for SNAPSHOT and have all other qualified releases take precedence over a non-qualified release. I can imagine users wanting to add myjar-1.1-patch1.jar to replace myjar-1.1.jar. - I think we should treat a third . to be the logical equivalent of a - in the version. Most users would expect 5.5.15.1 to be major version 5, minor version 5, incremental version 15, build/rev/patch/whatever 1 and consider this to be newer than 5.5.15. See #1 above for how we really treat 3 dots. Providing 5.5.15-1 gives substantially different results than providing 5.5.15.1 which is not intuitive. Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Help assigning GERONIMO-1860
Chris, You need to get Dain to grant you contributor karma by adding you to the geronimo-contributors group in jira. Then you can assign the jira to yourself (assuming Paul agrees). Joe Chris Cardona wrote: Anybody (maybe Dain) here who can help me have G-1860 assigned to me - ‘ccardona’? TIA. chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Help assigning GERONIMO-1860
Joe, Thanks for the info. Actually, Paul requested if I can take this particular jira since I already started working on it. The jira was originally assigned to him. Both of you said the same thing that's the reason for the original email. What I forgot to include is a bit of background why I'm requesting such change. Anyway, I hope Dain reads this email Thanks again, chris --- Joe Bohn [EMAIL PROTECTED] wrote: Chris, You need to get Dain to grant you contributor karma by adding you to the geronimo-contributors group in jira. Then you can assign the jira to yourself (assuming Paul agrees). Joe Chris Cardona wrote: Anybody (maybe Dain) here who can help me have G-1860 assigned to me - ccardona? TIA. chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
jars needed to build jetty on m2 are not available
Hi, While building jetty on m2, I get the following error - There is a line saying - [WARNING] While downloading springframework:spring:1.2.5 This artifact has been relocated to org.springframework:spring:1.2.5. The project.xml (m1) still uses springframework as groupId!. How can I get these jars pushed to m2 repo? I also need commons-modeler-1.2-GERONIMO-SNAPSHOT in am m2 repo. When will the openejb jars be updated on m2 repo? Thanks Anita . [INFO] Failed to resolve artifact. Missing: -- 1) javax.activation:activation:jar:1.0.2 Try downloading the file manually from: http://java.sun.com/products/javabeans/glasgow/jaf.html Then, install it using the command: mvn install:install-file -DgroupId=javax.activation -DartifactId=activation \ -Dversion=1.0.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT 2) org.springframework:spring:jar:1.2.5 3) org.springframework:spring-support:jar:1.2.5 4) javax.mail:mail:jar:1.3.2 5) javax.activation:activation:jar:1.0.2 2) javax.transaction:jta:jar:1.0.1B Try downloading the file manually from: http://java.sun.com/products/jta Then, install it using the command: mvn install:install-file -DgroupId=javax.transaction -DartifactId=jta \ -Dversion=1.0.1B -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT 2) org.springframework:spring:jar:1.2.5 3) org.springframework:spring-remoting:jar:1.2.5 4) org.springframework:spring-dao:jar:1.2.5 5) javax.transaction:jta:jar:1.0.1B 3) javax.mail:mail:jar:1.3.2 Try downloading the file manually from: http://java.sun.com/products/javamail/downloads/index.html Then, install it using the command: mvn install:install-file -DgroupId=javax.mail -DartifactId=mail \ -Dversion=1.3.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT 2) org.springframework:spring:jar:1.2.5 3) org.springframework:spring-support:jar:1.2.5 4) javax.mail:mail:jar:1.3.2 4) activecluster:activecluster:jar:1.2-20051115174934 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=activecluster -DartifactId=activecluster \ -Dversion=1.2-20051115174934 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT 2) activecluster:activecluster:jar:1.2-20051115174934 5) javax.resource:connector:jar:1.0 Try downloading the file manually from: http://java.sun.com/j2ee/connector/download.html Then, install it using the command: mvn install:install-file -DgroupId=javax.resource -DartifactId=connector \ -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT 2) org.springframework:spring:jar:1.2.5 3) org.springframework:spring-support:jar:1.2.5 4) javax.resource:connector:jar:1.0 -- 5 required artifacts are missing. for artifact: org.apache.geronimo.modules:geronimo-jetty:jar:1.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), maven2-central (http://repo1.maven.org/maven2), Apache CVS (http://cvs.apache.org/maven-snapshot-repository), maven1-ibiblio (http://www.ibiblio.org/maven), snapshots (http://snapshots.maven.codehaus.org/maven2), apache-cvs (http://cvs.apache.org/repository) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=comments#action_12413546 ] Aaron Mulder commented on GERONIMO-1431: Now if you deploy via hot deploy and undeploy with another tool, the file is deleted from the hot deployer directory. Still need: - if deploy otherwise and copy new version into hot deploy dir, redeploy - GERONIMO-1813 Make deploy tool and hot deploy directory work better together -- Key: GERONIMO-1431 URL: http://issues.apache.org/jira/browse/GERONIMO-1431 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Right now if you deploy something with the deploy tool and then drop an update in the hot deploy directory, it doesn't work. The hot deploy dir expects you to only use the hot dpeloy dir for that module. Likewise, if you deploy something with the hot deploy dir and then undeploy it with the deploy tool, it is not deleted from the hot deploy dir. Both of those can be fixed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
M2 :openejb for geronimo
David J, There are *.pom files in the openejb source. Is it sufficient to replace the groupId 'geronimo' with o.a.g.modules' and create pom.xmls for building openejb locally? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: cwiki.apache.org and Geronimo web site update
Hernan, This is awesome as I for one love to download everything I can get my paws on about a project seemingly before I get on a plane so it looks like the project is finally coming of age in this way. I know you have been cranking out the lion's share of doc here but that there are many folks who also have been contributing. Hat's off to all and thank you. It might be nice to add a link on this page to the library link and describe that there are books and articles from across the globe that can be access here. I for one probably wouldn't immediately go looking for a separate page. Having something to clearly guide users would be really helpful. Using my own incompetence as a measure :) Thanks Matt Hernan Cunico wrote: Hi All, the new cofluence wiki cwiki.apache.org is ready to go live! I have reorganized the documentation, migrated it and updated the new confluence installation, the new structure looks like this: Apache Geronimo v1.0 Apache Geronimo v1.0 - User's Guide Apache Geronimo v1.0 - Developer's Guide Apache Geronimo v1.1 Apache Geronimo v1.1 - User's Guide Apache Geronimo Project Management Apache Geronimo Development Process Apache Geronimo Development Status Apache Geronimo SandBox You can see it LIVE accessing http://geronimo.apache.org/documentation The documents that are still up-to-date from wiki.apache.org/geronimo should be moved over the new confluence wiki, some of those docs should actually go directly into the web site itself. I will work on these changes unless somebody else volunteers :D Part of this update includes reorganizing the web site, the old Libray and Documentation thing. The Documentation link will contain the new structure just decribed (http://geronimo.apache.org/documentation) and the Library link will contain all the available printed and online books, cookbooks, articles, interviews, etc. So, whoever is working on a Geronimo book, articles, etc. and the info is not listed on the web site, pls send the details over so we can update the site. You will have to re-register in the new confluence in order to continue contributing with Geronimo's documentation. Enjoy! Cheers! Hernan
TranQL Converted to SVN
All, For those that are interested TranQL, which is located at CodeHaus, has been converted from CVS to SVN. If you are interested you can checkout the TranQL tree with the following command: svn co https://svn.codehaus.org/tranql We'll be working over the weekend to get this straightened out so we can get to a 1.1 release. Thanks for your patience. Cheers, Matt
Re: Move blocker GERONIMO-1960 to 1.1.1?
I concur with Aaron that including it is reasonable. Aaron Mulder wrote: This may be no surprise, but I think including it is reasonable. :) Thanks, Aaron On 5/26/06, David Jencks [EMAIL PROTECTED] wrote: I think I've lost the thread and level-of-reply info due to having to use the web interface for mail, sorry copying the message I'm replying to... --original message thread... On May 24, 2006, at 12:47 PM, Dain Sundstrom wrote: On May 23, 2006, at 11:26 PM, David Jencks wrote: On May 23, 2006, at 11:04 PM, David Jencks wrote: +1 on excluding this from 1.1. I agree it's not a blocker. I think client-corba needs a dependency on client-security, I thought it was there. I'll try to investigate on the plane tomorrow. I expected you to fix this by modifying the ServiceConfigBuilder to check that the gbean reference was satisfied in the ancestor set when it is reading the xml. This is what the other builders do for e.g. resource-refs, and I think it would be simple and non-invasive. However, in any case I don't think this is a blocker the worst that can happen is that you get an error later rather than sooner, you get essentially the same effect either way. Umm, re this comment, I should think before writing :-) A moment's further thought reminded me that the reason we can check e.g. resource-refs when we process them is that we have a multistep process in the j2ee module builders and when we resolve the references we already know all the gbeans. This is not the case for service modules so the verify method you added or some other way of introducing 2 steps would be necessary. Bingo! It took me a few tries to get this patch right. My first attempt worked just as you suggested above (verify as reading the xml), and I ran into the problem where beans were referring to stuff further down in the file. My second attempt was to modify the ServiceConfigBuilder to verify after all beans had been added, but I ran into the problem where beans were referring to stuff in modules that hadn't been processed yet. My final attempt was to put the verify method in DeploymentContext and set it to verify when we call getConfigurationData(). Since this method is only called when the deployment is complete, all gbeans should be available. The patch does appear to work, but complexity of writing it made me nervous about putting it into 1.1. -my reply Ok... so I spent most of my plane ride to Florida working on getting MagicGBall working again. The plans your verifier flagged were indeed very faulty. This makes me somewhat positive towards including this in 1.1. Anyone else think including it is reasonable? thanks david jencks -dain
Re: M2 :openejb for geronimo
It will be worth checking that Windows builds (especially in the assemblies) still work with the longer groupId due to the longer path lengths that will be generated. John anita kulshreshtha wrote: David J, There are *.pom files in the openejb source. Is it sufficient to replace the groupId 'geronimo' with o.a.g.modules' and create pom.xmls for building openejb locally? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Update on OpenEJB incubation?
In Februrary 2006 the incubation of OpenEJB was discussed on the incubation mailing list. Does anyone have any updates on the progress of the preparation for entering the incubator as OpenEJB coming to Apache has been mentioned in recent mails and I haven't heard anything for a while. OpenEJB is such an integral part of Geronimo, so I think it is worth discussing on this list to keep the Geronimo community informed of the OpenEJB/Geronimo relationship in future Geronimo releases. Thanks, John
Re: Help assigning GERONIMO-1860
Dain, I have some degree of JIRA admin access but could not see where I could do this. Do I need extra privileges? John Chris Cardona wrote: Joe, Thanks for the info. Actually, Paul requested if I can take this particular jira since I already started working on it. The jira was originally assigned to him. Both of you said the same thing that's the reason for the original email. What I forgot to include is a bit of background why I'm requesting such change. Anyway, I hope Dain reads this email… Thanks again, chris --- Joe Bohn [EMAIL PROTECTED] wrote: Chris, You need to get Dain to grant you contributor karma by adding you to the geronimo-contributors group in jira. Then you can assign the jira to yourself (assuming Paul agrees). Joe Chris Cardona wrote: Anybody (maybe Dain) here who can help me have G-1860 assigned to me - ‘ccardona’? TIA. chris __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
