xbean 3.0.1
Geronimo 2.0.1 is using XBean 3.0.1 versions of xbean-naming and xbean-finder and 3.1 version of xbean-reflect. Anybody recall why we're not using 3.1 versions of all xbean artifacts? If I knew, I've forgotten... ;-) --kevan
Re: xbean scm messages
On Sep 7, 2007, at 10:15 AM, Alan D. Cabrera wrote: Your email is not registered on that list. It was waiting on the moderator queue and I have just released it. Thanks. I'm still confused... ;-) Is there a unique SCM list for XBean? I'm guessing that there must be... I don't see David Blevins' recent commit either. In fact, I'm not finding any XBean commits since it was at Codehaus... :-( The XBean Subproject web site says that the XBean SCM list is [EMAIL PROTECTED] I just tried a subscribe to xbean- [EMAIL PROTECTED] That seems to be working (at least ezmlm isn't complaining...) Is that the correct SCM mailing list? --kevan
Re: xbean scm messages
On Sep 7, 2007, at 10:15 AM, Alan D. Cabrera wrote: Your email is not registered on that list. It was waiting on the moderator queue and I have just released it. OK. I found the archive for xbean-scm (http://mail- archives.apache.org/mod_mbox/geronimo-xbean-scm/). I've updated http://cwiki.apache.org/confluence/display/XB/Lists to reflect the proper scm list... --kevan
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0
On Sep 7, 2007, at 12:54 PM, Vamsavardhana Reddy wrote: Does it mean we will need to spin a new RC? We can't release the binaries in their current state. So, yes. --kevan Vamsi On 9/7/07, Kevan Miller [EMAIL PROTECTED] wrote: Hey Tim, Apologies for my slow review of the Eclipse plugin. Reviewing the binary distribution, it looks like we are missing license and notice information for xpp3. There may be a few more notices missing, also. With your permission, I'll make updates to the license and notice files in branches/2.0.0... --kevan
[DISCUSS] Release Geronimo Eclipse Plugin 2.0.0
Hey Tim, Apologies for my slow review of the Eclipse plugin. Reviewing the binary distribution, it looks like we are missing license and notice information for xpp3. There may be a few more notices missing, also. With your permission, I'll make updates to the license and notice files in branches/2.0.0... --kevan
Re: Questions about geronimo-plugin.xml content
On Sep 6, 2007, at 5:31 PM, David Jencks wrote:
On Sep 6, 2007, at 10:42 AM, Kevan Miller wrote:
On Sep 6, 2007, at 12:52 PM, David Jencks wrote:
I think we should start using the maven-remote-resources-
plugin. I will get to it eventually for sufficiently distant
values of eventually...
:-) I would love to have license and notice file generation to be
automated. I have my doubts that it will work for a project with
as many diverse dependencies as Geronimo. The example you provide
below indicates that m-r-r-p (or the available maven meta-data
descriptions) is not ready, yet -- note the multiple occurrences
of ... developed by $project.organization.name
($project.organization.url).
saying including problems that haven't been overridden yet was
supposed to imply that these are fixable through additional
configuration so you wouldn't say that :-) I'm not sure where
these particular ${}'s came from since when I converted apacheds to
use the m-r-r-p I thought I got rid of all of them.
My understanding which could be quite wrong is that any aggregate
we ship is licensed under the asl2 only no matter what's in it
and that this may limit what we can include in an aggregate work.
Our aggregate is not licensed solely under ASL V2. Far from it...
We develop source code which is, almost entirely, ASL v2 licensed.
However, our aggregate contains artifacts that are covered my
multiple licenses. These licenses are acceptable for use within
an Apache product (as determined by our PMC).
I don't think Apache DS has done a very good job of indicating the
licenses that apply to their aggregate (at least in their noarch
distribution it's terrible). Looking at 1.5.1 unstable binary (i
couldn't find a stable binary), the apacheds-noarch/target/
apacheds-noarch-installer-1.5.1-app.jar contains the following
license files:
ASL V2
Spring
SL4J
jzlib
JDBM (LICENSE.txt in a separate format from the other license files)
I don't understand this so I'll stop talking about it. I'm not
sure the m-r-r-p will be useful for assemblies but I think it will
work fine for jars and cars.
Heh.
I think you are probably right about jars and cars.
--kevan
[DISCUSS] Default server log level
The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 1:43 PM, Paul McMahan wrote: On Sep 11, 2007, at 1:27 PM, Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near- term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Right now users can add -v or -vv to the command line to control the logging level. How would this proposal affect those command line flags? -v and -vv only impact CONSOLE logging, not log FILE logging. That could be changed, I guess... IMO, a threshold setting of ERROR for CONSOLE is good. I'd prefer to see the FILE threshold set to INFO. --kevan
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 5:05 PM, Jason Dillon wrote: Are you refering to console output or what is captured in the log file? Heh. Come on, read my mind... :-P I'm referring to the log FILE. I'm fine with our current CONSOLE behavior... --kevan
Re: removal of spring dependencies from cxf module
On Sep 11, 2007, at 5:37 PM, Jarek Gawor wrote: I think we have an acceptable solution for this whole CXF/Spring issue. First, CXF will continue to be configured with Spring as before. Second, all web applications will now get an automatic hidden-classes filtering for Spring classes and resources. That should enable applications to have their own versions of Spring and reduce conflicts with Geronimo's version. The key to this solution was ensuring that CXF was initialized/configured with the CXF module classloader and not the application classloader. If the application classloader was used, and it had Spring filtering enabled, the Spring configuration files were filtered away. That caused incomplete configuration of CXF and failures later on. When CXF module classloader is used, the right Spring configuration files are discovered and things work nicely. Of course, now if the application has its own CXF configuration files they will be ignored. So this solution is not perfect but hopefully should be good enough for 2.0.2. I committed the changes to trunk and branches/2.0 if people want to review. Cool. Thanks Jarek! I think this will fix the Spring problems, we've seen to date with Jetty/CXF. There are still some things we can do, in addition to this: 1) Create a separate Spring module. The CXF module would be dependent upon this module. Other system modules could also be dependent upon this Spring module. Optionally, client applications could have a dependency on this module. 2) Currently, our ClassLoaders can only filter classes from their parents. Would be cleaner if we allowed the CXF module to filter Spring classes from its children. 3) Would be good to upgrade our Spring version. There used to be a problem with 2.0.5+ versions of Spring and XBean. I think I've fixed that in XBean. Possible that CXF has an issue with newer versions of Spring. --kevan
Re: [DISCUSS] Move J2G from sandbox to devtools
On Sep 12, 2007, at 10:21 AM, Donald Woods wrote: Given all of the work and interest in the J2G tool, I would like to move the current J2G files from sandbox/j2g to devtools/trunk/j2g, so we can start working towards an official release of the tool. Does this require a Vote first or does the CTR process apply here, as the code is already in our svn repo? No vote is required. Discuss it (like you are doing) and barring objections, do it... My 2 cents -- I agree that it is a good thing to do... --kevan
Re: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
On Sep 12, 2007, at 7:44 AM, Jacek Laskowski wrote: On 9/8/07, Paul McMahan [EMAIL PROTECTED] wrote: I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a patchset with this annotation support. See http://tinyurl.com/2enw25 How can we work it around? Shall we put Tomcat codebase into our repo and maintain ourselves or start the G-T integration over with the newest trunk bits? Well, we already use a patched version of Tomcat and distribute the binary in our repository dir. There was discussion about releasing a suitably named binary (rather than maintaining in our svn tree). Don't think that anyone has tackled this, yet. Continuing on this patch should give the Tomcat community time to make amends... --kevan
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Sep 13, 2007, at 3:17 AM, Jason Dillon wrote: I'm converting all of the assemblies tonight, should be done in another hour or so. But, currently server/trunk is not building due to: snip [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/server/ modules/geronimo-openejb/target/classes [INFO] -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.TransactionServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.SecurityServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo /snip So, I can't verify that everything is super happy... I've deployed a new version of OpenEJB 3.0 snapshots. So, verify away... :-) You may need to delete old versions of OpenEJB snapshots from your maven repo (depending on when you built last...). --kevan
Re: svn commit: r574770 - in /geronimo/devtools/eclipse-plugin/branches/2.0.0: ./ plugins/org.apache.geronimo.deployment.model.edit/ plugins/org.apache.geronimo.deployment.model/ plugins/org.apache.ge
On Sep 13, 2007, at 5:39 PM, Kevan Miller wrote: On Sep 13, 2007, at 4:44 PM, Lin Sun wrote: I think we also need to update the license in the feature.properties file for each of the feature we provide. Right now, I only saw ASL 2.0 there. The license in the feature.properties file is presented to a user when they install the Geronimo Eclipse plugin or server runtime using the Eclipse update manager, before he/she clicks on accept the license to install our Geronimo eclipse plugin or server runtime. It may make sense to put the contents of both the license and notice file there. Ah, ok. That makes sense. I didn't know what the feature.properties files were used for (just saw that they didn't have any non ASL/ Geronimo artifacts). Thanks for reviewing! Lin or Tim, Is that something that one of you can take care of? --kevan
Re: [Discuss] What next?
Apologies for such a late response. This thread came out while I was on vacation and got buried by a lot of other things... This is a good list. Comments, below. On Aug 30, 2007, at 8:12 PM, David Jencks wrote: Getting 2.0.1 out the door was a great step and now might be a good time to start discussing where we want geronimo to head next. Here are some ideas I've had or think are important. If I were to try to write actual sentences about all of this I'd probably never send the email so this is way too fragmentary but maybe can spark more discussion. I'm hoping everyone will chime in with their interests and viewpoints, this is just what I've been thinking about lately. Modularity. For a long time we've been on the brink of having an actually modular server, not just a conceptually modular server. As reflected in a lot of recent discussion on the dev list, I think we are so close we should really work hard to make this a pleasant reality. Some of the steps I see: - enhance the plugin framework so bits of more config files can be added, in particular artifact_aliases.properties and config_substitutions.properties. IIUC Paul has some schema changes and xml handling rewrites in the wings as well - finish up the pluggable admin console work and actually split the admin console into appropriate bits for the plugins - rearrange the build so it is organized by plugin - actually assemble the servers we ship using plugins, perhaps using gshell scripts - have more server-building tools. For instance, a button to push that spits out a server with just what is needed for a set of apps and nothing else. I wouldn't go so far as saying G is a conceptually modular server, but would agree that the modularity can be a lot more user-friendly. And would like to see us building our server assemblies from plugin parts. Sounds like you've been making some good progress on this path. One caveat -- I would not want our Java EE servers (or other assembly flavors) to become harder to use. One concern I have is ending up with a bunch of differently versioned server plugins that we have a hard time managing... I'd really like us to keep a critical eye on ease-of-use... Clustering IIUC we have a lot of partial clustering solutions. For instance there's WADI, native tomcat clustering, a terracotta integration, and IIUC Jeff has been working on a clustering solution (my apologies if I left any out). I'd like to know where these efforts are in terms of actual functionality and reliability and what they can be extended to do. We also need some kind of cluster admin tools. Security jaspi triplesec administration beyond javaee security for jetspeed and roller There are some good things about javaee security such as the idea of using Permissions and evaluating them in a policy but there are also a lot of limitations and problems such as no support for restricting access to user generated content that didn't exist when the security was originally configured. At least roller and jetspeed have run into this problem. I think triplesec may provide a fairly generic solution and it might be interesting to see if other projects are interested in this. Other apps roller jetspeed proximity etc It would be great to get all popular apps available as geronimo plugins. Management and troubleshooting ARM trace on error facility. Have a list of info that each component can add to as the request moves through the system. If there's an error, we can show the entire path taken with all data. Otherwise we discared it. server farm management (gshell?) As Jason D has mentioned (and I really, really agree with him), we need to address logging. We need to create a logging policy and need to start addressing this in a consistent and rigorous manner... Transaction manager implement a do work in a new tx interface, hook it up to openjpa. IIUC IBM has proposed an interface that lets server pieces submit work to be done in a new transaction, thus eliminating the need to deal with suspend etc yourself. There's been some discussion on the openjpa lists, and we should definitely do this. There may be more commonj work to do also, but I've more or less lost track of that project. make sure recovery actually works Core Better Spring application management I think our basic issues have been resolved... But there are some follow on improvements that should be implemented hidden-classes for children, a separate Spring module, etc. Investigate OSGI and figure out how it is different from what we are doing, what it can do better, and what is missing from it. Figure out an integration strategy whether it be run OSGI as an application or replace the kernel with OSGI Don't break stuff if we start using OSGI more :-) I have yet to see what I'd call a compelling argument for moving our kernel to an OSGI base. I can
Re: Problem with referencing to beans from other ejb-jars
I thought I'd take the opportunity to send some love David B's way...
I think it's great the way he's been addressing these user questions
and documenting in the Wiki.
I hope we can get this stuff organized so that users can find this
information in a reasonable manner...
--kevan
On Sep 13, 2007, at 3:54 PM, David Blevins wrote:
Hi Tomasz,
I created a doc for you that describes the missing parts.
http://cwiki.apache.org/OPENEJB/ejb-refs.html
Keep what you have with the openejb-jar and add the parts described
in this to your ejb-jar.xml.
Unfortunately, while looking into this I discovered that our code
for overriding an @EJB annotation with an ejb-ref in the xml is
not implemented, thus if you have @EJB and the corresponding ejb-
ref as described in the first section of the document, you'll end
up with two refs and not one as you should.
We'll get this fixed asap, but until then follow the technique
described in the second part of the doc and in the next version of
Geronimo you'll be able to delete some of that xml and readd the
@EJB annotation.
-David
On Sep 13, 2007, at 6:58 AM, Tomasz Mazan wrote:
Hello
I got deployed module A (JAR) and application B (EAR).
A) Contains stateless bean
@Stateless(name = JmsDispatcherGate)
public class JmsDispatcherGateImpl implements DispatcherGateLocal,
DispatcherGateRemote {
and - of course - necessary interfaces.
ejb-jar.xml does'nt contain interesting content,
openejb-jar.xml contains module description
sys:moduleId
sys:groupIdmyejbmodule/sys:groupId
sys:artifactIdDispatcher/sys:artifactId
sys:version1.0/sys:version
sys:typejar/sys:type
/sys:moduleId
B) Application contains two ejb-jars with beans
geronimo-application.xml contains
dependencies
dependency
groupIdmyejbmodule/groupId
artifactIdDispatcher/artifactId
version1.0/version
typejar/type
/dependency
/dependencies
and one of B-module has openejb-jar.xml with similar dependencie's
definition.
Bean in B-module references to bean from A (EJB) using code below:
@EJB(name = JmsDispatcherGate)
private DispatcherGateLocal dispatcherGate;
Problem occurs on deploying B-application (EAR) while A (EJB) is
correctly
deployed and Geronimo Console JNDI Viewer show JmsDispatcherGate
bean. I
tried to use Remote interface - with no special difference.
Exception stacktrace:
15:31:18,812 FATAL [startup] Cannot find bean JmsDispatcherGate
referenced
by bean CoreManagerLocal.
15:31:18,812 ERROR [Deployer] Deployment failed due to
org.apache.geronimo.common.DeploymentException:
org.apache.openejb.OpenEJBException: Cannot find bean
JmsDispatcherGate
referenced by bean CoreManagerLocal.
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbJarInfo
(EjbModuleBuilder.java:530)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext
(EjbModuleBuilder.java:437)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder$
$FastClassByCGLIB$$cd80af20.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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$
$dc485bed.initContext(generated)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfigurati
on(EARConfigBuilder.java:576)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder$
$FastClassByCGLIB$$38e56ec6.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.j2ee.deployment.CorbaGBeanNameSource$
$EnhancerByCGLIB$$1375d602.buildConfiguration(generated)
at
[DISCUSS] G 2.0.2 Release plan
All, I think it's time to start rolling out a 2.0.2 release. There have been a number of fixes in response to user issues, since 2.0.1. Time, I think, to make these available in a release. We'd also be able to make use of released versions of OpenJPA, Axis2, and hopefully OpenEjb, whittling away at our local builds... I think we have one must-fix problem that is outstanding -- the MEJB security issue. Assuming we resolve this problem, are there any other issues which must be resolved prior to a 2.0.2 release? Assuming we're in general agreement, I'd set a goal of creating a release candidate by next Friday (Sept 21). I'm volunteering to be the release manager. Thoughts? --kevan
Re: svn commit: r574770 - in /geronimo/devtools/eclipse-plugin/branches/2.0.0:
On Sep 14, 2007, at 10:48 AM, Tim McConnell wrote: Hi Lin/Kevan, do you all feel this change is a show-stopped for RC2 ?? If so, I'll cancel the vote and start another one for RC3. Please advise. Thanks. Hey Tim, From a binary perspective, things are fine. However, if the installation of the plugin is presenting LICENSE information that we purport to represent the license information for the plugin, and that information is incorrect. Then, yes, I think it needs to be fixed. --kevan
Re: svn commit: r574694 - in /geronimo/server/trunk: configs/jetty6-deployer/src/main/plan/ configs/jetty6-deployer/src/plan/ configs/tomcat6-deployer/src/main/plan/ configs/tomcat6-deployer/src/plan/
On Sep 14, 2007, at 2:56 PM, Jarek Gawor wrote: Ugh... I had a feeling that this filtering will cause problems for someone. Anyway, in general I think moving the hidden-classes filter to the CXF deployer is a better solution (to keep it all together and assuming it has the same effect as when specified in the web container deployer). But, in this case I don't think this will work right still. First, in CXF there are two key deployers. One that handles deployment of web services and another one that handles service references (it's a naming builder). Both will need the hidden-classes filter (the patch only updates the web service deployer). However, because the way currently the naming builders work in Geronimo, the environment of naming builders is always merged no matter if the application has a service reference or not (or whatever the naming builder is looking for). So at the end, even if we moved the hidden-classes filter to the CXF deployers, the filter will still be injected. So we might need to fix how the naming builders work or find a better way to deal with Spring filtering. I'm not sure what's the right solution here. Heh. Well, I had hopes for Paul's proposal... Sounds like it's still better than where we are now... I think the right way to address the problem is at the CXF module, itself (which we've talked about on other threads). Basic idea is that the CXF module would declare the classes that it will hide from classloader children. You'd specify something like: child-hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /child-hidden-classes The CXF module classloader would hide these classes/resources from child classloaders. We could also consider separating hidden- classes and hidden-resources... Other final (?) thing to consider is creating a Spring module. Both cxf and pluto-support could depend on this new module... --kevan
Re: What exactly is going into 2.0.2?
I'm moving this to the '[DISCUSS] G 2.0.2 Release Plan' mail thread. --kevan
Re: What exactly is going into 2.0.2?
On 9/17/07, Paul McMahan [EMAIL PROTECTED] wrote: snip Joe, you mentioned TCK and our ability to make 2.0.2 available by 9/21. I have a question for the team about that. I would like to bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new release contains several bug fixes, some of them actually found and reported by Geronimo users. But doing that could affect Geronimo's TCK results and affect the 9/21 delivery date. I would imagine that the same is true for other dependencies.Are we OK with picking up maintenance releases of Geronimo dependencies in 2.0.2 even if we think TCK issues could slow us down? Or should we keep 2.0.2 focused on localized changes and only bump the dependency versions in Geronimo 2.1 so we have more time to deal any resulting TCK issues? In general, I think it's fine to bump dependencies to a later version. Especially, if there are bug fixes we know about. We're also motivated to pick up released versions of projects which we're currently carrying -r* builds in our svn repository... --kevan
Re: What exactly is going into 2.0.2?
On 9/17/07, David Jencks [EMAIL PROTECTED] wrote: Speaking of versions I think we should go to openjpa 1.0.0 the trunk build has been broken for a bit since the -r* snapshot openejb was using seems to have disappeared. Hmm. A while back, I moved branches/2.0 and trunk to OpenJPA 1.0.0-SNAPSHOT and deleted the private builds from our repo (or at least thought i did). I moved the version to 1.0.0 earlier today. I confess that I didn't build trunk. But I did build branches/2.0 without a problem. I'm reinstalling the OS on my dev machine. So, I can't really check on this, ATM. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
Moved from another mail thread... On 9/17/07, David Jencks [EMAIL PROTECTED] wrote: I'm starting to wonder what the goal for 2.0.2 is. I kinda thought that a x.y.z where z 0 was a bugfix-only release of x.y.z-1 but I think some new features are going into 2.0.2... IIUC Vamsi is applying an enhancement to allow specifying work directory per-web- app and donald is encouraging me to apply my proposal to GERONIMO-2925 to the branch. Though small these are definitely new features. The goal of 2.0.2 is to get fixes into user's hands. In general, I agree with you. 2.0.x releases are bug-fix releases. You're raising two questions: 1) what is a bug fix? and 2) how dogmatic do we want to be in our bug-fix release management? Regarding 1), I think we'd agree that there isn't necessarily an objective measure for determining what is or isn't a bug fix. Re: 2), we could be pretty conservative on our interpretation of bug fix or we can be a bit more permissive on what we interpret as a bug fix. Personally, I probably fall into a more permissive side of that decision (at least at this point in time of our 2.x lifetime -- I expect I'll have a different answer when 2.4 rolls around...). In the meantime, if users are encountering issues or experiencing pain because of missing features (perhaps features that were overlooked), then I'm not averse to alleviating this pain in a 2.0.x release. More important metric, IMO, is are we helping our users? I haven't looked closely at either of the issues that you highlight. If you'd like me to, I'll evaluate and give my opinion with a release manager hat on -- barring objections...) Personally I would prefer to minimize such feature creep and have more focus on getting 2.1 out in a less than geological time frame, in particular before apachecon atlanta. I haven't seen a discussion or proposal for a 2.1 release. So, it's hard for me to evaluate if ApacheCon is a reasonable date for 2.1. I don't think that a 2.1 schedule is, by itself, a reason to not do work in 2.0.x -- especially at this point. When we have a target 2.1 release date and are getting closer to that date, then I'm sure I'd feel differently... --kevan
Re: [VOTE] Release Geronimo Eclipse Plugin 2.0.0 (RC3)
I have not tested, but source and binaries look good... +1 --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 20, 2007, at 8:38 AM, Donald Woods wrote: Also, the changes in txmanager aren't enough to warrant another components release. The txmanager change was only to fix a misspelling in an exception message... Ya. However, there was a Transaction Recovery jira opened. I'm going to have a quick look. We may have dropped a fix between M6 and 2.0... I see that Anita has attached some patches for the MEJB problem. We need to get some eyes on these... Finally, we need to get some TCK issues cleaned up. We have some EJB- related issues to resolve... Oh. One more thing... OpenEJB is nearing a 3.0 beta release. We have a choice of creating a new private build of OpenEJB. Or lining up with their Beta release. I'd rather grab their beta release. However, if they have a significant delay, will need to reconsider... --kevan
Re: automatic builds with tests
On Sep 20, 2007, at 10:50 AM, Prasad Kashyap wrote: Right. We have talked about this before and the majority opinion was to have a separate subject line. I have a gmail reader, but then again it's not about how I want it. I'll gladly put whatever the majority of the community decides. Start a [VOTE] thread :-)) Just checking... If others are happy with the way things are, I can deal... --kevan
Re: OSGifying org.apache.geronimo.specs
On Sep 21, 2007, at 9:08 AM, Guillaume Nodet wrote: I guess given that no framework support it and that nobody uses this jar yet, I will just defer ;-) Many thanks for this explanation. There isn't a current release of the commonj spec. We only released commonj when we released all specs at once. I'm not aware of any commonj dependencies. We probably should just move it to sandbox, until somebody is interested in it... --kevan
Re: What exactly is going into 2.0.2?
On Sep 21, 2007, at 10:48 AM, Paul McMahan wrote: On Sep 21, 2007, at 10:43 AM, Vamsavardhana Reddy wrote: Will we have a released version of MyFaces 1.2.1? I believe we do not want to include any SNAPSHOT versions as dependencies in our releases. We can request a release when it is passing TCK. Getting it into a Geronimo build is a first step towards running TCK on it and fixing any problems. We work very closely with the MyFaces team on this process, similar to OpenEJB, Axis, CXF, etc. Sounds reasonable. You'll probably have an easier time running on branches/2.0, however. Suggest you make a local modification to the myfaces dependency (without committing) and run some tests... --kevan
Re: svn commit: r578231 - /geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.0.1/
On Sep 21, 2007, at 3:18 PM, Vamsavardhana Reddy wrote: Kevan, This should be created from rev 563889. I had one commit to the branch in rev 577161 (just correcting a typo) post what was used in 2.0.1. Though I had sent an e-mail earlier to the dev-list about creating this tag I forgot to follow it up :o( Thanks. I deleted my tag and created a new one from 563889. --kevan
LinuxWorld Open Solutions Conference 2007 in Tokyo
All, I'm going to be giving a Geronimo talk at the LinuxWorld Open Solutions Conference, in Tokyo on Thursday of this week. The talk is from 11:00-11:45. Here are the conference details -- http://www.idg.co.jp/expo/lwe/index.html --kevan
Re: MEJB Question
On Sep 24, 2007, at 3:03 PM, David Jencks wrote: On Sep 20, 2007, at 8:56 AM, Anita Kulshreshtha wrote: I am leaning towards deploying MEJB as an EJBModule. To auto deploy this I will be adding an mejb config. Are there any objections? no :-) I've been wondering if we should try to separate mejb security from other security somehow and thought perhaps we should use a GeronimoGroupPrincipal named mejb or mejb-admin. I think this would make it easier to e.g. give someone access to the web console but not the mejb or vice-versa. If we wanted to be even fancier we could try mejb-read and mejb-write. Would this improve modularity or just create more difficult configuration? I'm not sure about improving modularity, but it seems useful. I'd definitely advocate an mejb-specific group. Separation of read/write selectivity seems less important and, I would assume, harder to do... --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 8:51 AM, David Jencks wrote: I've committed to branches/2.0 also. Thanks David! I think this leaves us with: * integration of the MEJB code itself * release of OpenEJB 3.0-Beta One thing I've noticed -- the default JNDI name for EJB's has been changed in OpenEJB. So, there is a compatibility issue with 2.0.1. We might be able to configure how OpenEJB generates this default to maintain backward compatibility. Better, IMO, to go ahead and match OpenEJB's behavior. --kevan
Re: svn commit: r577890 - in /geronimo/server: branches/2.0/modules/geronimo-deployment/src/main/java/org/apache/geronimo/deployment/xmlbeans/ branches/2.0/modules/geronimo-j2ee-schema/src/test/resour
On Sep 25, 2007, at 12:38 PM, Jarek Gawor wrote: Vamsi, In general I think we agree on how things should be handled when schema changes. Also, the patch I looked at had schema changes made in the existing .xsd files and I assumed that the new files would be introduced in trunk only. But since nobody else has an issue with that change, that's fine. We just have to remember to publish the new schemas on the website and (eventually) update the eclipse plugin. Several people have expressed their concerns about this change. I must confess that I'm not entirely comfortable with the change either. I don't think there's a black and white answer. Obviously, Vamsi would prefer that the change go into 2.0.2. We could always retag 2.0.2 and call it 2.1. However, that doesn't feel right either. I'd thought about the required documentation changes, but don't really know how to evaluate the plugin impacts. I'd like to hear about this from an eclipse plugin perspective... I think Vamsi has done a commendable job of communicating with the community (one minor quibble: don't use Jira as a group communication mechanism. Not all people read Jira comments as actively as they read the dev list). Even with this communication, it's quite reasonable for Jarek or anyone to express their concerns about a commit. He, or any other project member, can do this *at any time*. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 6:40 PM, David Blevins wrote:
On Sep 25, 2007, at 7:38 AM, Kevan Miller wrote:
One thing I've noticed -- the default JNDI name for EJB's has been
changed in OpenEJB. So, there is a compatibility issue with 2.0.1.
We might be able to configure how OpenEJB generates this default
to maintain backward compatibility. Better, IMO, to go ahead and
match OpenEJB's behavior.
There are no compatibility issues as it was explicitly set in
Geronimo 2.0.1 to be essentially {moduleId}/{ejbName}/
{interfaceClass} (actually it's {deploymentId}/{interfaceClass}
and deploymentId will be {moduleId}/{ejbName}). It'll still be the
same in Geronimo 2.0.2, just now it can be changed to something
shorter.
Well, that's encouraging. However, something has changed between
2.0.1 and 2.0.2. Can you help explain the following?
INFO log during 2.0.1 deploy:
18:45:13,785 INFO [config] Configuring app: GeneralEJB.jar
18:45:13,849 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My, container-id=null)
18:45:14,066 INFO [config] Loaded Module: GeneralEJB.jar
18:45:16,653 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase class
load times significantly.
18:45:17,021 INFO [startup] Assembling app: /geronimo-jetty6-
jee5-2.0.1/var/temp/geronimo-deploymentUtil24358.jar
18:45:17,375 INFO [startup] Jndi(name=GeneralEJB.jar/My/ejbs.My)
18:45:17,375 INFO [startup] Created Ejb(deployment-id=GeneralEJB.jar/
My, ejb-name=My, container=Default Stateless Container)
INFO log during 2.0.2-SNAPSHOT deploy:
18:52:08,701 INFO [config] Configuring app: sibc/ejb/7.0.0/ear
18:52:08,936 INFO [OpenEJB] Auto-deploying ejb My: EjbDeployment
(deployment-id=GeneralEJB.jar/My)
18:52:09,281 INFO [config] Loaded Module: sibc/ejb/7.0.0/ear
18:52:11,467 INFO [Enhance] You have enabled runtime enhancement,
but have not specified the set of persistent classes. OpenJPA must
look for metadata for every loaded class, which might increase class
load times significantly.
18:52:11,977 INFO [startup] Assembling app: /Users/kevan/geronimo/
server/branches/2.0/target/geronimo-jetty6-jee5-2.0.2-SNAPSHOT/var/
temp/geronimo-deploymentUtil14898.jar
18:52:12,440 INFO [startup] Jndi(name=GeneralEJB.jar/My/ejbs.MyHome)
-- Ejb(deployment-id=GeneralEJB.jar/My)
18:52:12,447 INFO [startup] Created Ejb(deployment-id=GeneralEJB.jar/
My, ejb-name=My, container=Default Stateless Container)
Note the different JNDI names...
--kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 25, 2007, at 4:08 PM, Donald Woods wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 Donald, Thanks a bunch for going through all of those Jiras! David Blevins, Are we missing 3423 in branches/2.0? --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Sep 26, 2007, at 7:30 PM, Kevan Miller wrote: On Sep 25, 2007, at 4:08 PM, Donald Woods wrote: OK, I'm done updating the 2.0.x closed issues (sorry for all the JIRA emails.) The only one I couldn't figure out, was: https://issues.apache.org/jira/browse/GERONIMO-3423 Donald, Thanks a bunch for going through all of those Jiras! David Blevins, Are we missing 3423 in branches/2.0? Heh. Looks like I merged the change to branches/2.0 in revision 570950 -- http://svn.apache.org/viewvc?view=revrevision=570950. --kevan
Re: Distributing AspectJ JARs - License
On Oct 3, 2007, at 10:07 AM, Gianny Damour wrote: Hi Matt, Yes: I would like to add this dependency from the Eclipse Foundation to a config so that it gets included in the assemblies: dependency groupIdaspectj/groupId artifactIdaspectjrt/artifactId version1.5.2a/version /dependency My understanding is that the AspectJ tools are provided under the Eclipse Public License Version 1.0 license: http:// www.eclipse.org/legal/epl-v10.html At this stage, I would like to simply change the licensing files of the config: * mofify the NOTICE.txt to include a one liner pointing to the EPL; and * add a LICENSE-EPL-V10.txt, which is a CC of http:// www.eclipse.org/legal/epl-v10.html. However, I am not sure that we can include AspectJ jars in the assemblies. Hi Gianny, It's fine to include EPL-licensed binaries. EPL-licensed source code would be a problem, however. FYI -- an overview of OS licenses and categorization with regard to Apache projects can be found here -- http://people.apache.org/~rubys/3party.html I would prefer that you not create a separate LICENSE-EPL file. We currently aggregate all license information in our LICENSE.txt file. I'd prefer that we maintain this practice until we change our handling for all 3rd party licenses. The NOTICE file needs to inform users how to obtain aspectj source code (this is a provision of the EPL). Typically this is accomplished with a url to the project web site. Although the geronimo-wadi module would conceptually contain the EPL-licensed artifact, it's actually the assembly that contains the artifact. So, updating the license/notice files in the configs/ geronimo-wadi directory would not be appropriate. Instead, you need to update trunk/LICENSE.txt (and NOTICE.txt) as well as trunk/ assemblies/geronimo-boilerplate-minimal/src/main/underlay/LICENSE.txt (and NOTICE.txt). --kevan
Re: [VOTE] Release XBean 3.2
The sources jars (e.g. http://people.apache.org/~gnodet/xbean-3.2/org/ apache/xbean/xbean-classloader/3.2/xbean-classloader-3.2-sources.jar) are missing LICENSE and NOTICE files. The xbean-reflect pom (http://svn.apache.org/repos/asf/geronimo/xbean/ tags/xbean-3.2/xbean-reflect/pom.xml) is missing an apache source header. xbean-spring/src/main/resources/org/apache/xbean/spring/spring- beans.xsd does not have an apache source header, either. Not clear that it should... Was that file copied from Spring (should there be a Spring attribution?) or was it created by xbean? Other than the above, everything else looks good. --kevan
Re: Distributing AspectJ JARs - License
On Oct 3, 2007, at 2:38 PM, Donald Woods wrote: We aren't pulling WADI into the Tomcat assemblies yet, so only the Jetty assemblies need the update, right? Technically correct. However, we aren't that granular at the moment. We currently don't differentiate between tomcat/jetty, minimal/full java ee servers in our license/notice files. Clearly we could be more targeted... --kevan
Re: Branches/2.0 24 hour branch notice for 2.0.2 release processing
On Oct 5, 2007, at 10:02 AM, Matt Hogstrom wrote: I think Kevan was going to do this yesterday but in his sleep deprived state from Globe trotting he may still be snoozing. I'll let him whack me on the head if my notice is inconsistent with his desire as release manager. We'll create the 2.0.2 branch on Saturday, October 5th around 1000 ET. :) Thanks Hogstrom... --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Oct 5, 2007, at 8:42 AM, Donald Woods wrote: What's the plan for creating a 2.0.2 branch in preparation of closing down the release? Matt sent a note earlier today, while I was in a jet-lagged impose slumber... I'll plan on creating a branches/2.0.2 for finalizing release activity on Saturday morning... --kevan
Re: [VOTE] Release XBean 3.2
On Oct 5, 2007, at 2:55 PM, Guillaume Nodet wrote: I have finally uploaded a new release condidate. Please review. I have only modified the root pom to make sure the jars include the needed files. Great. Thanks Guillaume. +1 --kevan
Re: svn commit: r578812 - /geronimo/server/trunk/configs/jetty6/src/main/plan/plan.xml
On Oct 3, 2007, at 4:34 AM, Vamsavardhana Reddy wrote:
I am surprised that the ServerInfo reference is not there in the
file because http://svn.apache.org/viewvc/geronimo/server/trunk/
configs/jetty6/src/plan/plan.xml?r1=577801r2=577800pathrev=577801
shows that it is there in the commit!!
That's because it's a different file.
Looks like we have duplicate plans in all of our configs... src/plan/
plan.xml and src/main/plan/plan.xml.
Looks like http://svn.apache.org/viewvc?view=revrevision=572395
created the src/main/plan/plan.xml files, but left around the src/
plan/plan.xml files.
We need to diff all plans and make sure that we aren't missing
updates (note that a merge from branches/2.0 would apply cleanly) and
delete all src/plan/plan.xml files from svn... Otherwise, this is
going to happen again... ;-)
Any volunteers?
--kevan
Vamsi
On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: djencks
Date: Mon Sep 24 06:42:43 2007
New Revision: 578812
URL: http://svn.apache.org/viewvc?rev=578812view=rev
Log:
GERONIMO-2964 apparently missed new reference
Modified:
geronimo/server/trunk/configs/jetty6/src/main/plan/plan.xml
Modified: geronimo/server/trunk/configs/jetty6/src/main/plan/plan.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
jetty6/src/main/plan/plan.xml?rev=578812r1=578811r2=578812view=diff
==
--- geronimo/server/trunk/configs/jetty6/src/main/plan/plan.xml
(original)
+++ geronimo/server/trunk/configs/jetty6/src/main/plan/plan.xml Mon
Sep 24 06:42:43 2007
@@ -41,9 +41,12 @@
!-- default WAR container using Jetty --
gbean name=JettyWebContainer
class=org.apache.geronimo.jetty6.JettyContainerImpl
- reference name=WebManager
-nameJettyWebManager/name
- /reference
+reference name=WebManager
+nameJettyWebManager/name
+/reference
+reference name=ServerInfo
+nameServerInfo/name
+/reference
/gbean
gbean name=JettyRequestLog
class=org.apache.geronimo.jetty6.requestlog.NCSARequestLog
@@ -88,29 +91,29 @@
/gbean
!-- DONT USE THIS ONE --
-!--
-gbean name=JettySSLConnector
class=org.apache.geronimo.jetty6.connector.HTTPSSocketConnector
-attribute name=host${PlanServerHostname}/attribute
-attribute name=port${PlanHTTPSPort}/attribute
-attribute name=keyStoregeronimo-default/attribute
-attribute name=keyAliasgeronimo/attribute
-attribute name=trustStoregeronimo-default/attribute
-attribute name=clientAuthRequiredfalse/attribute
-attribute name=algorithmDefault/attribute
-attribute name=secureProtocolTLS/attribute
-attribute name=maxThreads50/attribute
-reference name=JettyContainer
-nameJettyWebContainer/name
-/reference
-reference name=ThreadPool
-nameDefaultThreadPool/name
-/reference
-reference name=KeystoreManager
-nameKeystoreManager/name
-/reference
-/gbean
---
-!-- USE THIS ONE --
+!--
+gbean name=JettySSLConnector
class=org.apache.geronimo.jetty6.connector.HTTPSSocketConnector
+attribute name=host${PlanServerHostname}/attribute
+attribute name=port${PlanHTTPSPort}/attribute
+attribute name=keyStoregeronimo-default/attribute
+attribute name=keyAliasgeronimo/attribute
+attribute name=trustStoregeronimo-default/attribute
+attribute name=clientAuthRequiredfalse/attribute
+attribute name=algorithmDefault/attribute
+attribute name=secureProtocolTLS/attribute
+attribute name=maxThreads50/attribute
+reference name=JettyContainer
+nameJettyWebContainer/name
+/reference
+reference name=ThreadPool
+nameDefaultThreadPool/name
+/reference
+reference name=KeystoreManager
+nameKeystoreManager/name
+/reference
+/gbean
+--
+!-- USE THIS ONE --
gbean name=JettySSLConnector
class=org.apache.geronimo.jetty6.connector.HTTPSSelectChannelConnecto
r
attribute name=host${PlanServerHostname}/attribute
attribute name=port${PlanHTTPSPort}/attribute
Re: Requirements for releasing a vendor specific version of DayTrader?
On Oct 2, 2007, at 11:01 PM, Matt Hogstrom wrote: It would be a powered by version if the name is used. AFAICT there is no restriction to take the code and call it Chris' Benchmark. I spect there are others out there with more insight on how some of this work. Bill Stoddard would know since Apache get's rebranded by several folks. On Oct 2, 2007, at 10:31 AM, Christopher Blythe wrote: Matt, I was just wondering what processes must be followed for an app server vendor to release a customized version of DayTrader? We are thinking about replacing the Trade 6.1 download on the WebSphere site with DayTrader and I wanted to make sure we cover all our bases from an Apache perspective. Chris, There's no process from an Apache perspective -- just do it... IANAL and you should consult your local consel... However, the Apache License makes this pretty simple for you. You just need to follow the terms of the Apache License. Namely section 4 (Redistribution) -- http://apache.org/licenses/LICENSE-2.0.html. You need to include a copy of the Apache license in your distribution and you must include the attribution notices from the NOTICE file... --kevan
Re: [jira] Commented: (GERONIMO-3309) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool
On Oct 8, 2007, at 11:29 AM, Jason Warner wrote: You're using the correct command to build the tool. I just checked out the latest version and built it with no issues? It was recently moved to the devtools component. Is that where you checked it out from? What problems are you having? mvn install assembly:assembly ... [INFO] Building jar: /Users/kevan/geronimo/devtools/j2g/trunk/plugins/ org.apache.geronimo.j2g.ui/target/org.apache.geronimo.j2g.ui-1.0.0- SNAPSHOT.jar [INFO] [assembly:assembly] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Included module: org.apache.geronimo.tools:j2g-plugins:pom: 1.0.0-SNAPSHOT does not have an artifact with a file. Please ensure the package phase is run before the assembly is generated. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 58 seconds [INFO] Finished at: Mon Oct 08 10:42:01 EDT 2007 [INFO] Final Memory: 30M/85M [INFO] --kevan
Re: [DISCUSS] G 2.0.2 Release plan
All, I've created a 2.0.2 release branch -- https://svn.apache.org/repos/ asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. Beyond those two, I don't think there is any more work to do on 2.0.2. As soon as they are complete, I'll start working on spinning up an RC. Oh, there is one more thing... We need to release the 2.0.2 versions of geronimo-transaction and geronimo-connector. I starting to work on this now. I'll either start release proceedings prior to, or concurrently with G 2.0.2. --kevan
Re: [jira] Commented: (GERONIMO-3309) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool
On Oct 8, 2007, at 12:53 PM, Jason Warner wrote:
It looks like you're building from the ui package. The ui package
has dependencies on a few other packages in j2g. The error your
getting is complaining about not being able to find a built version
of those packages. That error message seems to lack a description
of which package it wants that it can't find. I took a look at the
pom, but didn't really see anything regarding what packages it
would want. Can you try building j2g completely from your root j2g
directory? The same command can be used.
I'm building from j2g/trunk. The error occurs when the build reaches
org.apache.geronimo.j2g.ui.
Here's output with -e option:
[INFO]
[INFO] Building org.apache.geronimo.j2g.ui
[INFO]
[INFO] [eclipsepde:manifestbundles {execution: default}]
[INFO] [eclipsepde:install {execution: default}]
[INFO] org.eclipse.equinox.registry : 3.3.0-v20070522 already exists
in local repository.
[INFO] org.eclipse.ui.console : 3.2.0-v20070530 already exists in
local repository.
[INFO] org.eclipse.jface : 3.3.0-I20070606-0010 already exists in
local repository.
[INFO] SWTFragment: Dependency {groupId=org.eclipse.plugins,
artifactId=org.eclipse.swt.carbon.macosx, version=3.3.0-v3346, type=jar}
[INFO] org.eclipse.swt.carbon.macosx : 3.3.0-v3346 already exists in
local repository.
[INFO] org.eclipse.swt : 3.3.0-v3346 already exists in local repository.
[INFO] org.eclipse.equinox.preferences : 3.2.100-v20070522 already
exists in local repository.
[INFO] org.eclipse.ui : 3.3.0-I20070614-0800 already exists in local
repository.
[INFO] org.eclipse.core.jobs : 3.3.0-v20070423 already exists in
local repository.
[INFO] org.eclipse.equinox.app : 1.0.0-v20070606 already exists in
local repository.
[INFO] org.eclipse.core.contenttype : 3.2.100-v20070319 already
exists in local repository.
[INFO] org.eclipse.ui.workbench : 3.3.0-I20070608-1100 already exists
in local repository.
[INFO] org.eclipse.debug.ui : 3.3.0-v20070607-1800 already exists in
local repository.
[INFO] org.eclipse.osgi : 3.3.0-v20070530 already exists in local
repository.
[INFO] org.eclipse.core.runtime : 3.3.100-v20070530 already exists in
local repository.
[INFO] org.eclipse.debug.core : 3.3.0-v20070607-1800 already exists
in local repository.
[INFO] org.eclipse.equinox.common : 3.3.0-v20070426 already exists in
local repository.
[INFO] org.eclipse.swt.carbon.macosx : 3.3.0-v3346 already exists in
local repository.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [eclipsepde:validatemanifest {execution: validate-bundle-
classpath}]
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar: /Users/kevan/geronimo/devtools/j2g/trunk/plugins/
org.apache.geronimo.j2g.ui/target/org.apache.geronimo.j2g.ui-1.0.0-
SNAPSHOT.jar
[INFO] [assembly:assembly]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Included module: org.apache.geronimo.tools:j2g-plugins:pom:
1.0.0-SNAPSHOT does not have an artifact with a file. Please ensure
the package phase is run before the assembly is generated.
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Included
module: org.apache.geronimo.tools:j2g-plugins:pom:1.0.0-SNAPSHOT does
not have an artifact with a file. Please ensure the package phase is
run before the assembly is generated.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoa
l(DefaultLifecycleExecutor.java:493)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle
Failures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
DefaultLifecycleExecutor.java:224)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
Re: svn commit: r582931 [3/3] - in /geronimo/devtools/j2g/trunk/plugins/org.apache.geronimo.devtools.j2g.resources: ./ META-INF/ schema/ src/ src/org/ src/org/apache/ src/org/apache/geronimo/ src/org/
On Oct 8, 2007, at 2:50 PM, [EMAIL PROTECTED] wrote: Added: geronimo/devtools/j2g/trunk/plugins/ org.apache.geronimo.devtools.j2g.resources/test-apps/security/ geronimo-secutiry-plan.xml Hi Lin, 'security' is misspelled in this new plan name... --kevan
Re: [jira] Commented: (GERONIMO-3309) Add missing LICENSE.txt and NOTICE.txt files to the J2G conversion tool
On Oct 8, 2007, at 2:31 PM, Lin Sun wrote: Hi Kevan, Could you try building with mvn install? I am able to build j2g fine with that. Yes, 'mvn install' completes without error. However, I don't think that's running a full build... I see individual jar files are built, but there's no aggregation of jars, dependent jars, command scripts, etc. Nothing that a user can actually download... Lin, are you building and running j2g? --kevan
Re: J2G - GERONIMODEVTOOLS-221
On Oct 8, 2007, at 3:19 PM, Donald Woods wrote: Cool, thanks for doing this. As soon as you're done with this JIRA, I'll create a branch for a 1.0.0 release I'd like to know how to build and run j2g... There are no license/notice files, atm... Also, RAT is flagging the following files as not having apache src license headers (are the .classpath and .project files needed? or were they an accidental commit?) Any files that are non-trivial, non-machine generated, syntactically able to hold a comment, and created by our project should have a license header. !? ./configurator/.classpath !? ./configurator/.project !? ./plugins/org.apache.geronimo.devtools.j2g.common/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.common/.project !? ./plugins/org.apache.geronimo.devtools.j2g.common/META-INF/ MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/.project !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/META- INF/MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/schema/ tool.migrations.exsd !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/test- resources/geronimo-application.xml !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/test- resources/geronimo-web.xml !? ./plugins/org.apache.geronimo.devtools.j2g.descriptors/test- resources/openejb-jar.xml !? ./plugins/org.apache.geronimo.devtools.j2g.jasper/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.jasper/.project !? ./plugins/org.apache.geronimo.devtools.j2g.jasper/META-INF/ MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.resources/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.resources/.project !? ./plugins/org.apache.geronimo.devtools.j2g.resources/META-INF/ MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.resources/schema/ tool.migrations.exsd !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ ds/hsqldb-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ ds/mysql-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ ds/oracle-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ jms/jms-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ mail/mail-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.resources/test-apps/ security/security-geronimo-plan.xml !? ./plugins/org.apache.geronimo.devtools.j2g.sources/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.sources/.project !? ./plugins/org.apache.geronimo.devtools.j2g.sources/META-INF/ MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.sources/schema/ migrations.exsd !? ./plugins/org.apache.geronimo.devtools.j2g.util/.classpath !? ./plugins/org.apache.geronimo.devtools.j2g.util/.project !? ./plugins/org.apache.geronimo.devtools.j2g.util/META-INF/ MANIFEST.MF !? ./plugins/org.apache.geronimo.devtools.j2g.util/test-apps/test- app-jboss/openejb-jar-serialized.xml --kevan
Re: jetty jee5 assembly broken in branches/2.0
On Oct 9, 2007, at 12:59 AM, Jarek Gawor wrote: Oh, I think I know what's going on. Jetty is configured with 3 connectors. Each connector is configured with 50 threads. So by the time the server starts up all the threads in the pool are taken.. Looks like in Jetty we must set the thread pool size to 150. Jarek, Thanks for tracking this down. 50 threads per connector seems like overkill to me. It's dependent on application behavior. So, hard to predict... But I would consider lowering the per connector thread count. I won't argue with increasing the thread pool size, however... I also think these WARN messages are a bit less useful than they ought to be... --kevan
[VOTE] Release geronimo-txmanager 2.0.2
As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo-transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
On Oct 10, 2007, at 6:16 AM, Joe Bohn wrote: Kevan Miller wrote: All, I've created a 2.0.2 release branch -- https://svn.apache.org/ repos/asf/geronimo/server/branches/2.0.2 And have updated the branches/2.0 version to be 2.0.3-SNAPSHOT (with a helping hand from Donald :) Vamsi is working on an update to the CA Helper in the console. Joe B is working on a JNDI mapped name problem for MEJB. The JNDI mapped name for MEJB is fixed. Excellent. Thanks Joe! I'll start pulling things together... --kevan
Board Report for October -- Input Needed
All, Geronimo is scheduled to give a Board report on October 17th. Here is a wiki page to gather status -- http://cwiki.apache.org/ confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2007-10+- +October Please have your updates in by Sunday October 14th. This allows the status to be finalized and sent to the board prior to the meeting. Thanks, --kevan
Re: svn commit: r583850 - in /geronimo/gbuild/daily_build_scripts: ./ gbuild.sh openejb.sh tck.sh testsuite.sh
On Oct 11, 2007, at 11:23 AM, [EMAIL PROTECTED] wrote: Author: prasad Date: Thu Oct 11 08:23:05 2007 New Revision: 583850 URL: http://svn.apache.org/viewvc?rev=583850view=rev Log: * checking in scripts that run daily build, run testsuite and tck smoketests Added: geronimo/gbuild/daily_build_scripts/ geronimo/gbuild/daily_build_scripts/gbuild.sh (with props) geronimo/gbuild/daily_build_scripts/openejb.sh (with props) geronimo/gbuild/daily_build_scripts/tck.sh (with props) geronimo/gbuild/daily_build_scripts/testsuite.sh (with props) Prasad, Can you please get some Apache source license headers on these scripts. I see that one of these scripts runs the TCK. It looks like it doesn't reveal any details of the TCK. So, I think that's fine. --kevan
Re: [DISCUSS] G 2.0.2 Release plan
All, I've updated the versions in branches/2.0.2 from 2.0.2-SNAPSHOT to 2.0.2. No code changes should be going into 2.0.2. I'm going to be finalizing the release notes and building binaries later tonight. The ibiblio repo is having problems this afternoon. To build successfully, I had to add the following to my settings.xml: mirrors mirror idibiblio.org/id nameMirror of http://repo1.maven.org/maven2//name urlhttp://repo1.maven.org/maven2/url mirrorOfcentral/mirrorOf /mirror /mirrors In case these problems persist, I intend to add this information to the 2.0.2 release notes and the building geronimo page on our wiki. --kevan
Re: KEYS ?
On Aug 8, 2007, at 3:08 PM, Jason Dillon wrote: And... this is done. I don't know what else needs to be changed... if anyone runs into any problems lemme know. The new location for this puppy in svn is: https://svn.apache.org/repos/asf/geronimo/KEYS Props need to check the current trunk/* and branches/* (except for release in progress branches) bits for other KEYS files and nuke them. I just encountered our proliferation of KEYS files. From an Apache release signing perspective, I think the only important file is http://www.apache.org/dist/geronimo/KEYS. Probably makes sense to keep this file and https://svn.apache.org/repos/asf/geronimo/KEYS in sync (they are currently not in sync). I'm not sure if it's possible to automate this... Ideas? I don't know of any reason to maintain KEYS files in any other svn directory. I propose we delete them from all non-tagged branches/ trunks in our svn tree. Thoughts? --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Oops. Accidentally sent my vote directly to myself instead of the dev list. Here's my +1. --kevan
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
On Oct 12, 2007, at 1:55 PM, Jason Warner wrote: Donald, I'm still unsure of the status of the license files for J2G. If we can get a confirmation that those are ok, then I'm all for releasing a 1.0.0. Otherwise, I think we should hold off. Right. They aren't ok. And must be fixed before j2g can be released. I had problems building and haven't gotten back to it... There's a jira (GERONIMO-3309) with 2 patches that are supposed to fix. If somebody can have a look, that'd be great... --kevan
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
On Oct 12, 2007, at 1:55 PM, Jason Warner wrote: Donald, I'm still unsure of the status of the license files for J2G. If we can get a confirmation that those are ok, then I'm all for releasing a 1.0.0. Otherwise, I think we should hold off. By the way, the patches seem to be missing a number of license files. Possible that some files hadn't been svn add'ed when the patch was generated? --kevan
Re: svn commit: r584040 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
On Oct 12, 2007, at 8:54 AM, Anita Kulshreshtha wrote: --- [EMAIL PROTECTED] wrote: Author: kevan Date: Thu Oct 11 21:25:03 2007 New Revision: 584040 URL: http://svn.apache.org/viewvc?rev=584040view=rev Log: Add RELEASE-NOTES for 2.0.2 release . . +To enable MEJB access, you will need to configure either an mejb- user or +mejb-admin group. The current deployment of MEJB allows read access to all the users in the default admin group. If you would like the behavior (mejb- user group) as you have described, we can make changes to the MEJB plan. To get read/write access an mejb-admin group must be created. All users in this group will have R/W access. Ok. Faulty memory, I guess. I'll update the release notes. --kevan
Re: [VOTE] Release geronimo-txmanager 2.0.2
All A reminder about this release vote. Hoping to call the vote tomorrow. --kevan On Oct 10, 2007, at 1:42 AM, Kevan Miller wrote: As discussed in the Geronimo 2.0.2 release discussion thread, we need to release geronimo-txmanager 2.0.2 to pick up fixes for the Geronimo 2.0.2 release. geronimo-txmanager contains the geronimo- transaction and geronimo-connector components. The proposed binary release artifacts can be found here -- http:// people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2.zip Your can browse these artifacts here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2/ The source for the release is currently here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/branches/2.0.2 Once released, I'll tag this source as -- https://svn.apache.org/ repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager- parent-2.0.2 For your convenience, a zip file containing this source is here -- http://people.apache.org/~kevan/geronimo-txmanager-2.0.2/geronimo- txmanager-2.0.2-src.zip A RAT report for this source is here -- http://people.apache.org/ ~kevan/geronimo-txmanager-2.0.2/geronimo-txmanager-2.0.2-rat.txt Please vote on this release. [ ] +1 Release geronimo-txmanager 2.0.2 [ ] 0 No opinion [ ] -1 Do not release geronimo-txmanager 2.0.2 Barring any problems or ongoing discussions, I'll plan on calling the vote at 8 AM (EDT) on Saturday October 13. --kevan
[VOTE] Geronimo 2.0.2 (rc1)
All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
On Oct 12, 2007, at 9:57 PM, Kevan Miller wrote: [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) Here's my +1 --kevan
[RESULT] Release geronimo-txmanager 2.0.2
All, The vote passed with 10 +1 votes and no -1 votes. I'll work on pushing the binaries, but not tonight -- probably tomorrow. --kevan
Re: svn commit: r584163 - /geronimo/server/branches/2.0.2/RELEASE_NOTES-2.0.2.txt
On Oct 15, 2007, at 3:06 AM, Vamsavardhana Reddy wrote: snip I should have reported this early. This should read Updated CA (Certification Authority) Helper application. CA Helper application is not part of the Admin Console. Not a big thing though, but, do consider this change if there is an need to spin another RC. Thanks Vamsi. I've updated the Wiki version (http://cwiki.apache.org/ confluence/display/GMOxDOC20/RELEASE-NOTES-2.0.2.TXT) with this change and and also changed maintenance EJB to management EJB in the MEJB bullet. I agree these changes don't require a new RC. Possible that the changes could be included as we roll out the release. --kevan
Re: [VOTE] Geronimo 2.0.2 (rc1)
Thanks for the votes so far. The 72 hours expires at 10 PM (EDT), this evening. I'll give it a bit more time for others to inspect. I'll plan on calling the vote tomorrow morning -- around 9 AM my time... --kevan
Re: Build issue with trunk - build hangs
On Oct 16, 2007, at 10:55 AM, Jarek Gawor wrote: Maybe try getting a thread dump while the process appears to be hanging (kill -QUIT jvm process). That might give a clue on what's going on. You can also try tracking memory utilization (since there have been multiple reports of needing more memory...) -- -verbose:gc -XX:+PrintGCDetails --kevan
Re: allowHosts in geronimo 2.0.1
On Oct 17, 2007, at 3:06 AM, Ashish Jain wrote: Any help on this issue On 10/16/07, Ashish Jain [EMAIL PROTECTED] wrote: Hi, I am trying to simulate the allowHosts feature for geronimo 2.0.1 which was available in geronimo 1.2. With geronimo 1.2 it works fine and I am able to restrict access to EJB application running on the server to specific ip addresses. With AG 2.0.1 this attribute is not allowed. Do we have some other alternative available in AG2.0.1? In config-substitutions.properties we have ClientAddresses variable. What is the use of this variable? Ashish, It looks like this configuration option got dropped as we moved from Geronimo 1.2 to Geronimo 2.0/OpenEJB 3. I don't think this was intentional... It *might* be possible to get this configured in our current code -- However, probably should reinstate allowHosts. Let us know if you'd like to see this capability... --kevan
[RESULT] Geronimo 2.0.2 (rc1)
All, This vote has passed with a unanimous 17 +1 votes. Thanks all. Will start pushing binaries... --kevan On Oct 12, 2007, at 9:57 PM, Kevan Miller wrote: All, I've prepared a 2.0.2 release candidate for review and vote. http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ contains the 8 Java EE and Minimal server (tar/zip and tomcat/ jetty) binaries. Here are pointers to the zip files: http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-jee5-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-jetty6-minimal-2.0.2-bin.zip http://people.apache.org/~kevan/release-votes/geronimo-2.0.2-dist/ geronimo-tomcat6-minimal-2.0.2-bin.zip Source for the release is packaged here: http://people.apache.org/ ~kevan/release-votes/geronimo-2.0.2-dist/geronimo-2.0.2-src.zip Note that this release is dependent upon the geronimo-txmanager release that is currently being voted on. To build Geronimo 2.0.2, you'll need to either build geronimo-txmanager from source or copy the geronimo-txmanager artifacts into your local maven repo. The maven artifacts for Geronimo 2.0.2 are here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2/ or in the following archive -- http://people.apache.org/~kevan/release-votes/ geronimo-2.0.2.tar.gz. The rat report for the Geronimo 2.0.2 source is here -- http:// people.apache.org/~kevan/release-votes/geronimo-2.0.2-rat.txt The source for the release currently resides here -- https:// svn.apache.org/repos/asf/geronimo/server/branches/2.0.2 Once the release is approved, I'll move this branch to https:// svn.apache.org/repos/asf/geronimo/server/tags/2.0.2 [ ] +1 Release Geronimo 2.0.2 [ ] 0 No opinion [ ] -1 Do not release Geronimo 2.0.2 (please provide rationale) I'll plan on calling this vote on Tuesday morning (EDT). --kevan
Re: allowHosts in geronimo 2.0.1
On Oct 17, 2007, at 10:54 AM, Ashish Jain wrote: Hi Kevan, It would be great if we can have allowHosts feature back in AG. Shall I open a jira for this issue? Hi Ashish, Yes, thanks. That would be helpful. --kevan
Re: [Discuss] Remaining work items before we create a J2G 1.0.0 branch?
On Oct 17, 2007, at 10:49 PM, Lin Sun wrote: Hi Kevan, I've marked G3309 as resolved. I documented my analysis in the latest few comments I added in the JIRA. If there is anything else that is missing from a legal point of view, please let me know. Hi Lin, That's great. Thanks for working on this. A few comments: 1. Artifacts that are AL2 licensed can still be mentioned in the license file. Although not necessary, it's good for completeness. Just say the following are licensed under ALv2: commons-logging, etc. 2. I think the NOTICE file needs a bit more attention. Even though projects are ALv2 licensed, we need to reproduce their NOTICE attributions as appropriate. Also, our notice file should mention dom4j, pull-parser, and jaxen and reproduce the copyrights that are in their licenses. The pull-parser license requires the following acknowledgement: This product includes software developed by the Indiana University Extreme! Lab. For further information please visit http://www.extreme.indiana.edu/; The appropriate location for this acknowledgement is the NOTICE file. I'll look a bit more... --kevan
[SECURITY] Potential vulnerability in Apache Tomcat Webdav servlet
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav
servlet, you may be affected by this vulnerability. If you do not
configure the Webdav servlet or configure read-only Webdav servlets,
you are not impacted by this vulnerability. Jetty configurations of
Geronimo are not affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see http://mail-
archives.apache.org/mod_mbox/tomcat-users/200710.mbox/%3c47135C2D.
[EMAIL PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However,
it is possible for the Webdav Servlet to be configured or referenced
by a user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/
servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet,
for example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem
has been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo
(2.0.3 and/or 2.1).
--kevan
Re: svn commit: r586078 - in /geronimo/devtools/j2g/trunk: LICENSE.txt NOTICE.txt
Hi Lin, Great. 2 minor comments... --kevan On Oct 18, 2007, at 2:56 PM, [EMAIL PROTECTED] wrote: Author: linsun Date: Thu Oct 18 11:56:41 2007 New Revision: 586078 URL: http://svn.apache.org/viewvc?rev=586078view=rev Log: some changes per Kevan's comments on license/notice file on dev list Modified: geronimo/devtools/j2g/trunk/LICENSE.txt geronimo/devtools/j2g/trunk/NOTICE.txt Modified: geronimo/devtools/j2g/trunk/LICENSE.txt URL: http://svn.apache.org/viewvc/geronimo/devtools/j2g/trunk/ LICENSE.txt?rev=586078r1=586077r2=586078view=diff == --- geronimo/devtools/j2g/trunk/LICENSE.txt (original) +++ geronimo/devtools/j2g/trunk/LICENSE.txt Thu Oct 18 11:56:41 2007 @@ -187,7 +187,7 @@ same printed page as the copyright notice for easier identification within third-party archives. - Copyright [] [name of copyright owner] + Copyright 2003-2007 The Apache Software Foundation This [] should not be changed... Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. @@ -200,6 +200,12 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. + += +J2G, Commons Logging, commons-el, jasper-runtime, jasper-compiler, +jasper-compiler-jdt, geronimo-jsp_sepc, geronimo-servlet-spec uses the +above Apache License v2.0. += sepc is misspelled == === == Dom4j License == Modified: geronimo/devtools/j2g/trunk/NOTICE.txt URL: http://svn.apache.org/viewvc/geronimo/devtools/j2g/trunk/ NOTICE.txt?rev=586078r1=586077r2=586078view=diff == --- geronimo/devtools/j2g/trunk/NOTICE.txt (original) +++ geronimo/devtools/j2g/trunk/NOTICE.txt Thu Oct 18 11:56:41 2007 @@ -14,3 +14,33 @@ Foundation under the Software Grant and Corporate Contribution License Agreement, informally known as the IBM Console CLA. += +== Commons-logging Notice== += +This product includes software developed by +The Apache Software Foundation (http://www.apache.org/). + + += +== Dom4j Notice == += + +Copyright 2001-2005 (C) MetaStuff, Ltd. All Rights Reserved. + += +== Jaxen Notice == += + +Copyright 2003-2006 The Werken Company. All Rights Reserved. + += +== PullParser Notice == += + +Copyright 2002 The Trustees of Indiana University. +All rights reserved. + +This product includes software developed by the Indiana +University Extreme! Lab. For further information please visit +http://www.extreme.indiana.edu/ +
[ANNOUNCE] Availability of Geronimo 2.0.2
All, Wanted to let everyone know that the Geronimo 2.0.2 binaries are available for download -- http://geronimo.apache.org/downloads.html 2.0.2 addresses a number of issues that were found in our 2.0.1 release, including the MEJB security vulnerability. Great work everyone! --kevan
Re: Location of tx manager component in source distro?
On Oct 23, 2007, at 9:11 AM, Guy Pardon wrote: Hi, This component: https://svn.apache.org/repos/asf/geronimo/ components/txmanager/ ...does not seem to figure in the source distribution 2.0.2 - or did I miss something? Hi Guy, components are released separately from our server distribution. Instead they are embedded by the Geronimo server just like any other external software project. The downside to this is that it's not a one-stop-shop when it comes to our source code. The upside is that these components can be re-used more easily by other projects. You'll find the source in our svn tree, here -- https:// svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo- txmanager-parent-2.0.2/ Or the maven central repo -- http://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo- transaction/2.0.2/geronimo-transaction-2.0.2-sources.jar http://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo- connector/2.0.2/geronimo-connector-2.0.2-sources.jar --kevan
Re: Location of tx manager component in source distro?
On Oct 23, 2007, at 11:29 AM, Guy Pardon wrote: Hi, I see. Then what is the name of the component's classes jar and where is it in the distribution? They are: repository/org/apache/geronimo/components/geronimo-transaction/2.0.2/ geronimo-transaction-2.0.2.jar repository/org/apache/geronimo/components/geronimo-connector/2.0.2/ geronimo-connector-2.0.2.jar --kevan
Re: [BUILD] 2.0: Failed for Revision: 587047
On Oct 23, 2007, at 4:17 AM, Peter Petersson wrote: I still have problem building G v2.0.2 from svn tag org.apache.xbean:xbean-naming:jar:3.2-r579367 is missing anyone else seeing this ? regards That's caused by a build of xbean created by OpenEJB. The jar file can be found here: http://svn.apache.org/repos/asf/openejb/repo/org/apache/xbean/xbean- naming/3.2-r579367/xbean-naming-3.2-r579367.jar Some other people have reported a problem with 2.0.2 builds. It builds ok for me. However, obviously failing for some. The error seems to depend upon how maven computes release numbers/determines remote repositories to be searched. We added some maven excludes to avoid the problem, but doesn't seem to have resolved the problem... You can download the jar file into your repo manually or add the following repo to your local config: repository idopenejb-3rdparty-builds/id name3rd Party Build Repository/name urlhttp://svn.apache.org/repos/asf/openejb/repo//url /repository --kevan
Re: [DISCUSS] Geronimo Eclipse Plugin (GEP) questions
On Oct 23, 2007, at 9:08 PM, Tim McConnell wrote: Hi everyone, I have a couple questions I'd like to discuss about the Geronimo Eclipse plugin: 1. How many versions of the Geronimo server should we continue to simultaneously support in the Geronimo Eclipse plugin ?? 2. What level of support should we provide in the Eclipse plugin for the Geronimo 1.2 Beta ?? My thoughts and/or opinions are as follows (simply to start the discussions): 1. The plugin now has support for four Geronimo releases (i.e., 1, 1.1.1, 1.2, and 2.0). I would like to support only three versions at a time. This would still allow an upward migration path for people who want to migrate their projects from older to new versions (which is apparently one of the major reasons for providing support for multiple versions to begin with). I feel though that support for only three versions at a time would facilitate a more stable (and smaller) code base, it would mitigate some of the test scenario permutations inherit with multiple version support, and ease the implementation transitions from one release of the GEP to another. We've had and continue to have difficulties supporting the Geronimo 2.0.2 deployment plans in the GEP, which I'm confident will finally be rectified in the next maintenance release of the GEP, but it's only exacerbated by supporting so many versions. Can you define what you mean by version? Currently we have a major.minor[.service-level] release number scheme. By release do you mean major number (e.g 2.0) or minor number (e.g. 2.0.1 and 2.0.2) releases? Personally, I think it's just fine to support only one back-level major.minor release (N-1) and the current major.minor releases (N). Using a 2.1 release as a hypothetical example. IMO, the GEP could support 2.1, and 2.0. Using the same methodology, a 2.0.2 GEP release would support 2.0 and 1.1 (I see no reason to support 1.0 at this point). I think we'd want to be practical, here. Time between releases may be a factor. Also, usage should be a factor in deciding what releases to support. We currently expect our users to migrate to G 2.0.x. We don't plan on any new 1.1.x releases. This may change over time. If a large number of users are on a back-level release, we may want to maintain support for the back-level release, even if it would violate the precedence we're defining here... 2. I would like to start to untangle some of the interdependencies we now have with the various features in the plugin in the upcoming GEP maintenance release. I know very little about the Geronimo 1.2 Beta, but I get the sense that it is more of a one-off rather than a nature progression from 1.1.1 to 2.0.x, and I just wonder though how much the 1.2 support in the plugin is really being used. If it's not being used, I would actually like to remove the 1.2 Beta code from the plugin in the upcoming maintenance release for the reasons I've mentioned above. I wouldn't characterize 1.2 as a one-off, it was a natural progression from 1.1 to 2.0. We ran into some bugs preparing for a 1.2 release. Since most of our focus was on a 2.0 release, the 1.2 issues never got resolved. At this point, I don't expect that we'll have a 1.2 release. I think you can skip 1.2-beta. --kevan
Re: Promoting GShell to a real subproject
On Oct 26, 2007, at 10:35 AM, Prasad Kashyap wrote: I don't see why we shouldn't. But can someone more informed please list the pros and cons. Here's my list: Pro's * Easier for other projects to reuse GShell * Release cycle not tied to Geronimo server release cycle Con's * Small overhead for being a separately released project -- documentation, release voting, etc * Separate source tree can complicate debugging (can make the counterpoint that debugging GShell is easier...) The Geronimo tx-manager components (transaction and connector) is another example where we've done this. Note that prior to (or concurrent with) voting on our last two releases, we've been voting on a tx-manager release. Although it need not be that way, we're falling into a lock-step release cycle... I assume that Guillaume is interested in using GShell outside of Geronimo. I assume that there will be others... I'd support GShell as a subproject... --kevan
Re: time to remove old plan files?
On Oct 26, 2007, at 2:07 PM, Jarek Gawor wrote: Is it time to remove the old/unused plan files from trunk? I mean the plan files in configs/module/src/plan/plan.xml. They have been replaced by plans in configs/module/src/main/plan/plan.xml. Sounds good... --kevan
Re: geronimo terracotta plugin demo
Hi Orion, Thanks for the note. I'm definitely interested in progress on the geronimo terracotta plugin. So thanks for giving us a status update. I have one clarification, below... On Oct 24, 2007, at 8:20 PM, Orion Letizi wrote: On Monday, we demonstrated the bitchen geronimo terracotta plugin that Jeff Genender wrote. Here are the notes I took about todo items, etc: - Geronimo release will coincide with Terracotta release in Nov. We haven't set a release goal for our 2.1 release. I assume that this is saying that the Geronimo Terracotta plugin will be released when we release Geronimo 2.1. Correct? --kevan - TODO for that release: - Fix geronimo plugin pom.xml (gary k. has already dont this, but couldn't build the plugin on windows) - publish terracotta plugin artifacts to maven repo - documentation - move plugin to forge - make sure Jeff has commit rights to forge - this will have the nice side benefit of continuous integration (see http://forge.terracotta.org/ for details) - sometime soon, we'll want to add the right magic to get the plugin tests run by the forge CI machine - nice feature adds, not necessary for initial plugin release: - unwind terracotta plugin install: - safe start - rename rc.d files - rebuilding the boot jar on change - groovy editing. checking date/time stamps on config - geronimo console portlets - configuration editor portlet - tc admin console portlet
Re: TCK access
On Oct 26, 2007, at 11:57 PM, Alan D. Cabrera wrote: I think that Geir has to ACK that the paperwork was completed. Has he done so? I don't see an ACK on our tck list. I recall that Tim had a lot of problems getting the NDA acked. Geir, Do you have an NDA on file for Jay McHugh? If not, what's the best way for him to get this to you? --kevan
Re: Build problem
On Oct 28, 2007, at 4:30 AM, Heinz Drews wrote: Hello, is there any fix or bypass available to get rid of [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) castor:castor:jar:0.9.9.0-pre Heinz I thought there was a work-around for this in the latest trunk source. I'd remove groovy-all from your m2 repo (e.g. rm -rf ~/.m2/repository/ groovy/groovy-all ) svn up and rebuild. --kevan
Re: J2G future positioning
On 10/29/07, Tim McConnell [EMAIL PROTECTED] wrote: Hi, Does anyone have any thoughts as to how we'll position the J2G plugin in the future ?? I understand now that in its initial iteration that it is narrowly scoped to work for JBoss specific migrations only (thus the JBoss in the name). However, it seems if we want to eventually enhance it as a more generic tool for migrating multiple applications to Geronimo (which I would hope we would), it might be a good time now to reconsider a more generic and/or appropriate name. Any thoughts ?? I think it's a good idea to call it a migration tool. We definitely should not be using the name JBoss. j2g would be ok (though i'd be in favor of a generic name). --kevan
[DISCUSS] 2.1 Release
I think it's time to start discussing the particulars of a 2.1 release. There's been a lot of advancements made in our plugin infrastructure. There's also been the pluggable console enhancements. It would be good to get a release out, with these capabilities. They provide a more solid platform for future enhancements, I think. There's also GShell and new monitoring capabilities. I'm probably missing a few other new functions. Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd also be very interested to hear what WADI capabilities that could be exposed. I'm willing to bang the release manager drum. I see that Joe has already started tugging on the TCK chain What do others think? How close are we to a 2.1 release? What additional capabilities and bug fixes are needed? Can we wrap up development activities in the next week or two? --kevan
Re: Promoting GShell to a real subproject
No, not in my opinion. I haven't heard of any dissenters. There's been plenty of time for someone to raise an objection. I say -- have at it... --kevan On 11/1/07, Jason Dillon [EMAIL PROTECTED] wrote: So shall we move the project out of the sandbox? Do we need an official vote for this? --jason On Oct 26, 2007, at 6:43 AM, Guillaume Nodet wrote: i think the subject is explicit. What do people think about that ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: [VOTE] Release Devtools maven-plugins-1.0 RC1
+1. I ran RAT and inspected the binaries. All looked good. Thanks Donald! --kevan On 10/30/07, Donald Woods [EMAIL PROTECTED] wrote: The maven-plugins are build tools used by the Eclipse Plugin and J2G tools and are not included in either tool. A 72 hour vote is being called for the following: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/branches/1.0 Revision 590072 Binaries can be downloaded from: http://people.apache.org/~dwoods/releases/ maven-plugins-1.0-RC1-bin.tar.gz - files to be published maven-plugins-repo-1.0-RC1.tar.gz - captured build repo The source code will be moved to the following location in svn after the release has been approved: https://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/1.0 Please record your vote by 11AM EDT Friday, Nov. 2, 2007. Thanks, Donald
Re: [DISCUSS] Release J2G 1.0.0 RC1
What are they .project and .classpath files? They don't have ASL license headers... I assume JBoss is a trademarked name. We are using it in some file names and in some file contents. Are we handling this correctly? I don't know the answer off hand. There was a recent discussion about aggregating migration tools in a common devtools directory. Was there a consensus reached? --kevan On 11/2/07, Donald Woods [EMAIL PROTECTED] wrote: Starting discussion thread for Vote thread at - http://www.nabble.com/-VOTE--Release-J2G-1.0.0-RC1-tf4740253s134.html -Donald
Re: [DISCUSS] Release J2G 1.0.0 RC1
Strange. In j2g-eclipse-plugin-1.0.0-RC1-deployable.ziphttp://people.apache.org/~dwoods/releases/j2g-1.0.0/j2g-eclipse-plugin-1.0.0-RC1-deployable.zipthe LICENSE.txt and NOTICE.txt files are write-only (i.e. I have to chmod +r to read them). I haven't tried building yet. Is this an artifact of your build environment? --kevan On 11/2/07, Donald Woods [EMAIL PROTECTED] wrote: Starting discussion thread for Vote thread at - http://www.nabble.com/-VOTE--Release-J2G-1.0.0-RC1-tf4740253s134.html -Donald
Re: Geronimo IRC logs
On Nov 8, 2007 8:55 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Does anyone know why IRC is not being logged? Don't know why, but I've pinged the contact we've used in the past at uwyn.com. Hopefully we can get it restarted... --kevan
Re: Geronimo Project Management
On Nov 7, 2007 6:47 PM, khaldi hinda [EMAIL PROTECTED] wrote: Hi, I have to represent the Project Apache Geronimo during a lecture of Software Project Management. It is possible to send me the Geronimo Project Management Documents (more precisely : aim of the architecture, all about the stepps of development, development constraints, logical context, development environment) Hinda, http://cwiki.apache.org/GMOxDEV/index.html contains some general documentation of geronimo. I realize that this isn't in a form that is very useful for your purposes, but everything else is in our dev lists which can be browsed here -- http://mail-archives.apache.org/mod_mbox/geronimo-dev/ or here -- http://www.nabble.com/Apache-Geronimo---Dev-f136.html --kevan
Re: Geronimo IRC logs
On Nov 8, 2007 8:55 AM, Anita Kulshreshtha [EMAIL PROTECTED] wrote: Does anyone know why IRC is not being logged? I think this should be fixed, now... Somebody needs to start an IRC conversation, before we know for sure... ;-) --kevan
Re: [ANN] JOSSO (Java Open Single Sign-On) support added for Geronimo
On Nov 7, 2007, at 4:23 PM, Gianluca wrote: Apache Geronimo J2EE server 2.0 is now officially supported by JOSSO 1.6 for both Single Sign-On Agent and Gateway deployments. For detailed technical guidelines on how to setup JOSSO with Apache Geronimo see : http://www.josso.org/confluence/pages/viewpage.action?pageId=2359317 A pre-configured Apache Geronimo instance and the JOSSO dependencies snapshot are available for download here : http://sourceforge.net/project/showfiles.php?group_id=116854package_id=129496 Gianluca, Cool! Thanks for the information. I think you'd be interested in our Geronimo plugin capabilities. This would allow JOSSO (and requisite dependencies) to be easily installed in an existing Geronimo server. Contact us on our dev list if you'd like more info... --kevan
Re: [DISCUSS] 2.1 Release
On Nov 8, 2007, at 4:17 PM, Hernan Cunico wrote: Hey y'all, I started to map some of the new features/functions to the 2.1 documentation. I just created a new wiki space http://cwiki.apache.org/GMOxDOC21 and created some initial entries. Pls chime in with your ideas for topics to cover but don't stop just there, feel free to start working out some content too if you feel compelled to do so ;-) Help with the documentation is GREATLY APPRECIATED!!! I will be starting a separate thread on user@ for user feedback as well. Thanks, Hernan. It looks like documentation may be our long pole for getting a 2.1 release. I'll start looking at the required documentation... Will help where I can. I'll summarize the results of this thread, but may take me a day or two. --kevan
Re: svn commit: r594117 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/src/main/assembly/ assemblies/geronimo-jetty6-javaee5/src/main/resources/cluster-repository/ assemblies/ge
Hi Gianny,
I notice that this scheme is storing admin username and password in
clear text. It will also make the username/password accessible via
JMX. I think we need to avoid this. Would prefer to see this
information handled in a manner more consistent with our handling of
sensitive information in var/security. Would you agree?
--kevan
On Nov 12, 2007, at 8:35 AM, [EMAIL PROTECTED] wrote:
Modified: geronimo/server/trunk/plugins/clustering/clustering/src/
main/plan/plan.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/clustering/clustering/src/main/plan/plan.xml?rev=594117r1=594116r2=594117view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/plugins/clustering/clustering/src/main/
plan/plan.xml (original)
+++ geronimo/server/trunk/plugins/clustering/clustering/src/main/
plan/plan.xml Mon Nov 12 05:35:48 2007
@@ -27,4 +27,78 @@
/reference
/gbean
+gbean name=MasterRepository
class=org.apache.geronimo.system.repository.Maven2Repository
+attribute name=rootmaster-repository//attribute
+reference name=ServerInfo
+nameServerInfo/name
+/reference
+/gbean
+
+gbean name=MasterConfigurationStore
class
=org.apache.geronimo.clustering.deployment.MasterConfigurationStore
+xml-attribute name=defaultEnvironment
+environment xmlns=http://geronimo.apache.org/xml/ns/deployment-$
{geronimoSchemaVersion}
+dependencies
+dependency
+groupId${pom.groupId}/groupId
+artifactIdclustering/artifactId
+typecar/type
+/dependency
+/dependencies
+/environment
+/xml-attribute
+reference name=Repository
+nameMasterRepository/name
+/reference
+reference name=ClusterInfo
+nameClusterInfo/name
+/reference
+reference name=ClusterConfigurationStoreClient
+nameClusterConfigurationStoreClient/name
+/reference
+/gbean
+
+gbean name=ClusterConfigurationStoreClient
class
=
org
.apache
.geronimo.clustering.deployment.BasicClusterConfigurationStoreClient
+attribute name=clusterConfigurationStoreNameQuery?
name=ClusterConfigurationStore/attribute
+/gbean
+
+gbean name=ClusterRepository
class=org.apache.geronimo.system.repository.Maven2Repository
+attribute name=rootcluster-repository//attribute
+reference name=ServerInfo
+nameServerInfo/name
+/reference
+/gbean
+
+gbean name=ClusterStore
class
=
org
.apache.geronimo.system.configuration.RepositoryConfigurationStore
+reference name=Repository
+nameClusterRepository/name
+/reference
+/gbean
+
+gbean name=ClusterConfigurationStore
class
=
org
.apache
.geronimo.clustering.deployment.BasicClusterConfigurationStore
+reference name=ConfigurationStore
+nameClusterStore/name
+/reference
+/gbean
+
+!-- Static Cluster Configuration --
+gbean name=ClusterInfo
class=org.apache.geronimo.clustering.config.BasicClusterInfo
+attribute name=name${PlanClusterName}/attribute
+reference name=NodeInfos/reference
+/gbean
+
+gbean name=NodeInfo
class=org.apache.geronimo.clustering.config.BasicNodeInfo
+ attribute name=nameNodeName/attribute
+ xml-attribute name=extendedJMXConnectorInfo
+ ns:javabean xmlns:ns=http://geronimo.apache.org/xml/ns/deployment/javabean-1.0
class
=
org.apache.geronimo.clustering.config.BasicExtendedJMXConnectorInfo
+ ns:property name=usernamesystem/ns:property
+ ns:property name=passwordmanager/ns:property
+ ns:property name=protocolrmi/ns:property
+ ns:property name=hostlocalhost/ns:property
+ ns:property name=port1099/ns:property
+ ns:property name=urlPathJMXConnector/
ns:property
+ ns:property name=localtrue/ns:property
+ /ns:javabean
+ /xml-attribute
+ /gbean
+
/module
Re: svn commit: r594117 [1/2] - in /geronimo/server/trunk: assemblies/geronimo-jetty6-javaee5/src/main/assembly/ assemblies/geronimo-jetty6-javaee5/src/main/resources/cluster-repository/ assemblies/ge
On Nov 13, 2007 4:40 PM, Kevan Miller [EMAIL PROTECTED] wrote:
Hi Gianny,I notice that this scheme is storing admin username and
password in clear text. It will also make the username/password accessible
via JMX. I think we need to avoid this. Would prefer to see this information
handled in a manner more consistent with our handling of sensitive
information in var/security. Would you agree?
David Jencks reminded me that 'password' properties in config.xml will be
encrypted.
--kevan
--kevan
On Nov 12, 2007, at 8:35 AM, [EMAIL PROTECTED] wrote:
Modified:
geronimo/server/trunk/plugins/clustering/clustering/src/main/plan/plan.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/clustering/clustering/src/main/plan/plan.xml?rev=594117r1=594116r2=594117view=diff
==
---
geronimo/server/trunk/plugins/clustering/clustering/src/main/plan/plan.xml
(original)
+++
geronimo/server/trunk/plugins/clustering/clustering/src/main/plan/plan.xml
Mon Nov 12 05:35:48 2007
@@ -27,4 +27,78 @@
/reference
/gbean
+gbean name=MasterRepository class=
org.apache.geronimo.system.repository.Maven2Repository
+attribute name=rootmaster-repository//attribute
+reference name=ServerInfo
+nameServerInfo/name
+/reference
+/gbean
+
+gbean name=MasterConfigurationStore class=
org.apache.geronimo.clustering.deployment.MasterConfigurationStore
+xml-attribute name=defaultEnvironment
+environment xmlns=
http://geronimo.apache.org/xml/ns/deployment-${geronimoSchemaVersion};
+dependencies
+dependency
+groupId${pom.groupId}/groupId
+artifactIdclustering/artifactId
+typecar/type
+/dependency
+/dependencies
+/environment
+/xml-attribute
+reference name=Repository
+nameMasterRepository/name
+/reference
+reference name=ClusterInfo
+nameClusterInfo/name
+/reference
+reference name=ClusterConfigurationStoreClient
+nameClusterConfigurationStoreClient/name
+/reference
+/gbean
+
+gbean name=ClusterConfigurationStoreClient class=
org.apache.geronimo.clustering.deployment.BasicClusterConfigurationStoreClient
+attribute
name=clusterConfigurationStoreNameQuery?name=ClusterConfigurationStore/attribute
+/gbean
+
+gbean name=ClusterRepository class=
org.apache.geronimo.system.repository.Maven2Repository
+attribute name=rootcluster-repository//attribute
+reference name=ServerInfo
+nameServerInfo/name
+/reference
+/gbean
+
+gbean name=ClusterStore class=
org.apache.geronimo.system.configuration.RepositoryConfigurationStore
+reference name=Repository
+nameClusterRepository/name
+/reference
+/gbean
+
+gbean name=ClusterConfigurationStore class=
org.apache.geronimo.clustering.deployment.BasicClusterConfigurationStore
+reference name=ConfigurationStore
+nameClusterStore/name
+/reference
+/gbean
+
+!-- Static Cluster Configuration --
+gbean name=ClusterInfo class=
org.apache.geronimo.clustering.config.BasicClusterInfo
+attribute name=name${PlanClusterName}/attribute
+reference name=NodeInfos/reference
+/gbean
+
+gbean name=NodeInfo class=
org.apache.geronimo.clustering.config.BasicNodeInfo
+ attribute name=nameNodeName/attribute
+ xml-attribute name=extendedJMXConnectorInfo
+ ns:javabean xmlns:ns=
http://geronimo.apache.org/xml/ns/deployment/javabean-1.0; class=
org.apache.geronimo.clustering.config.BasicExtendedJMXConnectorInfo
+ ns:property name=usernamesystem/ns:property
+ ns:property name=passwordmanager/ns:property
+ ns:property name=protocolrmi/ns:property
+ ns:property name=hostlocalhost/ns:property
+ ns:property name=port1099/ns:property
+ ns:property name=urlPathJMXConnector/ns:property
+ ns:property name=localtrue/ns:property
+ /ns:javabean
+ /xml-attribute
+ /gbean
+
/module
Re: Netbeans plugin
On Nov 16, 2007, at 12:19 AM, Siamak Sarmady wrote: Hello, I was speaking over email with Jacek Laskowski about his netbeans plugin. For sometimes I have been using Geronimo with Eclipse and I should say it is much more faster than Glasfish. I am sure if the netbeans plugin can be offered many of Netbeans developers will use Geronimo over Glassfish and Tomcat.(and new version of jboss which used to be offered with NB5.5 is not ready) Anyway, I wanted to see who is working on the project (besides Jacek) and what is the status? I willing to help but I do not know what to do and where to start (I will try to ru Hi Siamak, I don't recall seeing anyone but Jacek working on the Netbeans plugin. I'm sure he'd love to have some help. I think it would be *great* to have a Neatbeans plugin in addition to our Eclipse plugin. Perhaps Jacek can fill us in on where things stand with the plugin and identify next steps. --kevan
Re: Deploying jboss seam 2.0.0.GA's jee5 sample onto geronimo 2.1-SNAPSHOT...DONE
On Nov 15, 2007, at 8:38 PM, Jacek Laskowski wrote: On Nov 15, 2007 8:37 AM, Jacek Laskowski [EMAIL PROTECTED] wrote: Just to let you know I'm still working on it and ended up with the following plan with no changes to the sample application - booking. With the plan I can easily deploy the sample, seam starts up fine...almost. The PU the application uses is not injected, but the duplicate class...something is not reported. Any comments greatly appreciated. Your silence was as helpful as verbal help that I did not receive and I do really appreciate it - I read it as you're on your way to sort it out. keep going! ;-) Thanks! Heh. Always glad to help! ;-) I was quite interested in this problem (I'd hit the same/similar problem deploying a Seam app a week or two ago). Afraid I've just had zero-time, lately. Thanks for chasing this one down. Hoping to look at this in more detail over the weekend... --kevan It made me dug into the source code deeper and deeper and finally found the solution. I couldn't believe that it was a matter of creating the plan file with no other changes involved. I don't have to touch the sample either. No changes, but the plan makes Geronimo happy to deploy Seam's jee5 booking sample. Unbelievable how much you guys did in the server. Only now could I realize it. Awesome. I'm now able to run the sample when deployed with the following plan file. What's even more interesting is that I can run it with Hibernate JPA (!). Other than there's an issue I had to step over using a debugger with Ejb3Configuration changed (where it checks whether there're any jars to be processed where geronimo returns null when exclude-unlisted-classes is set to true, but hibernate expects empty list, i.e. Collections.EMPTY_LIST worked fine ;-)). I'm going to describe it very soon, but the real treasure is the plan and the supporting class - org .apache .geronimo.hibernate.transaction.GeronimoTransactionManagerLookup so Hibernate can get at Geronimo's tx manager (when openjpa's used it's not needed and it works fine too). The only change I did comparing to the previous plan was to change xa-transaction to local-transaction for jdbc/__default datasource as Seam didn't like it (don't remember what it was, but with the change it worked like a charm and didn't mean to spend more time investigating it). I think having Seam working pretty well on Geronimo makes Geronimo even more entertaining. Lots of people have asked me about it recently and am going to check whether other examples work fine as well. ?xml version=1.0 encoding=UTF-8? application xmlns=http://geronimo.apache.org/xml/ns/j2ee/application-2.0 environment xmlns=http://geronimo.apache.org/xml/ns/ deployment-1.2 moduleId groupIdorg.jboss.seam.examples.jee5/groupId artifactIdjboss-seam-jee5/artifactId version2.0.0.GA/version typeear/type /moduleId dependencies dependency groupIdorg.apache.geronimo.hibernate.transaction/groupId artifactIdgeronimo-hibernate-transaction-manager-lookup/ artifactId typejar/type /dependency /dependencies /environment module webjboss-seam-jee5.war/web web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2 moduleId groupIdorg.jboss.seam.examples.jee5/groupId artifactIdjboss-seam-jee5/artifactId version2.0.0.GA/version typewar/type /moduleId /environment context-root/seam-jee5/context-root /web-app /module module ejbjboss-seam-jee5.jar/ejb openejb-jar xmlns=http://www.openejb.org/xml/ns/openejb-jar-2.1; environment xmlns=http://geronimo.apache.org/xml/ns/deployment-1.2 moduleId groupIdorg.jboss.seam.examples.jee5/groupId artifactIdjboss-seam-jee5/artifactId version2.0.0.GA/version typejar/type /moduleId /environment !-- overrides what's in the module's persistence.xml -- persistence xmlns=http://java.sun.com/xml/ns/persistence; persistence-unit name=bookingDatabase !-- Hibernate JPA works fine too -- !-- providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider -- jta-data-sourcejdbc/__default/jta-data-source classorg.jboss.seam.example.booking.Booking/class classorg.jboss.seam.example.booking.Hotel/class classorg.jboss.seam.example.booking.User/class exclude-unlisted-classestrue/exclude-unlisted-classes properties property name=hibernate.transaction.manager_lookup_class value = org .apache .geronimo.hibernate.transaction.GeronimoTransactionManagerLookup / /properties /persistence-unit !-- change the way the default PU works - make it an alias to bookingDatabase PU -- persistence-unit name=cmp
Re: Distribution and start/stop of clustered deployments
On Nov 13, 2007, at 9:36 PM, Gianny Damour wrote: Hi Joe, After some investigations, here is my understanding of problem 1: there are two deployments because by default, i.e. when no target is specified, the distribute command executes against all the configuration stores defined by a Geronimo instance. Note that this default behavior is also applied by other deployment components, such as the hot directory scanner or the installation portlet. To some extent, I believe this default behavior should be changed to deploy to only one configuration store. Indeed, I am not convinced that users distributing applications would expect their applications to be deployed as many times as the number of configuration stores defined by the targeted Geronimo server. Also, having the same configuration multiple times in a Geronimo instance does not make a lot of sense. A potentially better default behavior would be: only distribute to the first target returned by DeploymentManager.getTargets(). Internally, our implementation of getTargets returns as the first target the default configuration store. Problem 3) is caused by problem 1). What do you think? Hi Gianny, That seems like reasonable behavior. I haven't looked closely at this, yet. I'm curious about how list- modules would work. I'm also wondering about plugin installation, console support, etc. Have they been updated appropriately to reflect your multiple config store scheme? --kevan
