[jira] Created: (GERONIMO-1557) W hen you enter the url of a web se rvıce ın the console You should g et a page showıng the servıce name
When you enter the url of a web servıce ın the console You should get a page showıng the servıce name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Type: Improvement Components: webservices Versions: 1.0 Environment: All Reporter: Manu T George Priority: Minor When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] XBean donation
Really? I think it is the simplest classloader API with the most flexibility... or maybe I'm just tainted by all that UCL mess... so anything other than that is simple. BUT, jokes aside, Classworlds is really simple to create hierarchies, either from configuration or programatically. Some of the more advanced import scoping fluff could get complicated, but I just don't use that. --jason On Jan 30, 2006, at 10:34 PM, Dain Sundstrom wrote: I don't consider classworlds simple at all. -dain On Jan 30, 2006, at 9:14 PM, Jason Dillon wrote: "a real simple way to define classloader hierarchies", sounds like you want Classworlds --jason -Original Message- From: James Strachan <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 11:03:24 To:dev@geronimo.apache.org Subject: Re: [vote] XBean donation On 29 Jan 2006, at 18:50, Dain Sundstrom wrote: On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote: +1 I assume this will just be a regular subproject at present. If one of the XBean folks could talk a little about how XBean could ultimately be adopted by Geronimo (the app server), that would be great. I think we talked about ways that Geronimo and XBean could move to close the gap and thus eventually make it possible to for Geronimo to adopt XBean without it being such a massive change, but I'm a little fuzzy on the details. Thanks, Aaron You're a bit fuzzy on the detail because every is a bit fuzzy. I have a few idea about how to integrate the code, but we're not going to know exactly how the integration will work or if we want to do it at all until we try. Just wanted to drop a warning before jumping into my ideas. XBean has several modules most of which are designed for direct XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to only address the kernel and server module. The kernel in XBean has a very light weight kernel compared to the Geronimo kernel. For example, the Geronimo kernel directly supports object name queries, and in XBean name querying is an optional service. The other big difference is the code is just easier to follow :) *If* we decide to switch to the XBean kernel, we can easily create an implementation of the current Geronimo kernel interface that simply calls through to the XBean kernel. I had this working with the XBean 1.0 kernel, but haven't written a bridge for the 2.0 kernel yet. The server module is more tricky. The server module contains simplified start up code, support for spring based configurations and some experimental class loaders. All of these will take work to determine if they are beneficial to Geronimo and if so, how to integrate them with out breaking current users. I think that more importantly than integrating the code is integrating the ideas in the server module. For example, the startup code in XBean would allow us to eliminate the serialized object graph in the our startup jars, which contain important attributes that we can't edit. Agreed. I think once we import the code into an xbean module we can start experimenting with a cleaner & more lightweight POJO based kernel/ server/deployer that avoids much of the GBean plumbing. e.g. I'd love a real simple way to define classloader hierarchies and to auto- deploy & redeploy spring.xml & xbean.xml files inside those class loaders as a nice simple Spring/POJO container. James --- http://radio.weblogs.com/0112098/
Re: [vote] XBean donation
I don't consider classworlds simple at all. -dain On Jan 30, 2006, at 9:14 PM, Jason Dillon wrote: "a real simple way to define classloader hierarchies", sounds like you want Classworlds --jason -Original Message- From: James Strachan <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 11:03:24 To:dev@geronimo.apache.org Subject: Re: [vote] XBean donation On 29 Jan 2006, at 18:50, Dain Sundstrom wrote: On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote: +1 I assume this will just be a regular subproject at present. If one of the XBean folks could talk a little about how XBean could ultimately be adopted by Geronimo (the app server), that would be great. I think we talked about ways that Geronimo and XBean could move to close the gap and thus eventually make it possible to for Geronimo to adopt XBean without it being such a massive change, but I'm a little fuzzy on the details. Thanks, Aaron You're a bit fuzzy on the detail because every is a bit fuzzy. I have a few idea about how to integrate the code, but we're not going to know exactly how the integration will work or if we want to do it at all until we try. Just wanted to drop a warning before jumping into my ideas. XBean has several modules most of which are designed for direct XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to only address the kernel and server module. The kernel in XBean has a very light weight kernel compared to the Geronimo kernel. For example, the Geronimo kernel directly supports object name queries, and in XBean name querying is an optional service. The other big difference is the code is just easier to follow :) *If* we decide to switch to the XBean kernel, we can easily create an implementation of the current Geronimo kernel interface that simply calls through to the XBean kernel. I had this working with the XBean 1.0 kernel, but haven't written a bridge for the 2.0 kernel yet. The server module is more tricky. The server module contains simplified start up code, support for spring based configurations and some experimental class loaders. All of these will take work to determine if they are beneficial to Geronimo and if so, how to integrate them with out breaking current users. I think that more importantly than integrating the code is integrating the ideas in the server module. For example, the startup code in XBean would allow us to eliminate the serialized object graph in the our startup jars, which contain important attributes that we can't edit. Agreed. I think once we import the code into an xbean module we can start experimenting with a cleaner & more lightweight POJO based kernel/ server/deployer that avoids much of the GBean plumbing. e.g. I'd love a real simple way to define classloader hierarchies and to auto- deploy & redeploy spring.xml & xbean.xml files inside those class loaders as a nice simple Spring/POJO container. James --- http://radio.weblogs.com/0112098/
Re: [vote] XBean donation
"a real simple way to define classloader hierarchies", sounds like you want Classworlds --jason -Original Message- From: James Strachan <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 11:03:24 To:dev@geronimo.apache.org Subject: Re: [vote] XBean donation On 29 Jan 2006, at 18:50, Dain Sundstrom wrote: > On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote: >> +1 >> >> I assume this will just be a regular subproject at present. If >> one of >> the XBean folks could talk a little about how XBean could ultimately >> be adopted by Geronimo (the app server), that would be great. I >> think >> we talked about ways that Geronimo and XBean could move to close the >> gap and thus eventually make it possible to for Geronimo to adopt >> XBean without it being such a massive change, but I'm a little fuzzy >> on the details. >> >> Thanks, >> Aaron > > You're a bit fuzzy on the detail because every is a bit fuzzy. I > have a few idea about how to integrate the code, but we're not > going to know exactly how the integration will work or if we want > to do it at all until we try. Just wanted to drop a warning before > jumping into my ideas. > > XBean has several modules most of which are designed for direct > XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to > only address the kernel and server module. > > The kernel in XBean has a very light weight kernel compared to the > Geronimo kernel. For example, the Geronimo kernel directly > supports object name queries, and in XBean name querying is an > optional service. The other big difference is the code is just > easier to follow :) *If* we decide to switch to the XBean kernel, > we can easily create an implementation of the current Geronimo > kernel interface that simply calls through to the XBean kernel. I > had this working with the XBean 1.0 kernel, but haven't written a > bridge for the 2.0 kernel yet. > > The server module is more tricky. The server module contains > simplified start up code, support for spring based configurations > and some experimental class loaders. All of these will take work > to determine if they are beneficial to Geronimo and if so, how to > integrate them with out breaking current users. I think that more > importantly than integrating the code is integrating the ideas in > the server module. For example, the startup code in XBean would > allow us to eliminate the serialized object graph in the our > startup jars, which contain important attributes that we can't edit. Agreed. I think once we import the code into an xbean module we can start experimenting with a cleaner & more lightweight POJO based kernel/ server/deployer that avoids much of the GBean plumbing. e.g. I'd love a real simple way to define classloader hierarchies and to auto- deploy & redeploy spring.xml & xbean.xml files inside those class loaders as a nice simple Spring/POJO container. James --- http://radio.weblogs.com/0112098/
Re: Test strategy
Anyone thought about using TestNG? Its xml suite def and grouping support would be nice to define these itest suites. --jason -Original Message- From: David Blevins <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 20:41:39 To:dev@geronimo.apache.org Subject: Re: Test strategy On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote: > I would like to solicit the views of others too like you and get their > views and opinions. Great. I poked some other people in irc to get involved as well. Here is hoping :) More input is going to make for a better community supported solution. >>> - The tests can all be run or only a subset of suites can be run >>> quite easily. > >> When you say "easily" do you mean by virtue of them being separate or >> some other idea? > > When I said we could run a subset of tests "easily" when the itests > are run "on" assemblies, I meant that it would be relatively easier to > selectively include/exclude tests (by categories) than when compared > to doing the same if the itests are embedded with their modules. I think I follow what you mean. I guess the haze is in what you mean by "embedded." As I'm not sure, I will just state in more specific terms that I have never argued for putting the actual testing source code inside any particular assembly module -- this code is big, bulky, has a lot of deps itself and some pretty specific packaging needs. I have argued for simply running thebig test suite during the lifecycle of an assembly. Not sure if that is coming across well, or if it's being assumed that since I've recommended running the integration tests on an assembly, during the integration test phase of it's lifecycle, that the test source of course must be in the assembly as well. I believe we agree on keeping the test source in modules separate and organized. >>> - The tests will be grouped logically into suites or categories. >>> Each >>> individual test will fall in one of these suites. > >> Not sure of your usage of the word "test" in this sentence. In junit >> terms is that TestSuite, TestCase, or individual test method. Can >> you clarify? > > I meant TestCase. For. eg, we could have a TestSuite called, "System" > which will have test cases from many different modules. We could say > that these form the core set of tests. If the System suite passed, we > have somewhat of a stable binary with the caveat that all functions > may not work. That is much clearer to me, thanks. I do like the sort of parent module name you came up with of "System" too -- it's a keeper. At this point, I will note that it is possible put a single SuperServerSystemTest.java TestSuite in the SuperServer assemblies module (for example) that adds only the tests from the many different test modules that apply to that assembly. > In summary, the cons of running the itests "on" assemblies is that it > goes against the m2 lifecycle. And even though integration-test is an > m2 lifecycle phase, we are not exploiting it's usage but calling it > explicity again. The same has to be done for the deploy phase too. You captured that quite well. It occurred to me while writing a sentence above that there is no clear distinction between "on" and "during". In all cases you are quite literally running the tests on the assembly. The better distinction is whether or not you wish to run them "during" it's lifecycle or "after" in the lifecycle of a separate module. -David
[jira] Reopened: (GERONIMO-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
[ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] John Sisson reopened GERONIMO-1287: --- Ran installer on windows and found the following message at the end of the output in the IzPack processing window: Installed configuration geronimo/shutdown/1.0.1-SNAPSHOT/car Configuration complete. FixTextLines: C:\test\ginstall\var\temp\config.xml final rename failed. FixTextLines processing complete. Can others reproduce this issue on Windows? > IzPack Installer does not set line endings to CRLF on windows and LF on > non-Windows platforms > - > > Key: GERONIMO-1287 > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5, 1.0-M4, 1.0 > Reporter: John Sisson > Fix For: 1.1, 1.0.1 > Attachments: installer-fix-crlf.patch > > Currently we build one IzPack installer that is used on Windows and > non-Windows platforms. IzPack does not provide any fixcrlf type > functionality when copying files from its packs to the install location. > IzPack needs to be enhanced to be able to do this "easily". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Virtual Hosts
On Jan 20, 2006, at 12:53 AM, Greg Wilkins wrote: Aaron Mulder wrote: It would be saying something like, there must be a GBean to represent a virtual host, and that GBean must have a set of host names associated with it, and any application can be associated with that "defined virtual host". For Tomcat, this would be effectively a HostGBean with all that entails. For Jetty, it would be a GBean holding a list of Strings that get applied as virtual hosts when the app is associated with that "defined virtual host". Can we modify this to: there must be a GBean to represent a HOST, and that GBean must have a set of host names AND a set of aliases (virtual host names) associated with it. Any applicaton can be associated with that "defined HOST". For Tomcat, this would be effectively a HostHBean with all that entails. For Jetty it would be a GBean holding a list of string that get applied as hosts and a list of strings that get applied as virtual hosts when the app is associated with that "defined HOST". We have a potential user for this on IRC and I'm thinking of implementing it at least for jetty. Greg, can you point out the correct calls to set up a web app context with multiple hosts and virtual hosts in jetty? I didn't immediately see what to do. thanks david jencks cheers
Re: Test strategy
On Jan 30, 2006, at 7:43 PM, Prasad Kashyap wrote: I would like to solicit the views of others too like you and get their views and opinions. Great. I poked some other people in irc to get involved as well. Here is hoping :) More input is going to make for a better community supported solution. - The tests can all be run or only a subset of suites can be run quite easily. When you say "easily" do you mean by virtue of them being separate or some other idea? When I said we could run a subset of tests "easily" when the itests are run "on" assemblies, I meant that it would be relatively easier to selectively include/exclude tests (by categories) than when compared to doing the same if the itests are embedded with their modules. I think I follow what you mean. I guess the haze is in what you mean by "embedded." As I'm not sure, I will just state in more specific terms that I have never argued for putting the actual testing source code inside any particular assembly module -- this code is big, bulky, has a lot of deps itself and some pretty specific packaging needs. I have argued for simply running thebig test suite during the lifecycle of an assembly. Not sure if that is coming across well, or if it's being assumed that since I've recommended running the integration tests on an assembly, during the integration test phase of it's lifecycle, that the test source of course must be in the assembly as well. I believe we agree on keeping the test source in modules separate and organized. - The tests will be grouped logically into suites or categories. Each individual test will fall in one of these suites. Not sure of your usage of the word "test" in this sentence. In junit terms is that TestSuite, TestCase, or individual test method. Can you clarify? I meant TestCase. For. eg, we could have a TestSuite called, "System" which will have test cases from many different modules. We could say that these form the core set of tests. If the System suite passed, we have somewhat of a stable binary with the caveat that all functions may not work. That is much clearer to me, thanks. I do like the sort of parent module name you came up with of "System" too -- it's a keeper. At this point, I will note that it is possible put a single SuperServerSystemTest.java TestSuite in the SuperServer assemblies module (for example) that adds only the tests from the many different test modules that apply to that assembly. In summary, the cons of running the itests "on" assemblies is that it goes against the m2 lifecycle. And even though integration-test is an m2 lifecycle phase, we are not exploiting it's usage but calling it explicity again. The same has to be done for the deploy phase too. You captured that quite well. It occurred to me while writing a sentence above that there is no clear distinction between "on" and "during". In all cases you are quite literally running the tests on the assembly. The better distinction is whether or not you wish to run them "during" it's lifecycle or "after" in the lifecycle of a separate module. -David
Re: Test strategy
David, Thanks for letting me make that decision. I, at this point, would now have to get the insight and information from people who are more knowledgeable about the project; something similiar to what you have provided now. With my limited knowledge, I don't want to go down the wrong path. I would like to solicit the views of others too like you and get their views and opinions. >> - The tests can all be run or only a subset of suites can be run >> quite easily. > When you say "easily" do you mean by virtue of them being separate or > some other idea? When I said we could run a subset of tests "easily" when the itests are run "on" assemblies, I meant that it would be relatively easier to selectively include/exclude tests (by categories) than when compared to doing the same if the itests are embedded with their modules. >> - The tests will be grouped logically into suites or categories. Each >> individual test will fall in one of these suites. > Not sure of your usage of the word "test" in this sentence. In junit > terms is that TestSuite, TestCase, or individual test method. Can > you clarify? I meant TestCase. For. eg, we could have a TestSuite called, "System" which will have test cases from many different modules. We could say that these form the core set of tests. If the System suite passed, we have somewhat of a stable binary with the caveat that all functions may not work. In summary, the cons of running the itests "on" assemblies is that it goes against the m2 lifecycle. And even though integration-test is an m2 lifecycle phase, we are not exploiting it's usage but calling it explicity again. The same has to be done for the deploy phase too. Thanks again Prasad. On 1/30/06, David Blevins <[EMAIL PROTECTED]> wrote: > It's probably going to be you doing this work, so ultimately, you are > the one who decides what you want to write. I will just say that you > and I share the same goals, but your proposal goes against the grain > of maven which fundamentally combines build/test. Anytime you do > that, it's painful. > > So let me just stop proposing and do my best to provide the > information you'd need to get something done. > > On Jan 30, 2006, at 11:09 AM, Prasad Kashyap wrote: > > 1. Build and Test will be kept separate functionally. > > > > 2. The itests 'subproject' can scale better. The testbucket could > > become potentially large as more modules start adding their own itests > > or increasing the number of test scenarios. > > A point of clarification. There is no technical limit to > modularizing and building a set of tests in one area and reusing the > artifacts produced by them elsewhere. In other words, where you keep > the itests does not dictate where you run them. It is possible to > build tests in maven 2 and run them in maven 1. The reverse could be > true if a maven 2 version of the deployment plugin was created. > > > 3. The throughput of the itests will not determine the throughput of > > the G build. Even if we do fix the openejb itests in G now to make it > > very fast, when we have a potentially large number of itests > > contributed by different folks for different modules, they tend to add > > up. > > There are logically two different "build times" to consider. I would > consider Developer build time to be more precious, and Automated > built time to be less precious. Making the running of itests > optional to developers is mandatory. Making the itests off by > default may be a good idea. > > Either way, there is no technical limitation to achieving the above > goals and running itest "on" or "during" the assemblies. > > > 4. It will be difficult to selectively include/exclude a few tests. > > This is where you pick your poison so to speak. Not all itest will > apply to each assembly and vice versa. Meaning, there are only two > ways to skin this cat. > >1. You make each assembly say which tests apply to it >2. You make each set of tests say which assemblies apply to it > > With #1 you will have challenges specifying the tests to run. You > will have to deploy several apps and run distinct sets of tests. > With three assemblies and four distinct sets of tests (for example), > you will unpack and start each server once and deploy into it four > times (essentially). A total time of 3 unpacks and startups and 12 > deploys. > > With #2 you will have challenges specifying on which assemblies the > distinct set of tests should run against. The distinct set of tests > will have to unpack and start each assembly to run its set of tests. > With four distinct sets of tests and three assemblies (same example), > you will unpack, start and deploy on each assembly once for that set > of tests. A total of 12 unpacks, starts and deploys will be required. > > > This is how I'd imagined it, at a very high level. > > - The itests subproject will have it's own set of modules. These are > > the modules in G that have dropped their itests into this subproject.
Re: login-service refactoring: uniform treatment for the default principal
Not sure what you mean by the 'interceptor would be creating one of these (subjects?)' I want to emphasize that interceptors (or any code for that matter) should be passed authenticated subject(s) and hopefully we can avoid a call to ContextManager.registerSubject() altogether; The only calls an interceptor would do as far as subject is concerned: ContextManager.setCurrentCaller() and setNextCaller(); I have to think more about how ServerSecurityInterceptor that is doing csi-v2 authentication will interact with the login-service; Simon >> When default and run-as principals are in-effect they should be >> treated the >> same way as any other principal; (eg granting of privilege to perform >> certain tasks); That means we should track these objects in the >> login-service and believe that these objects are authentic; We rely >> on the >> login-service to produce principal objects that we believe to be >> authentic, >> not the interceptor code; >> >> There is a kludge possible such as granting interceptor code-source >> privilege to insert subjects into the context, > >In openejb the default and run-as subjects are passed into the >container, so from the container's perspective it doesn't care where >they came from. I also find it very weird that an interceptor would >be creating these because it seems to violate a separation of concern. > >> but this is authentication by >> assertion is disguise; better to be done explicitly; on top of that >> any code >> that inserts subjects into the context also inserts a bunch of >> principals >> trying to compensate for not doing authentication and should be >> avoided; > >Now as for where the subjects or principals come from I just want to >see simple easy to understand code. If logging them in is cleanest, >then I say go for it (just keep an eye out for complexity). > >-dain
[jira] Created: (GERONIMO-1556) UserTransaction may be in wrong state after ejb >> ejb call
UserTransaction may be in wrong state after ejb >> ejb call --- Key: GERONIMO-1556 URL: http://issues.apache.org/jira/browse/GERONIMO-1556 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.1 Reporter: David Jencks UserTransactionImpl has a thread local that holds the current UT state, online or offline. Currently we are unconditionally setting UT state to offline when leaving a method call. This is fine as long as the same UT threadlocal instance is never used for 2 ejb calls in the same thread. We have separate UT instances for each ejb. However, it is still possible if an ejb calls "itself" to reuse the UT. So, it we have a call A to A, after the call returns, UT will be offline in the first A. The solution is to read the state of UT on the way in to the method call and to reset it on the way back out. This is what the timer state does. As a consequence, we will be able to share the same UT instance over all ejbs, at least within an ejb application. The relevant code is in AbstractMethodOperation, and the implementations of EJBInstanceContext.setOperation. . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: login-service refactoring: uniform treatment for the default principal
On Jan 30, 2006, at 4:10 PM, Simon Godik wrote: When default and run-as principals are in-effect they should be treated the same way as any other principal; (eg granting of privilege to perform certain tasks); That means we should track these objects in the login-service and believe that these objects are authentic; We rely on the login-service to produce principal objects that we believe to be authentic, not the interceptor code; There is a kludge possible such as granting interceptor code-source privilege to insert subjects into the context, In openejb the default and run-as subjects are passed into the container, so from the container's perspective it doesn't care where they came from. I also find it very weird that an interceptor would be creating these because it seems to violate a separation of concern. but this is authentication by assertion is disguise; better to be done explicitly; on top of that any code that inserts subjects into the context also inserts a bunch of principals trying to compensate for not doing authentication and should be avoided; Now as for where the subjects or principals come from I just want to see simple easy to understand code. If logging them in is cleanest, then I say go for it (just keep an eye out for complexity). -dain
Re: login-service refactoring: uniform treatment for the default principal
On Jan 30, 2006, at 3:42 PM, Dain Sundstrom wrote:
On Jan 30, 2006, at 11:49 AM, Simon wrote:
public interface ILoginService {
No "I"s on interface names please
agreed, I forgot to mention this.
I agree with you that the default principal and run-as principals
should be
authenticated on application start-up; (That was my thinking as well)
Why would we need to authenticate the default and run-as
principals? Aren't they just object we create?
I was initially surprised at this idea and certainly want more
comments. Also, they are Subjects IIUC not Principals. However,
after thinking about it a bit more I think this is a good idea
because it puts all the access decisions in the same system. So, if
you are administering the login info and what principals get assigned
to each user, you also in the same way administer what principals get
assigned to the default user(s).
I guess it has the odd effect that you can log in as the default
user, only explicitly :-)
thanks
david jencks
-dain
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
This may not be an issue.. I am wondering whether uber jars could complicate security in the future. For example, we could provide sample/default security policies to be used by a security manager (that assume the individual jars are being used) that use CodeSource and Principal based authorization. Permissions are associated with each CodeSource. Basically, you wouldn't be able to use the same policies with the uberjar, since everything would be loaded from the one CodeSource and be associated with the one ProtectionDomain, therefore users would lose the ability to have fine grained (per library) control over what code executed by a Principal can do. This level of security would probably only be used by a minority, most likely large enterprise users. Do we only expect people to be using an uberjar in a development/build environment where they won't be running a security manager? IMO it is important that we make it easy for ant users etc. I have an experimental ant tasks module (I used a while ago against Geronimo M4) that can start and stop a server (the ant task code was largely based upon the geronimo deployment plugin code). The build of the ant task jar built a uberjar with the all the required dependencies. I think my ant task jar would be quite large if we included all of geronimo's dependencies in it. When i find some time I will look at placing it in the sandbox. John Alan D. Cabrera wrote: David Blevins wrote, On 1/30/2006 11:39 AM: On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? For maven 2 all we need is an uber pom. For people on maven 1 and ant and plain IDEs, an uber jar is nice. Following that line of reasoning, should we not have a super-uber jar that contains the specs, Geronimo, and its depdendencies? I think that it's better to do away w/ the uber jar all together. Regards, Alan
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
I think the uber jar is convenient but it's already causing a rat's nest of issues. I'd support dropping it. Jason Dillon wrote: IMO uberjar is more trouble than it is worth. --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 12:26:09 To:dev@geronimo.apache.org Subject: Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please! David Blevins wrote, On 1/30/2006 11:39 AM: On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? For maven 2 all we need is an uber pom. For people on maven 1 and ant and plain IDEs, an uber jar is nice. Following that line of reasoning, should we not have a super-uber jar that contains the specs, Geronimo, and its depdendencies? I think that it's better to do away w/ the uber jar all together. Regards, Alan
Re: login-service refactoring: uniform treatment for the default principal
When default and run-as principals are in-effect they should be treated the same way as any other principal; (eg granting of privilege to perform certain tasks); That means we should track these objects in the login-service and believe that these objects are authentic; We rely on the login-service to produce principal objects that we believe to be authentic, not the interceptor code; There is a kludge possible such as granting interceptor code-source privilege to insert subjects into the context, but this is authentication by assertion is disguise; better to be done explicitly; on top of that any code that inserts subjects into the context also inserts a bunch of principals trying to compensate for not doing authentication and should be avoided; Simon >Why would we need to authenticate the default and run-as principals? >Aren't they just object we create? > > >-dain
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:14 AM, David Jencks wrote: As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. What if we put a VERSIONS.txt file in the root of the jar which contained the names of jars it contained? -dain
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? Last time I checked Ant has quite a few users and so did Maven 1. Having an aggregate jar for those users is pretty nice. -dain
Re: login-service refactoring: uniform treatment for the default principal
On Jan 30, 2006, at 11:49 AM, Simon wrote:
public interface ILoginService {
No "I"s on interface names please
I agree with you that the default principal and run-as principals
should be
authenticated on application start-up; (That was my thinking as well)
Why would we need to authenticate the default and run-as principals?
Aren't they just object we create?
-dain
[jira] Assigned: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] John Sisson reassigned GERONIMO-1544: - Assign To: John Sisson > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Assignee: John Sisson > Priority: Critical > Attachments: installer-icon-license-fix.patch, installer-icons.tgz > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Multiple servers sharing the same repo and config store
As a programmer type it seems intuitive to me that the presence of a subdir in an alternate server root overrides the default while its absence makes the server instance inherit the default. But its possible that I am mingling system administration with too much OO. At any rate I agree that having to examine the command line and then the alternate server root directory to figure out which repository directory (or var, or config-store, etc.) is in use could be error-prone for some. An informative message shown at the beginning of startup that shows which directories are mapped into the server instance could help. I can think of a few other ways to address this concern but they all tend to sacrifice flexibility or intuitiveness. BTW, I'm not suggesting that the subdirs of the alternate server root directory get "weaved" into the subdirs of geronimo_home, as that approach *does* seem too indeterminate to me. Oh, and one more thing I'm wondering is how Sachin's req for running applications from within a dev environment might play into this new feature. Seems that ideally the solution for the var subdir would be consistent with the solution for config-store, repository, and whatever else we decide to put in geronimo_home in the future. Here's the JIRA for that req: https://issues.apache.org/jira/browse/GERONIMO-1526 Best wishes, Paul On 1/30/06, David Jencks <[EMAIL PROTECTED] > wrote: I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization.You might be able to argue me out of this position.thanksdavid jencks
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 12:26 PM, Alan D. Cabrera wrote: David Blevins wrote, On 1/30/2006 11:39 AM: On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? For maven 2 all we need is an uber pom. For people on maven 1 and ant and plain IDEs, an uber jar is nice. Following that line of reasoning, should we not have a super-uber jar that contains the specs, Geronimo, and its depdendencies? I think that it's better to do away w/ the uber jar all together. Isn't that called a "Release" But I kind of like super-uber :) Something snappy about using the same word twice in different languages. A gracious gracias, David
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:44 AM, David Jencks wrote: On Jan 30, 2006, at 11:37 AM, David Blevins wrote: On Jan 30, 2006, at 11:14 AM, David Jencks wrote: As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. The pom is inside all maven 2 built jars. That's good enough for me. OK, I see it now. Fine with me. Wish I had remembered that detail the first few times you'd asked me :) Sorry. -David
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
IMO uberjar is more trouble than it is worth. --jason -Original Message- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Mon, 30 Jan 2006 12:26:09 To:dev@geronimo.apache.org Subject: Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please! David Blevins wrote, On 1/30/2006 11:39 AM: > > On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: > >> If we moved to Maven 2 and used its transitive dependencies, would >> the the need for an Uber jar be obviated? > > > For maven 2 all we need is an uber pom. For people on maven 1 and ant > and plain IDEs, an uber jar is nice. Following that line of reasoning, should we not have a super-uber jar that contains the specs, Geronimo, and its depdendencies? I think that it's better to do away w/ the uber jar all together. Regards, Alan
Re: Test strategy
It's probably going to be you doing this work, so ultimately, you are the one who decides what you want to write. I will just say that you and I share the same goals, but your proposal goes against the grain of maven which fundamentally combines build/test. Anytime you do that, it's painful. So let me just stop proposing and do my best to provide the information you'd need to get something done. On Jan 30, 2006, at 11:09 AM, Prasad Kashyap wrote: 1. Build and Test will be kept separate functionally. 2. The itests 'subproject' can scale better. The testbucket could become potentially large as more modules start adding their own itests or increasing the number of test scenarios. A point of clarification. There is no technical limit to modularizing and building a set of tests in one area and reusing the artifacts produced by them elsewhere. In other words, where you keep the itests does not dictate where you run them. It is possible to build tests in maven 2 and run them in maven 1. The reverse could be true if a maven 2 version of the deployment plugin was created. 3. The throughput of the itests will not determine the throughput of the G build. Even if we do fix the openejb itests in G now to make it very fast, when we have a potentially large number of itests contributed by different folks for different modules, they tend to add up. There are logically two different "build times" to consider. I would consider Developer build time to be more precious, and Automated built time to be less precious. Making the running of itests optional to developers is mandatory. Making the itests off by default may be a good idea. Either way, there is no technical limitation to achieving the above goals and running itest "on" or "during" the assemblies. 4. It will be difficult to selectively include/exclude a few tests. This is where you pick your poison so to speak. Not all itest will apply to each assembly and vice versa. Meaning, there are only two ways to skin this cat. 1. You make each assembly say which tests apply to it 2. You make each set of tests say which assemblies apply to it With #1 you will have challenges specifying the tests to run. You will have to deploy several apps and run distinct sets of tests. With three assemblies and four distinct sets of tests (for example), you will unpack and start each server once and deploy into it four times (essentially). A total time of 3 unpacks and startups and 12 deploys. With #2 you will have challenges specifying on which assemblies the distinct set of tests should run against. The distinct set of tests will have to unpack and start each assembly to run its set of tests. With four distinct sets of tests and three assemblies (same example), you will unpack, start and deploy on each assembly once for that set of tests. A total of 12 unpacks, starts and deploys will be required. This is how I'd imagined it, at a very high level. - The itests subproject will have it's own set of modules. These are the modules in G that have dropped their itests into this subproject. Totally possible. - The tests will be grouped logically into suites or categories. Each individual test will fall in one of these suites. Not sure of your usage of the word "test" in this sentence. In junit terms is that TestSuite, TestCase, or individual test method. Can you clarify? - The tests can all be run or only a subset of suites can be run quite easily. When you say "easily" do you mean by virtue of them being separate or some other idea? - Continuum will continue to build G first and then run itests on the assemblies. - If the assembly passes a certain set of tests, then it can be certified good and then be uploaded to the repository. The maven 2 lifecycle supports this flow on a per module basis (truncated, but still in order): compile test-compile test package before-integration-test integration-test after-integration-test verify install deploy If there is a failure the next phase of the lifecycle is not called. So if "test" fails, "package" is not called. If "integration-test" fails then "install" or "deploy" are not called. Note, there are no "integration-test-complile" or "integration- test-package" phases as it is expected these exist in other modules. The life cycle of assembly SuperServer could work in maven 2 as follows: Geronimo :: Assembly :: Super Server compile(no op) test-compile (no op) test (no op) packagebuild the assembly before-integration-testunpack and start the server, deploy required itest components integration-test run all itests applicable for this assembly after-integration-test stop server verify run any additional checks to verify the package is valid and meets quality criteria. installput in local maven repo deplo
Re: Multiple servers sharing the same repo and config store
As far as directory structure, it seems that WebSphere separates the binaries (e.g. jars, scripts) from the instance data. Each instance has it's own copy of configuration data, installed applications, logs and properties. The scripts (e.g. startup/shutdown) are also available in each instance such that the user doesn't need to specify any environmental variables or parameters to indicate "which instance" when executing the scripts. -Dave- Dain Sundstrom wrote: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured? -dain On Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote: This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config stores, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is "writable" at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks <[EMAIL PROTECTED]> wrote: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
David Blevins wrote, On 1/30/2006 11:39 AM: On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? For maven 2 all we need is an uber pom. For people on maven 1 and ant and plain IDEs, an uber jar is nice. Following that line of reasoning, should we not have a super-uber jar that contains the specs, Geronimo, and its depdendencies? I think that it's better to do away w/ the uber jar all together. Regards, Alan
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
Kevan Miller wrote, On 1/30/2006 12:03 PM: FYI, console-standard currently has a dependency on geronimo- j2ee_1.4_spec-1.1-SNAPSHOT.jar which is where our builds currently (since the jar has yet to be published -- Alan when will this be fixed?) Even if we removed this dependency, we'd eventually die in new5... working on it...
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 2:38 PM, David Jencks wrote: On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: On 1/30/2006 11:14 AM, David Jencks wrote: On Jan 30, 2006, at 11:07 AM, David Blevins wrote: On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. Come on. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). If we did things according to your proposal, there would be 9 choices for each spec, 153 spec jars floating in the public and exactly 124 of them will be duplicates of previously released jars. Except the trick is, you won't actually know which ones are truly diplicates of other jars; you'd have to diff the scm like I did. Everyone would be forced to upgrade, even if they don't use javamail or corba, just to be sure and before you know it all 154 of those jars will be in use. IMHO, this will create a big mess for everyone who uses spec jars and has to deal with several other artifacts also using different versions of the spec jars. As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? I don't see how. I don't think any parts of geronimo should use the uber jar no matter which maven version we are using: my understanding is that it is for the convenience of users who don't want to figure out exactly which specs they are relying on. FYI, console-standard currently has a dependency on geronimo- j2ee_1.4_spec-1.1-SNAPSHOT.jar which is where our builds currently (since the jar has yet to be published -- Alan when will this be fixed?) Even if we removed this dependency, we'd eventually die in new5... --kevan Cant we solve this dilemma by generating a little text file that says which jars were aggregated and sticking it in META-INF? Is there some more "official" way to do this like with manifest entries? thanks david jencks Regards, Alan
Re: login-service refactoring: uniform treatment for the default principal
Hi David,
Currently there is DefaultPrincipal type and it wraps a subject; When I talk
about default principal I mean default principal name.
jetty interceptor code
(org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter) generates
a subject for a default principal with the help of the utility code that
populates a subject will all sorts of principals (domain, realm, etc); then
interceptor code registers this subject with the context and inserts another
principal (identification principal) into it;
I want to avoid all of that;
All logins should go through the login-service; currently I'm using this
api:
public interface ILoginService {
public SubjectId login(String securityRealmName, CallbackHandler cbh)
throws LoginException;
Subject getSubject(SubjectId subjectId);
...
}
When authentication succeeds, login-service creates identification principal
and inserts it into the subject; then it is using the same subject-id to
insert a subject into it's logins map; After that a subject is frozen
(read-only). When you make a call on context-manager (eg
cm.setCurrentCaller()) the check is made to see that the login-service knows
about this subject by using it's identification principal; In other words
you can not insert an unauthenticated subject into the context;
I agree with you that the default principal and run-as principals should be
authenticated on application start-up; (That was my thinking as well)
Interceptor code will receive default (and run-as) subjects and will call
context-manager.setCurrentCaller() and friends when needed; (no calls to
context-manager.register-subject)
Default principal authentication: an obvious way is to specify credentials
in the plan; Do not like it much but it should be mentioned; We need to deal
with plan secrets anyway... so when we put secret-vault in place it would be
less of a problem;
It is also true (as you mention) that you will have to setup a "default
user" in a login-domain; if an application is completely security unaware
you can configure it's security realm with dummy login module that accepts
any principal; If an application is security-sensitive you must define users
in the login domains that you use.
How to authenticate default principal without specifying credentials: This
could be done if we setup deployer (a server in fact) with a secret key;
Then deployer will vouch for the default principal by creating
authentication assertion for the default principal and signing it with it's
secret key (secure hash here, not pk signature). At authentication time
login module will receive this assertion and verify it with the server;
Setting up a server with a secret key is something we can do and use for
many purposes.
Here is a flow: define default-principal by a security role; find a
principal mapping for that role with the 'run-as' attribute set to true;
This is our default principal; authenticate this principal either by using
embedded credentials or by assertion at application start-up time; Pass
authenticated subject for the default-principal to the interceptor (or any
other code that needs it).
Comments?
Simon
>On Jan 30, 2006, at 2:46 AM, Simon wrote:
>
>> In login-service re-factoring, I'd like to unify treatment of the
>> default
>> principal.
>
>I think this is interesting and important, but I'm having trouble
>following what you are proposing. Could you provide more details?
>
>One overall question I have is, where exactly are we dealing with a
>default principal? When I think about our security I always start
>from a Subject. To deal with web containers we wrap the subject in a
>principal, and the subject of course is filled up with many principals.
>>
>> Default principal should be designated by a role, not as an
>> instance of a
>> principal; To find an instance of a default-principal find a
>> principal that
>> is mapped to a role that has 'run-as' attribute set to true (same as
>> 'run-as' principal)
>
>Again, where do we do this? My understanding of the jetty and
>openejb code is that we find a subject based on a specified run-as
>role. I don't know how the tomcat integration does this.
>
>> Default (and run-as) principal should be logged in as any other
>> principal;
>> Login service will create a subject with all types of principals
>> that are
>> applicable to the specified security realm and login domain;
>> (Currently this
>> is done by utility code, not login service)
>>
>> You would not be able to insert a subject into the context unless
>> subject is
>> authenticated (contains valid identification principal).
>
>Are you proposing a runtime check that the subject is valid in some
>way, or that we modify our code so all subjects we use have come from
>a JAAS login?
>>
>> Authentication of a default (run-as) principal can be done in
>> several ways;
>> Most obvious is to specify authentication credential when mapping
>> default
> (run-as) principal; (There are other ways such
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:37 AM, David Blevins wrote: On Jan 30, 2006, at 11:14 AM, David Jencks wrote: As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. The pom is inside all maven 2 built jars. That's good enough for me. OK, I see it now. Fine with me. thanks david jencks -David
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? For maven 2 all we need is an uber pom. For people on maven 1 and ant and plain IDEs, an uber jar is nice. -David
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:24 AM, Alan D. Cabrera wrote: On 1/30/2006 11:14 AM, David Jencks wrote: On Jan 30, 2006, at 11:07 AM, David Blevins wrote: On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. Come on. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). If we did things according to your proposal, there would be 9 choices for each spec, 153 spec jars floating in the public and exactly 124 of them will be duplicates of previously released jars. Except the trick is, you won't actually know which ones are truly diplicates of other jars; you'd have to diff the scm like I did. Everyone would be forced to upgrade, even if they don't use javamail or corba, just to be sure and before you know it all 154 of those jars will be in use. IMHO, this will create a big mess for everyone who uses spec jars and has to deal with several other artifacts also using different versions of the spec jars. As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? I don't see how. I don't think any parts of geronimo should use the uber jar no matter which maven version we are using: my understanding is that it is for the convenience of users who don't want to figure out exactly which specs they are relying on. Cant we solve this dilemma by generating a little text file that says which jars were aggregated and sticking it in META-INF? Is there some more "official" way to do this like with manifest entries? thanks david jencks Regards, Alan
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:14 AM, David Jencks wrote: As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. The pom is inside all maven 2 built jars. That's good enough for me. -David
[jira] Closed: (GERONIMO-1541) Unable to deploy applications in new Minimal and WEB-JMS assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-1541?page=all ] David Jencks closed GERONIMO-1541: -- Fix Version: 1.1 Resolution: Fixed Applied, I also removed some commented out dependencies Sendingassemblies/minimal-tomcat-server/project.xml Sendingassemblies/web-jms-tomcat-server/project.xml Transmitting file data .. Committed revision 373571. > Unable to deploy applications in new Minimal and WEB-JMS assemblies > --- > > Key: GERONIMO-1541 > URL: http://issues.apache.org/jira/browse/GERONIMO-1541 > Project: Geronimo > Type: Bug > Components: deployment, general > Versions: 1.1 > Environment: Win XP (but affects all) > Reporter: Joe Bohn > Assignee: David Jencks > Fix For: 1.1 > Attachments: deployj2ee.patch > > When attempting to deploy an application into either the new > minimal-tomcat-server or web-jms-tomcat-server assemblies we receive the > following error: > Exception in thread "main" java.lang.NoClassDefFoundError: > javax/enterprise/deploy/spi/status/ProgressListener > at > org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68) > This appears to be because the j2ee deployment jar > (geronimo-j2ee-deployment_1.1_spec-1.0.jar) wasn't placed in the lib > directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On 1/30/2006 11:14 AM, David Jencks wrote: On Jan 30, 2006, at 11:07 AM, David Blevins wrote: On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. Come on. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). If we did things according to your proposal, there would be 9 choices for each spec, 153 spec jars floating in the public and exactly 124 of them will be duplicates of previously released jars. Except the trick is, you won't actually know which ones are truly diplicates of other jars; you'd have to diff the scm like I did. Everyone would be forced to upgrade, even if they don't use javamail or corba, just to be sure and before you know it all 154 of those jars will be in use. IMHO, this will create a big mess for everyone who uses spec jars and has to deal with several other artifacts also using different versions of the spec jars. As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. If we moved to Maven 2 and used its transitive dependencies, would the the need for an Uber jar be obviated? Regards, Alan
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On 1/30/2006 11:07 AM, David Blevins wrote: On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). Ahh, others who just want servlet or JSP. Point taken. Regards, Alan
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 11:07 AM, David Blevins wrote: On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. Come on. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). If we did things according to your proposal, there would be 9 choices for each spec, 153 spec jars floating in the public and exactly 124 of them will be duplicates of previously released jars. Except the trick is, you won't actually know which ones are truly diplicates of other jars; you'd have to diff the scm like I did. Everyone would be forced to upgrade, even if they don't use javamail or corba, just to be sure and before you know it all 154 of those jars will be in use. IMHO, this will create a big mess for everyone who uses spec jars and has to deal with several other artifacts also using different versions of the spec jars. As I expressed previously, I think it is a bigger mess to be unable to determine the contents of the uber-spec jar. If you can suggest a way to make it easy to find out which individual spec jars are aggregated into the uber-spec jar, I will stop objecting to individual versions. thanks david jencks -David
Re: Clustering docs - DB Section
On Mon, 30 Jan 2006, Ryan Thomas wrote: > > I just took a look at the c-jdbc design and it seems that they have to > > execute writes one at a time (one insert statement at a time) - because if > > you start multiple write transaction at the same time then multiple sites > > could execute the writes in different orders. So it's not a good general > > solution except for read-mostly applications. > > > > Pardon my ignorance, but is the purpose here to develop a db-clustering > module for geronimo, or is that beyond the scope of the server? A db-clustering module like c-jdbc is not beyond the scope, but then it has very limited value so I would not work on it.
Re: Test strategy
Following the brief discussion we began having on irc, this is what I believe you mean and are proposing - that itests should be run (on modules), during the time of an assembly creation. The key word here is "during". This is also why itests should use the same version of maven that assembly plugin also uses. I imagined this quite differently. I thought and still think we should run the itests "on" the assemblies, outside the assembly process. Here are a few reasons - 1. Build and Test will be kept separate functionally. 2. The itests 'subproject' can scale better. The testbucket could become potentially large as more modules start adding their own itests or increasing the number of test scenarios. 3. The throughput of the itests will not determine the throughput of the G build. Even if we do fix the openejb itests in G now to make it very fast, when we have a potentially large number of itests contributed by different folks for different modules, they tend to add up. 4. It will be difficult to selectively include/exclude a few tests. This is how I'd imagined it, at a very high level. - The itests subproject will have it's own set of modules. These are the modules in G that have dropped their itests into this subproject. - The tests will be grouped logically into suites or categories. Each individual test will fall in one of these suites. - The tests can all be run or only a subset of suites can be run quite easily. - Continuum will continue to build G first and then run itests on the assemblies. - If the assembly passes a certain set of tests, then it can be certified good and then be uploaded to the repository. - a download page will be available to download assemblies and binaries from every single build. The builds that passed itests will be clearly marked so. What do you think ? Cheers Prasad On 1/30/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > David, > > Can you please help clarify the following points > > You wrote, "...but in each assemblies module after an assembly is > built is where they need to execute..". I'm sorry, I quite didn't > catch what that meant. > > Next, if the assemblies are assembled using maven 1.. do they then > have to deployed using maven 1 only ? Can't they be deployed using m2 > ? > > Cheers > Prasad > > On 1/29/06, David Blevins <[EMAIL PROTECTED]> wrote: > > On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote: > > > > > On the list of Dain's "Roamap, tasks and things to do" list, > > > integration tests that cover servlets, webservices and jms was quite > > > at the top. > > > http://www.mail-archive.com/dev@geronimo.apache.org/msg16593.html > > > > > > I would like to propose the following test strategy. > > > > > > 1. Fix existing openejb itests such that they can be reintegrated back > > > into the builds. > > > > > > 2. Create a testing subproject first in the sandbox that can be used > > > to test other services and components. This subproject will use maven > > > 2. Integration test is already a phase in the Maven2 lifecycle. > > > > > > 3. Create a new deployment plugin for maven 2 for use by the testing > > > subproject. A new one is needed because the openejb itests still use > > > maven 1. > > > > > > 4. As the test suite grows, we can move the subproject from sandbox to > > > the main branch/trunk. Hopefully by then, openejb will have come out > > > of it's incubator status for it's itests to join the rest. > > > > > > What say you all ? Comments, advice, suggestions more than welcome. > > > > > > > This is a good initative. Couple notes off the top of my head. > > > > A clarification on step 1 would be that we need to run the itest on > > each assembly we create. Don't mind if they are off by default and > > run only when we build in continuum, but in each assemblies module > > after an assembly is built is where they need to execute. > > > > If we wanted to build the new itests in maven 2, that'd be ok. We > > just need to make sure they run on our assemblies, which use maven > > 1. We wouldn't need a maven 2 version of our deployment plugin > > unless we started building the assemblies with maven 2. > > > > If more working itests start showing up, i'd be fine with an itests > > module next to applications, assemblies, configs, etc.. We'd just > > want to make sure that the test we add are actually running with the > > main build and not just a bunch of test-to-get-working-someday like > > David J. and I did when we tried to create itests about this time in > > '04. > > > > Thoughts? > > > > -David > > > > >
Re: Geronimo Specs 1.1-SNAPSHOT -- more opinions please!
On Jan 30, 2006, at 8:44 AM, Alan D. Cabrera wrote: Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. Come on. We are not looking at 545 versions of javamail -- if we were i would *certainly* put my foot down hard at releasing 545 identical jars for javax.servlet and the other 12 spec jars that don't change. We are looking at maybe 8 release of javamail, possibly 4 of corba. Just guessing. That would give us this repo for all the public to consume. If you weren't using javamail or corba, you'd would only ever have to worry about the "1.0" version of everything. Those are already J2EE 1.4 certified and most haven't changed in 2 years. geronimo-activation_1.0.2_spec-1.0 geronimo-corba_2.3_spec-1.0 geronimo-corba_2.3_spec-1.1 geronimo-corba_2.3_spec-1.2 geronimo-corba_2.3_spec-1.3 geronimo-corba_2.3_spec-1.4 geronimo-corba_2.3_spec-1.5 geronimo-ejb_2.1_spec-1.0 geronimo-j2ee-connector_1.5_spec-1.0 geronimo-j2ee-deployment_1.1_spec-1.0 geronimo-j2ee-jacc_1.0_spec-1.0 geronimo-j2ee-management_1.0_spec-1.0 geronimo-javamail_1.3.1_spec-1.0 geronimo-javamail_1.3.1_spec-1.1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.3.1_spec-1.3 geronimo-javamail_1.3.1_spec-1.4 geronimo-javamail_1.3.1_spec-1.5 geronimo-javamail_1.3.1_spec-1.6 geronimo-javamail_1.3.1_spec-1.7 geronimo-javamail_1.3.1_spec-1.8 geronimo-jaxr_1.0_spec-1.0 geronimo-jaxrpc_1.1_spec-1.0 geronimo-jsp_2.0_spec-1.0 geronimo-jms_1.1_spec-1.0 geronimo-jta_1.0.1B_spec-1.0 geronimo-qname_1.1_spec-1.0 geronimo-saaj_1.1_spec-1.0 geronimo-servlet_2.4_spec-1.0 geronimo-j2ee_1.4_spec-1.0 geronimo-j2ee_1.4_spec-1.1 geronimo-j2ee_1.4_spec-1.2 geronimo-j2ee_1.4_spec-1.3 geronimo-j2ee_1.4_spec-1.4 geronimo-j2ee_1.4_spec-1.5 geronimo-j2ee_1.4_spec-1.6 geronimo-j2ee_1.4_spec-1.7 geronimo-j2ee_1.4_spec-1.8 That would represent 100% of the jars publicly available and consumed by the public. Life for people who just use servlets or jsp is simple and leveraging other projects that use servlets or jsp is also clean as they will be guaranteed to have the same servlet jar version as you (there is only one available). If we did things according to your proposal, there would be 9 choices for each spec, 153 spec jars floating in the public and exactly 124 of them will be duplicates of previously released jars. Except the trick is, you won't actually know which ones are truly diplicates of other jars; you'd have to diff the scm like I did. Everyone would be forced to upgrade, even if they don't use javamail or corba, just to be sure and before you know it all 154 of those jars will be in use. IMHO, this will create a big mess for everyone who uses spec jars and has to deal with several other artifacts also using different versions of the spec jars. -David
[jira] Updated: (GERONIMO-1426) DatabasePoolPortlet gets NPE when saving
[ http://issues.apache.org/jira/browse/GERONIMO-1426?page=all ] Paul McMahan updated GERONIMO-1426: --- Geronimo Info: [Patch Available] > DatabasePoolPortlet gets NPE when saving > > > Key: GERONIMO-1426 > URL: http://issues.apache.org/jira/browse/GERONIMO-1426 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0 > Environment: Windows XP, MySQL Connector 3.1.12, MySQL 5.0, JDK 1.4.2 > Reporter: Cary Clark > Assignee: Aaron Mulder > Fix For: 1.0.1, 1.1 > Attachments: GERONIMO-1426.patch > > From a clean Geronimo 1.0 install: > * Log in to console > * add mysql-connector-java-3.1.12-bin.jar as a Common Library > Group: mysql > Artifact: mysql-connector-java-3.1.12 > Version: bin > Type: jar > * Go to Database Pools, click "Using the Geronimo database pool wizard" > Name of Database Pool:: CPPool > Database Type: MySQL > * Click Next > JDBC Driver Class: JDBC Driver Class: >Driver JAR: > DB User Name: cpdb > DB Password: cpdbuser >Port: 3306 > Host: localhost > Database: cpdb > * Click Next > JDBC Connect URL: jdbc:mysql://localhost:3306/cpdb > Driver Status: Loaded Successfully > Pool Min Size: 10 > Pool Max Size: 15 >Blocking Timeout: NO VALUE ENTERED...assuming default > Idle Timeout: NO VALUE ENTERED...assuming default > * Click Test Connection, then Show Plan OR click Skip Test and Show Plan to > get the following stack trace: > 16:24:04,137 ERROR [DatabasePoolPortlet] Unable to save connection pool > java.lang.NullPointerException > at sun.misc.URLClassPath$3.run(URLClassPath.java:312) > at java.security.AccessController.doPrivileged(Native Method) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:309) > at sun.misc.URLClassPath.getLoader(URLClassPath.java:286) > at sun.misc.URLClassPath.findResource(URLClassPath.java:137) > at java.net.URLClassLoader$2.run(URLClassLoader.java:352) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findResource(URLClassLoader.java:349) > at java.lang.ClassLoader.getResource(ClassLoader.java:787) > at > org.apache.geronimo.deployment.tools.loader.AbstractDeployable.(AbstractDeployable.java:57) > at > org.apache.geronimo.deployment.tools.loader.ConnectorDeployable.(ConnectorDeployable.java:37) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:813) > at > org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:339) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(A
Re: Multiple servers sharing the same repo and config store
On Jan 30, 2006, at 8:54 AM, Paul McMahan wrote:One approach that seems user friendly to me would be to allow the user to pass an argument to Geronimo startup specifying a "server root" directory. The immediate subdirectories of this server root directory would trump those in geronimo_home for that server instance. Using this technique would allow the user to make any combination of geronimo's customizable parts shared across all server instances or tailored to a specific server instance.I'm not sure I like that, because IIUC it would mean that the main repository gbean for instance would be looking at different repos depending on both a command line switch and whether a particular directory existed. At the moment I think that is too indeterminate. I would prefer to have each repo gbean point to a single well defined location and to add more repositories for customization.You might be able to argue me out of this position.thanksdavid jencks Best wishes, Paul On 1/30/06, David Jencks <[EMAIL PROTECTED] > wrote: Many people have talked on and off about how to set up multipleservers sharing the same repository and config-store, but we haven'tarrived at an agreed on way to do it. We have a prospective customerfor this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someoneimplement it. I believe any implementation will be more or lesstrivial, the hard part is figuring out what to do.I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees abetter way, please speak up.So, we have a ServerInfo gbean that knows where geronimo is locatedand can resolve absolute locations for other components. Then we have things like the repository and config store gbeans thattypically are "located" outside the var dir and things like thelogging framework, local attribute manager, derby, and tomcat, thattypically keep stuff in the var directory. All or most of these start with the first configuration loaded sothey can't have any attributes overridden by config.xml: in fact thisfile is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve givingServerInfo knowledge of another path and another resolve method.One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currentlylooking inside var having the "var" trimmed off the front of theirpaths and using the new resolveVar method. In this case we'd have different servers represented as e.g.var1var2var3...The other would give ServerInfo something like resolveServer whichwould normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolvemethod instead of the old one. In this case we'd have servers likevarserver1/varserver2/var...In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which serveryou want to run; the default would presumably be as now "var".Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I thinkthat providing a different config-store class that uses the newresolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking hasgone. Please comment.thanksdavid jencks
Re: minimal-tomcat-server
Anita, I haven't tried to deploy the console into the minimal assembly ... but I image that it might have some problems. Because the console manages many of the configurations in geronimo it might have some hard coded dependencies which could prevent it from deploying and/or loading (we haven't implemented a pluggable content architecture for the console yet). Most changes to make the console work should just involve eliminating portlets/pages that manage functions not included in the assembly. I think this would not be too difficult to whittle down. Why are you interested in including the console in the minimal image? Joe anita kulshreshtha wrote: Joe, Thanks, I will try that. Any idea how much work/modification is involved in getting the console running? Thanks Anita --- Joe Bohn <[EMAIL PROTECTED]> wrote: Hi Anita, I hit this error last week. I created GERONIMO-1541 https://issues.apache.org/jira/browse/GERONIMO-1541 and attached a patch to it for the fix. If you apply this patch and rebuild the assemblies you should be able to deploy. Another quick, temporary fix is just to copy this jar "geronimo-j2ee-deployment_1.1_spec-1.0.jar" from the j2ee-tomcat-server assembly lib to the minimal-tomcat-server lib. Joe anita kulshreshtha wrote: I am getting this error while deploying any app to minimal-tomcat-server using : java -jar bin\deployer.jar deployI ..\..\..\..\applications\jmxdebug\target\geronimo-jmxdebug-1.1-SNAPSHOT.war Exception in thread "main" java.lang.NoClassDefFoundError: javax/enterprise/deploy/spi/status/ProgressListener at org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68) Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Closed: (GERONIMO-1419) javax.mail.internet.InternetHeaders has some non implemented features
[ http://issues.apache.org/jira/browse/GERONIMO-1419?page=all ] Bruce Snyder closed GERONIMO-1419: -- Fix Version: 1.1 Resolution: Fixed > javax.mail.internet.InternetHeaders has some non implemented features > - > > Key: GERONIMO-1419 > URL: http://issues.apache.org/jira/browse/GERONIMO-1419 > Project: Geronimo > Type: Bug > Components: specs > Reporter: Guillaume Nodet > Assignee: Bruce Snyder > Fix For: 1.1 > Attachments: GERONIMO-1419.patch > > Some methods throw a UnsupportedOperationException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1419) javax.mail.internet.InternetHeaders has some non implemented features
[ http://issues.apache.org/jira/browse/GERONIMO-1419?page=all ] Bruce Snyder reassigned GERONIMO-1419: -- Assign To: Bruce Snyder > javax.mail.internet.InternetHeaders has some non implemented features > - > > Key: GERONIMO-1419 > URL: http://issues.apache.org/jira/browse/GERONIMO-1419 > Project: Geronimo > Type: Bug > Components: specs > Reporter: Guillaume Nodet > Assignee: Bruce Snyder > Fix For: 1.1 > Attachments: GERONIMO-1419.patch > > Some methods throw a UnsupportedOperationException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1419) javax.mail.internet.InternetHeaders has some non implemented features
[ http://issues.apache.org/jira/browse/GERONIMO-1419?page=comments#action_12364492 ] Bruce Snyder commented on GERONIMO-1419: Patch added: Sendingsrc/main/java/javax/mail/internet/InternetHeaders.java Transmitting file data . Committed revision 373564. Thanks, Guillaume! > javax.mail.internet.InternetHeaders has some non implemented features > - > > Key: GERONIMO-1419 > URL: http://issues.apache.org/jira/browse/GERONIMO-1419 > Project: Geronimo > Type: Bug > Components: specs > Reporter: Guillaume Nodet > Fix For: 1.1 > Attachments: GERONIMO-1419.patch > > Some methods throw a UnsupportedOperationException -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: minimal-tomcat-server
Joe, Thanks, I will try that. Any idea how much work/modification is involved in getting the console running? Thanks Anita --- Joe Bohn <[EMAIL PROTECTED]> wrote: > Hi Anita, > > I hit this error last week. I created GERONIMO-1541 > > https://issues.apache.org/jira/browse/GERONIMO-1541 > and attached a patch to it for the fix. If you > apply this patch and > rebuild the assemblies you should be able to deploy. > > Another quick, temporary fix is just to copy this > jar > "geronimo-j2ee-deployment_1.1_spec-1.0.jar" from > the j2ee-tomcat-server > assembly lib to the minimal-tomcat-server lib. > > Joe > > > anita kulshreshtha wrote: > > I am getting this error while deploying any > app to > > minimal-tomcat-server using : > > > >>java -jar bin\deployer.jar deployI > > > > > ..\..\..\..\applications\jmxdebug\target\geronimo-jmxdebug-1.1-SNAPSHOT.war > > > > Exception in thread "main" > > java.lang.NoClassDefFoundError: > > > javax/enterprise/deploy/spi/status/ProgressListener > > at > > > org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68) > > > > Thanks > > Anita > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > -- > Joe Bohn > joe.bohn at earthlink.net > > "He is no fool who gives what he cannot keep, to > gain what he cannot > lose." -- Jim Elliot > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[result] [vote] XBean donation
Vote passed with: +1 Jeff Genender, Alan Cabrera, Sachin Patel, Dain Sundstrom, David Blevins, Andy Piper, Aaron Mulder, Davanum Srinivas, Jacek Laskowski, Bruce Snyder, Jason Dillion, Gianny Damour, John Sission, David Jencks, James Strachan No -1s I'll file the paperwork with the incubator and import later today. -dain On Jan 27, 2006, at 12:08 PM, Dain Sundstrom wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http:// cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/ xbean/xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain
[jira] Commented: (GERONIMO-1527) InternetAddress does not properly implement address parsing.
[ http://issues.apache.org/jira/browse/GERONIMO-1527?page=comments#action_12364490 ] Bruce Snyder commented on GERONIMO-1527: Patches added: Adding geronimo-spec-javamail/src/main/java/javax/mail/internet/AddressParser.java Sending geronimo-spec-javamail/src/main/java/javax/mail/internet/InternetAddress.java Sending geronimo-spec-javamail/src/main/java/javax/mail/internet/InternetHeaders.java Sending geronimo-spec-javamail/src/test/java/javax/mail/internet/InternetAddressTest.java Transmitting file data Committed revision 373554. Thanks, Rick! > InternetAddress does not properly implement address parsing. > > > Key: GERONIMO-1527 > URL: http://issues.apache.org/jira/browse/GERONIMO-1527 > Project: Geronimo > Type: Improvement > Components: mail > Versions: 1.0 > Environment: All. > Reporter: Rick McGuire > Fix For: 1.1 > Attachments: InternetAddress.patch, InternetHeaders.patch > > The InternetAddress class of the javamail spec package does not properly > implement RFC822 address parsing. This is impacting the ability to implement > full SMTP support, as well as adding POP3 and IMAP support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1527) InternetAddress does not properly implement address parsing.
[ http://issues.apache.org/jira/browse/GERONIMO-1527?page=all ] Bruce Snyder closed GERONIMO-1527: -- Fix Version: 1.1 Resolution: Fixed Assign To: Bruce Snyder > InternetAddress does not properly implement address parsing. > > > Key: GERONIMO-1527 > URL: http://issues.apache.org/jira/browse/GERONIMO-1527 > Project: Geronimo > Type: Improvement > Components: mail > Versions: 1.0 > Environment: All. > Reporter: Rick McGuire > Assignee: Bruce Snyder > Fix For: 1.1 > Attachments: InternetAddress.patch, InternetHeaders.patch > > The InternetAddress class of the javamail spec package does not properly > implement RFC822 address parsing. This is impacting the ability to implement > full SMTP support, as well as adding POP3 and IMAP support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: minimal-tomcat-server
Hi Anita, I hit this error last week. I created GERONIMO-1541 https://issues.apache.org/jira/browse/GERONIMO-1541 and attached a patch to it for the fix. If you apply this patch and rebuild the assemblies you should be able to deploy. Another quick, temporary fix is just to copy this jar "geronimo-j2ee-deployment_1.1_spec-1.0.jar" from the j2ee-tomcat-server assembly lib to the minimal-tomcat-server lib. Joe anita kulshreshtha wrote: I am getting this error while deploying any app to minimal-tomcat-server using : java -jar bin\deployer.jar deployI ..\..\..\..\applications\jmxdebug\target\geronimo-jmxdebug-1.1-SNAPSHOT.war Exception in thread "main" java.lang.NoClassDefFoundError: javax/enterprise/deploy/spi/status/ProgressListener at org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68) Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: login-service refactoring: uniform treatment for the default principal
On Jan 30, 2006, at 2:46 AM, Simon wrote: In login-service re-factoring, I'd like to unify treatment of the default principal. I think this is interesting and important, but I'm having trouble following what you are proposing. Could you provide more details? One overall question I have is, where exactly are we dealing with a default principal? When I think about our security I always start from a Subject. To deal with web containers we wrap the subject in a principal, and the subject of course is filled up with many principals. Default principal should be designated by a role, not as an instance of a principal; To find an instance of a default-principal find a principal that is mapped to a role that has 'run-as' attribute set to true (same as 'run-as' principal) Again, where do we do this? My understanding of the jetty and openejb code is that we find a subject based on a specified run-as role. I don't know how the tomcat integration does this. Default (and run-as) principal should be logged in as any other principal; Login service will create a subject with all types of principals that are applicable to the specified security realm and login domain; (Currently this is done by utility code, not login service) You would not be able to insert a subject into the context unless subject is authenticated (contains valid identification principal). Are you proposing a runtime check that the subject is valid in some way, or that we modify our code so all subjects we use have come from a JAAS login? Authentication of a default (run-as) principal can be done in several ways; Most obvious is to specify authentication credential when mapping default (run-as) principal; (There are other ways such that you do not have to specify credentials at all (later)). This is an interesting idea. I like that it would result in subjects always getting set up in login modules. However I think it could complicate setting up default subjects. It also means you have to have enough control over the login authentication service that you can create at least one "default user" with the appropriate principals. Is this sure to be the case? I await your explanation of how to do this without credentials :-). With credentials, it seems to me that you are likely to distribute the credentials wherever the plan is visible. I looked at interceptors and it seems that default-principal is either passed in, or subject for the default principal is passed in; So interceptors can either perform default-principal (run-as) authentication or have default (run-as) subject passed in that is already authenticated; Then an interceptor can insert default (run-as) principal into context without any additional steps; Which interceptors specifically? I think that if we authenticate a default subject, it should be done when the app is started, not for any particular request. It looks like interceptor code could be optimized so it does not login default (run-as) principals more than once; I don't see why it should ever login a run-as principal. Comments? I'd like more specific details thanks david jencks Simon
1.0.1 Release Schedule and Todos
All, I talked with Alan about me coordinating the 1.0.1 release. I'm not sure I finished my question before he said, "Sure Sure, No Problem." So for 1.0.1 I'll do the release and get this monster kicked out the door. Per David B's suggestion Alan and I will work together to get the monster out following the watch one, do one, teach one model. I went through the JIRAs this morning that were assigned to 1.0.1. I deferred several and this is the list that remains. Each of the JIRAs ends with who was currently assigned to the issue. I left that assignment in place. If you are not planning on working the issue or feel it can be deferred please update the JIRA as appropriate. The most significant issue that faces us right now is the CAR format issue. There was a lot of discussion about it but I don't think we came to an agreed upon strategy. Aaron, can you poke at that discussion and lead it to a conclusion? Apart from that many of the bugs below are trivial and it would be good to get them off the books. I would like to code freeze on Friday and get testing completed the following week and release a week from Friday. Feedback welcome. I'll be travelling today so I won't be able to check e-mail until this evening. Bugs Bug GERONIMO-1336 Setting the Max PoolSize on a DataBase pool with invalid information does not yield an error message and silently fails Aaron Mulder Bug GERONIMO-1349 Missing Ports in Startup Port List Aaron Mulder Bug GERONIMO-1426 DatabasePoolPortlet gets NPE when savingAaron Mulder Bug GERONIMO-1451 A new TCP listener for ActiveMQ is not persisting across server startups Aaron Mulder Bug GERONIMO-1506 DB info portlet should use new GeronimoVersion Aaron Mulder Bug GERONIMO-1472 packaging plugin creates client cars with wrong version David Jencks Bug GERONIMO-1475 Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed Donald Woods Bug GERONIMO-1476 Changes to default log4j.rootCategory are not dynamic Donald Woods Bug GERONIMO-1489 Minor fixes/updates to jUDDI webapp and Tomcat config Donald Woods Bug GERONIMO-1480 Cross context include does not set jacc contextID for 2nd web app. (Tomcat only) Jeff Genender Bug GERONIMO-1441 Build path contains duplicate entry errors for some geronimo projects in eclipse John Sisson Bug GERONIMO-1456 geronimo-1.0-src.zip has a meta-inf folder in the root directory John Sisson Bug GERONIMO-1490 setjavaenv.bat is not called by deploy.bat John Sisson Bug GERONIMO-1448 debug-tool does not work on Tomcat Kevan Miller TaskGERONIMO-1466 Preparing 1.0 branch for development of 1.0.1 Matt Hogstrom Bug GERONIMO-1410 Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do not work Unassigned Bug GERONIMO-1423 log4j.properties's category is ignored Unassigned Bug GERONIMO-1491 ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name Unassigned Bug GERONIMO-1492 Many "org/apache/geronimo" configIds still live in source tree Unassigned Bug GERONIMO-1503 keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners Unassigned Bug GERONIMO-1508 1.0.1 won't accept plans with 1.0 configIds in references, parents, imports, etc. Unassigned Bug GERONIMO-1510 NPE in connector DConfigBeans if no config params present on connection definition instance Unassigned Documentation Bug GERONIMO-1417 [daytrader] daytrader/docs/tradeFAQ.html out of date Unassigned Matt
minimal-tomcat-server
I am getting this error while deploying any app to minimal-tomcat-server using : >java -jar bin\deployer.jar deployI ..\..\..\..\applications\jmxdebug\target\geronimo-jmxdebug-1.1-SNAPSHOT.war Exception in thread "main" java.lang.NoClassDefFoundError: javax/enterprise/deploy/spi/status/ProgressListener at org.apache.geronimo.deployment.cli.DeployTool.(DeployTool.java:68) Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Matt Hogstrom updated GERONIMO-1531: Fix Version: 1.x (was: 1.0.1) > KeyStore portlet should support deletion of certificates and private keys > - > > Key: GERONIMO-1531 > URL: http://issues.apache.org/jira/browse/GERONIMO-1531 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Reporter: Vamsavardhana Reddy > Priority: Minor > Fix For: 1.x, 1.1 > > KeyStore portlet currently supports generation of keypairs, adding trusted > certificates to keystore and importing certificate issued by CA. It does not > address "deletion" of any of these from the keystore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Matt Hogstrom updated GERONIMO-1524: Fix Version: 1.x (was: 1.0.1) > DB pool portlet should let you select multiple driver JARs > -- > > Key: GERONIMO-1524 > URL: http://issues.apache.org/jira/browse/GERONIMO-1524 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0 > Reporter: Aaron Mulder > Fix For: 1.x, 1.1 > > Currently the database pool portlet can handle a driver requiring multiple > JARs, but the UI doesn't actually let you select more than one. Some drivers > known to need more include DB/2 and MS SQL Server. Perhaps the screen should > have a checkbox to reveal another 2 driver selection pick lists (the security > realm portlet advanced config screen has an example of revealing extra fields > if you check a particular checkbox). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1199) Keystore portlet should display certificate finger print before importing trusted certificates
[ http://issues.apache.org/jira/browse/GERONIMO-1199?page=all ] Matt Hogstrom updated GERONIMO-1199: Fix Version: 1.x (was: 1.0.1) Version: 1.0 Moving to 1.x as this is an issue that predated 1.0. > Keystore portlet should display certificate finger print before importing > trusted certificates > -- > > Key: GERONIMO-1199 > URL: http://issues.apache.org/jira/browse/GERONIMO-1199 > Project: Geronimo > Type: Improvement > Components: console > Versions: 1.0-M5, 1.0 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.x > Attachments: GERONIMO-1199.patch > > While importing trusted certificates, keystore portlet displays certicate > fields like subject, issuer, etc. It does not display a certificate finger > print which is usually used to confirm if the certificate (especially, > self-signed certificates) being imported is indeed the one user intends to > import. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1509) Maven logging output multipled
[ http://issues.apache.org/jira/browse/GERONIMO-1509?page=all ] Matt Hogstrom updated GERONIMO-1509: Fix Version: 1.x (was: 1.0.1) This is more of a build issue. I'm moving out of 1.0.1 so it doesn't get tracked with this release. > Maven logging output multipled > -- > > Key: GERONIMO-1509 > URL: http://issues.apache.org/jira/browse/GERONIMO-1509 > Project: Geronimo > Type: Bug > Components: transaction manager > Versions: 1.0 > Reporter: Aaron Mulder > Priority: Minor > Fix For: 1.x > > When I run a new Maven build on the 1.0 branch... > It starts out printing each Maven log message once... > By the time it gets to the Transaction module, it's printing each one twice: > 23:09:54,922 INFO [ReactorTag] + > 23:09:54,922 INFO [ReactorTag] + > | geronimo and geronimo-plugins Geronimo :: Transaction > 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: > Transaction > 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: > Transaction > | Memory: 24M/66M > 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M > 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M > + > 23:09:54,924 INFO [ReactorTag] + > 23:09:54,924 INFO [ReactorTag] + > Something right there causes it to really get out of hand (see below). I > wonder if the Transaction tests are manipulating the Log4J configuration? It > looks like there are 8 transaction tests and the log output goes from > repeated twice to repeated 10 times (a difference of 8... kind of makes you > go "hmmm"...). Someone should look into this. If we ID the issue in the > transaction tests, maybe we can figure out what's causing it to get from 1 to > 2 and so on. Anyway, here's the suspicious output from the transaction build: > multiproject:install-callback: > [echo] Running jar:install for Geronimo :: Transaction > java:prepare-filesystem: > [mkdir] Created dir: > /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes > java:compile: > destdir="/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes"> > [echo] Compiling to > /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes > [javac] Compiling 40 source files to > /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes > java:jar-resources: > test:prepare-filesystem: > [mkdir] Created dir: > /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes > [mkdir] Created dir: > /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports > test:test-resources: > test:compile: > [javac] Compiling 15 source files to > /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes > test:test: > [junit] Running > org.apache.geronimo.transaction.context.TransactionContextManagerTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec > [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec > [junit] Running > org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest > [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec > [junit] Running > org.apache.geronimo.transaction.manager.MockLogRecoveryTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec > [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest > [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec > [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec > [junit] Running > org.apache.geronimo.transaction.manager.TransactionManagerImplTest > [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec > [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest > [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec > Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test > [touch] Creating > /data/cv
[jira] Updated: (GERONIMO-1462) Finish implementing inverseClassloading attribute in plan schemas
[ http://issues.apache.org/jira/browse/GERONIMO-1462?page=all ] Matt Hogstrom updated GERONIMO-1462: Fix Version: 1.x (was: 1.0.1) Moving to 1.x and 1.1. Looks fairly trivial but does not appear to be critical to users. > Finish implementing inverseClassloading attribute in plan schemas > - > > Key: GERONIMO-1462 > URL: http://issues.apache.org/jira/browse/GERONIMO-1462 > Project: Geronimo > Type: Bug > Versions: 1.0 > Reporter: Aaron Mulder > Fix For: 1.x, 1.1 > > The inverseClassloading attribute is declared in geronimo-config-1.0.xsd. > It appears to be used in: > - geronimo-application-1.0 > - geronimo-connector-1.0 > - geronimo-jetty-1.0 > - openejb-jar-2.0 > It should be added to: > - geronimo-web-1.0 > - geronimo-tomcat-1.0 > - geronimo-application-client-1.0 (not totally sure about this one) > However, we need to decide whether to rev the version numbers of those > schemas when we make the change. I would be inclined to not change the > namespace or version in the file name, but to add an internal version history > in the header comment of the schemas. Mainly because that's how Sun does it > with the J2EE schemas, and I think it would be a huge pain to try to get > people to update their namespaces every time we have a tiny change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1374) Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR relationship
[ http://issues.apache.org/jira/browse/GERONIMO-1374?page=all ] Matt Hogstrom updated GERONIMO-1374: Fix Version: 1.x (was: 1.0.1) I would like to see this in 1.0.1 but it looks like it might be disruptive. I'll defer to Gianny for his opinion but moving to 1.x until someone wants to step up and get this one integrated and tested. > Open EJB does not allow the setting of a ForiegnKey that is involved in a CMR > relationship > -- > > Key: GERONIMO-1374 > URL: http://issues.apache.org/jira/browse/GERONIMO-1374 > Project: Geronimo > Type: Bug > Components: OpenEJB > Versions: 1.0-M5 > Environment: JDK 1.4.2_09 WindowsXP > Reporter: Manu T George > Assignee: Gianny Damour > Fix For: 1.x > Attachments: CMPContainerBuilder.patch, CMPContainerBuilder.patch, > CMRCompoundAccessor.java, CMRMultiplePKAsFKAccessor.java, > CompoundPKTransform.patch > > I have two CMPs with a 1:n relationship. > CMP1 - Order - PK = OrderPK which has a single field orderId > CMP2 - OrderItem = OrderItemPk which has 2 fields InventoryId and > order_orderId > OrderId and order_orderId are mapped > When i do a setOrder_orderId in the ejbCreate of OrderItem geronimo gives an > error during runtime saying cannot set read only field. > When i don't set it geronimo says partial null key . In this case I set the > cmr field in the ejbPostCreate method > org.tranql.identity.UndefinedIdentityException: Partial null key > at > org.tranql.identity.DerivedIdentity.defineIdentity(DerivedIdentity.java:80) > at > org.openejb.entity.cmp.CMPCreateMethod.execute(CMPCreateMethod.java:175) > at > org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) > at > org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) > at > org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) > at > org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) > at > org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) > at > org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1445) Allow deployment and use of exploded EAR modules
[ http://issues.apache.org/jira/browse/GERONIMO-1445?page=all ] Matt Hogstrom updated GERONIMO-1445: Fix Version: (was: 1.0.1) > Allow deployment and use of exploded EAR modules > > > Key: GERONIMO-1445 > URL: http://issues.apache.org/jira/browse/GERONIMO-1445 > Project: Geronimo > Type: Bug > Components: deployment, Hot Deploy Dir > Versions: 1.0 > Environment: Windows XP > Reporter: Todd Williams > Assignee: Aaron Mulder > Fix For: 1.1 > Attachments: GeronimoTestEar.ear.zip > > Using the Geronimo 1.0 / Tomcat bundle, placing an exploded WAR into the > deploy directory causes it to be picked up and deployed by the hot deployer > as expected. However, if I wrap the exploded war with an exploded EAR, > Geronimo fails to deploy with the error message : > 17:00:50,282 INFO [Hot Deployer] Deploying GeronimoTestEar.ear > 17:00:51,494 ERROR [Hot Deployer] Unable to deploy: Module was not a war: > GeronimoTestWeb.war > org.apache.geronimo.common.DeploymentException: Module was not a war: > GeronimoTestWeb.war > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:544) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:226) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:122) > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke() > 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:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$1c79c440.getDeploymentPlan() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) > at java.lang.Thread.run(Thread.java:534) > I'll attached a zip that when unzipped contains the exploded hierarchy for > the EAR. The application is small, but valid, as it deploys just fine when > created as an archived EAR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1196) Keystore portlet: Viewing trusted certificate results in an error
[ http://issues.apache.org/jira/browse/GERONIMO-1196?page=all ] Matt Hogstrom updated GERONIMO-1196: Fix Version: 1.x (was: 1.0.1) Version: 1.0 Deferring out of 1.0.1 to 1.x. This is an issue that was re-existing to 1.0 > Keystore portlet: Viewing trusted certificate results in an error > - > > Key: GERONIMO-1196 > URL: http://issues.apache.org/jira/browse/GERONIMO-1196 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0, 1.0-M5 > Environment: Win XP, Sun JDK 1.4.2_08 > Reporter: Vamsavardhana Reddy > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.x > Attachments: GERONIMO-1196-2.patch, GERONIMO-1196.patch > > Viewing a trusted certificate results in an error. The following exception > is logged to geronimo.log > 12:04:01,806 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > at > org.apache.geronimo.console.certmanager.actions.ViewKeyStoreEntryDetail.render(ViewKeyStoreEntryDetail.java:69) > at > org.apache.geronimo.console.certmanager.CertManagerPortlet.doView(CertManagerPortlet.java:134) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) >... > Caused by: java.lang.NullPointerException > at > sun.security.provider.JavaKeyStore$JKS.convertAlias(JavaKeyStore.java:40) > at > sun.security.provider.JavaKeyStore.engineIsCertificateEntry(JavaKeyStore.java:409) > at java.security.KeyStore.isCertificateEntry(KeyStore.java:567) > at > org.apache.geronimo.console.core.keystore.KeyStoreGBean.getKeyEntryInfo(KeyStoreGBean.java:179) > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Multiple servers sharing the same repo and config store
One approach that seems user friendly to me would be to allow the user to pass an argument to Geronimo startup specifying a "server root" directory. The immediate subdirectories of this server root directory would trump those in geronimo_home for that server instance. Using this technique would allow the user to make any combination of geronimo's customizable parts shared across all server instances or tailored to a specific server instance. Best wishes, Paul On 1/30/06, David Jencks <[EMAIL PROTECTED] > wrote: Many people have talked on and off about how to set up multipleservers sharing the same repository and config-store, but we haven'tarrived at an agreed on way to do it. We have a prospective customerfor this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someoneimplement it. I believe any implementation will be more or lesstrivial, the hard part is figuring out what to do.I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees abetter way, please speak up.So, we have a ServerInfo gbean that knows where geronimo is locatedand can resolve absolute locations for other components. Then we have things like the repository and config store gbeans thattypically are "located" outside the var dir and things like thelogging framework, local attribute manager, derby, and tomcat, thattypically keep stuff in the var directory. All or most of these start with the first configuration loaded sothey can't have any attributes overridden by config.xml: in fact thisfile is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve givingServerInfo knowledge of another path and another resolve method.One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currentlylooking inside var having the "var" trimmed off the front of theirpaths and using the new resolveVar method. In this case we'd have different servers represented as e.g.var1var2var3...The other would give ServerInfo something like resolveServer whichwould normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolvemethod instead of the old one. In this case we'd have servers likevarserver1/varserver2/var...In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which serveryou want to run; the default would presumably be as now "var".Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I thinkthat providing a different config-store class that uses the newresolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking hasgone. Please comment.thanksdavid jencks
Re: Geronimo Specs 1.1-SNAPSHOT
On 1/29/2006 1:41 PM, David Blevins wrote: On Jan 28, 2006, at 11:51 AM, David Jencks wrote: On Jan 28, 2006, at 10:57 AM, Alan D. Cabrera wrote: I've updated the trunk of Geronimo Specs to 1.1-SNAPSHOT. The thinking is that we update the versions of all the spec jars in tandem. The rational for that is that end developers will not want to pick and choose what got updated in our collection of spec jars but, instead, will just want the latest and greatest version for the entire set. IMO a more important reason is that we are aggregating all the specs into an uber-spec-jar that contains everything. In order for this jar to have a meaningful version all the things of which it is built have to have the same version. In any case, I certainly agree this is the right thing to do. I see and understand those points, but I would like to add the points that: 1. issuing new versions of jars that don't change creates a confusing mess in public repos and classpaths. 2. snapshots and new jars off all the specs is a terrible way to deal with one or two edge cases of jars that change. But as opinions are cheap, I figured I'd actually revaluate where we are at in concrete terms. I grabbed all the source from 2 years ago, 10 months ago (near passing the cts), and now then stripped out all the comments and diff'ed them. Here is what I found. IMHO, doesn't make sense to keep pushing new versions into the public for stuff that doesn't change. Think of what the alternative is that you are asking the end developer to cope w/. He must grok what is the current correct collection of versions are. Even if all the APIs mature and their version numbers never change thereafter, there will be confusion when we say everything is 1.0 except for CORBA which is 1.3 and JavaMail which is 1.545. We should also consider the situation when we accommodate new JSRs as well. IMHO, people won't care about the new versions so long as they have a single version to remember. Regards, Alan
Re: Test strategy
David, Can you please help clarify the following points You wrote, "...but in each assemblies module after an assembly is built is where they need to execute..". I'm sorry, I quite didn't catch what that meant. Next, if the assemblies are assembled using maven 1.. do they then have to deployed using maven 1 only ? Can't they be deployed using m2 ? Cheers Prasad On 1/29/06, David Blevins <[EMAIL PROTECTED]> wrote: > On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote: > > > On the list of Dain's "Roamap, tasks and things to do" list, > > integration tests that cover servlets, webservices and jms was quite > > at the top. > > http://www.mail-archive.com/dev@geronimo.apache.org/msg16593.html > > > > I would like to propose the following test strategy. > > > > 1. Fix existing openejb itests such that they can be reintegrated back > > into the builds. > > > > 2. Create a testing subproject first in the sandbox that can be used > > to test other services and components. This subproject will use maven > > 2. Integration test is already a phase in the Maven2 lifecycle. > > > > 3. Create a new deployment plugin for maven 2 for use by the testing > > subproject. A new one is needed because the openejb itests still use > > maven 1. > > > > 4. As the test suite grows, we can move the subproject from sandbox to > > the main branch/trunk. Hopefully by then, openejb will have come out > > of it's incubator status for it's itests to join the rest. > > > > What say you all ? Comments, advice, suggestions more than welcome. > > > > This is a good initative. Couple notes off the top of my head. > > A clarification on step 1 would be that we need to run the itest on > each assembly we create. Don't mind if they are off by default and > run only when we build in continuum, but in each assemblies module > after an assembly is built is where they need to execute. > > If we wanted to build the new itests in maven 2, that'd be ok. We > just need to make sure they run on our assemblies, which use maven > 1. We wouldn't need a maven 2 version of our deployment plugin > unless we started building the assemblies with maven 2. > > If more working itests start showing up, i'd be fine with an itests > module next to applications, assemblies, configs, etc.. We'd just > want to make sure that the test we add are actually running with the > main build and not just a bunch of test-to-get-working-someday like > David J. and I did when we tried to create itests about this time in > '04. > > Thoughts? > > -David > >
Re: Multiple servers sharing the same repo and config store
Hi, In WebSphere this is the directory organization: $WAS_HOME/config/cells/$CELL_NAME applications (EAR/WAR/RAR) nodes .$NODE_NAME ..servers (JVM Configurations) ..$SERVER_NAME ..server.xml ..resources.xml ..variables.xml The applications are deployed by default in $WAS_HOME/installedApps but the administrator can change the directory (this is a cool functionality) I think that BEA Weblogic has a similar architecture. In WAS 6 there is a new concept (profile). Bye, Dain Sundstrom <[EMAIL PROTECTED]> escribió: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured?-dainOn Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote:> This sounds reasonable to me. I'd prefer to have resolveServer and> always look for /var under there. If there are multiple config> store s, we'll have to figure out how the deploy tool will know which> one to use. Perhaps there should be something indicating whether the> config store is "writable" at runtime (vs at server construction time)> and only the server-specific one would be writeable? Or at least, the> tools would default to writeable ones over not? (Right now they'd> theoretically deploy to all available config stores, but I think> there's an outstanding issue that the Deployer GBean doesn't let you> specify a config store even if you wanted to.)>> Thanks,> Aaron>> On 1/30/06, David Jencks <[EMAIL PROTECTED]>wrote:>> Many people have talked on and off about how to set up multiple>> servers sharing the same repository and config-store, but we haven't>> arrived at an agreed on way to do it. We have a prospective customer>> for this feature (Vincent Massol with Cargo) so I'd like to move>> beyond thinking about it in my head, discuss it, and have someone>> implement it. I believe any implementation will be more or less>> trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than>> restructure anything or add big new capabilities. If someone sees a>> better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located>> and can resolve absolute locations for other components. Then we>> have things like the repository and config store gbeans that>> typically are "located" outside the var dir and things like the>> logging framework, local attribute manager, derby, and tomcat, that>> typically keep stuff in the var directory. All or most of these start with the first configuration loaded so>> t hey can't have any attributes overridden by config.xml: in fact this>> file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving>> ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve>> to geronimo_home/var. This would involve all the gbeans currently>> looking inside var having the "var" trimmed off the front of their>> paths and using the new resolveVar method. In this case we'd have>> different servers represented as e.g.>> var1>> var2>> var3>> ...>> The other would give ServerInfo something like resolveServer which>> would normally resolve to geronimo_home. The gbeans looking inside>> var would keep their current paths and just call the new resolve>> method instead of the old one. In this case we'd have servers like>> var>> server1/var>> server2/var>> ... In either case I think starting geronimo with a command line argument>> pointing to the var directory is the only way to specify which server>> you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into>> var for "private" use by a particular server. At the moment I think>> that providing a different config-store class that uses the new>> resolve method on server info would be the best way to do this.>> I'm not attached to these ideas but this is as far as my thinking has>> gone. Please comment. thanks>> david jencks>> __Correo Yahoo!Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
[jira] Assigned: (GERONIMO-1293) Provide tomcat statistics
[ http://issues.apache.org/jira/browse/GERONIMO-1293?page=all ] anita kulshreshtha reassigned GERONIMO-1293: Assign To: anita kulshreshtha > Provide tomcat statistics > - > > Key: GERONIMO-1293 > URL: http://issues.apache.org/jira/browse/GERONIMO-1293 > Project: Geronimo > Type: New Feature > Components: Tomcat > Versions: 1.0-M5 > Environment: All environments > Reporter: anita kulshreshtha > Assignee: anita kulshreshtha > Priority: Minor > Fix For: 1.1 > Attachments: TomcatWebAppContext.patch, geronimo-stats-1.0-SNAPSHOT.war, > geronimo-stats-1.0-SNAPSHOT.war, geronimo-stats-1.0-SNAPSHOT.war, > geronimo-stats-1.1-SNAPSHOT.war, management.patch, management.patch, > management.patch, project.patch, properties.patch, properties.patch, > stats.zip, stats.zip, stats.zip, statsApp.zip, tomcat-builder.patch, > tomcat.patch, tomcat.patch, tomcat.patch, tomcat.patch > > Provide following statistics for tomcat : > 1. Per Host/Container - > a. Initially provide the following per connector statistics for > each connector - > Cummulative statistics about all request > handled by this connector since the stat were turned on. > b. If time (before 1.0 release) permits, use 'a' to generate > (rename/compute) statistics similar to the ones provided by Jetty > 2. Per application - > a.. processingTime : The cumulative processing times of all > servlets in this StandardContext > b. startTime - The time this context was started. > c. startupTime - The time (in milliseconds) it took to start > this context. > d.. tldScanTime() - > Later add session statistics and jsp statistics. > 3. Per Servlet - Explore using statistics from RequestInfo to provide > statistics for a servlet. > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1555) Refactor web module builders
[ http://issues.apache.org/jira/browse/GERONIMO-1555?page=all ] anita kulshreshtha reassigned GERONIMO-1555: Assign To: anita kulshreshtha > Refactor web module builders > > > Key: GERONIMO-1555 > URL: http://issues.apache.org/jira/browse/GERONIMO-1555 > Project: Geronimo > Type: Improvement > Components: web > Environment: All > Reporter: anita kulshreshtha > Assignee: anita kulshreshtha > Priority: Minor > > After the patches for G-1035 are incorporated, refactor TomcatModuleBuilder > and JettyModuleBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Contributors permission in JIRA
Done. -dain On Jan 30, 2006, at 5:49 AM, anita kulshreshtha wrote: Dain, Here is my request for geronimo-contributor privileges. Do I enough karma? Thnaks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: Since on one objected, I added a geronimo-contributers group that can assign, resolve and be assigned issues. If this is becomes an issue the group can be removed just as easily as it was added. If you are a contributor (i.e. you have submitted some patches) and would like to be able to be assigned issues, let us know and we can grant you karma. Please, only ask if you have actually contributed and need the ability to work on issues. Thanks, -dain On Oct 28, 2005, at 11:11 AM, Dain Sundstrom wrote: I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Multiple servers sharing the same repo and config store
Does anyone know how other J2EE servers structure their directories when they have multiple instances configured? -dain On Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote: This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config stores, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is "writable" at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks <[EMAIL PROTECTED]> wrote: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: Roadmap, tasks and things to do?
This is great input from the entire community and I hope the ideas
keep coming! I think it would be best if these were all entered as
JIRA issues so that they can all be categorized and tracked.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)
Castor (http://castor.org/)
RE: Knowing when G is started?
Oopss… that was Lacek and Sachin ;-) Sorry -Vincent From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 15:54 To: 'dev@geronimo.apache.org' Subject: RE: Knowing when G is started? Thanks Aaron and Sachin. I’ll try your suggestions. -Vincent From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 14:32 To: dev@geronimo.apache.org Subject: Re: Knowing when G is started? There is an attributed that gets passed to each configuration when all configurations have started, you can check for it. This is what is being done in the eclipse plugin. You can call kernel.getAttribute(obname, "kernelFullyStarted") - sachin On Jan 30, 2006, at 6:08 AM, Vincent Massol wrote: Hi, Is there an API that I can use from a java program to ask G whether it has finished starting? Thanks -Vincent
RE: Knowing when G is started?
Thanks Aaron and Sachin. I’ll try your suggestions. -Vincent From: Sachin Patel [mailto:[EMAIL PROTECTED] Sent: lundi 30 janvier 2006 14:32 To: dev@geronimo.apache.org Subject: Re: Knowing when G is started? There is an attributed that gets passed to each configuration when all configurations have started, you can check for it. This is what is being done in the eclipse plugin. You can call kernel.getAttribute(obname, "kernelFullyStarted") - sachin On Jan 30, 2006, at 6:08 AM, Vincent Massol wrote: Hi, Is there an API that I can use from a java program to ask G whether it has finished starting? Thanks -Vincent
[jira] Created: (GERONIMO-1555) Refactor web module builders
Refactor web module builders Key: GERONIMO-1555 URL: http://issues.apache.org/jira/browse/GERONIMO-1555 Project: Geronimo Type: Improvement Components: web Environment: All Reporter: anita kulshreshtha Priority: Minor After the patches for G-1035 are incorporated, refactor TomcatModuleBuilder and JettyModuleBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Contributors permission in JIRA
Dain, Here is my request for geronimo-contributor privileges. Do I enough karma? Thnaks Anita --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Since on one objected, I added a > geronimo-contributers group that can > assign, resolve and be assigned issues. If this is > becomes an issue > the group can be removed just as easily as it was > added. > > If you are a contributor (i.e. you have submitted > some patches) and > would like to be able to be assigned issues, let us > know and we can > grant you karma. Please, only ask if you have > actually contributed > and need the ability to work on issues. > > Thanks, > > -dain > > On Oct 28, 2005, at 11:11 AM, Dain Sundstrom wrote: > > > I'd like to create a geronimo-contributors group > in jira. We would > > give contributors permission to assign, move, and > resolve issues > > but not close them. This will let the committers > know what > > everyone is working on, and will hopefully help > those working on > > earning commit get used to JIRA. > > > > What do you think? > > > > -dain > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMODEVTOOLS-55) Update build to use Eclipse 3.1.2 and EMF 2.1.2
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55?page=comments#action_12364459 ] Sachin Patel commented on GERONIMODEVTOOLS-55: -- You're correct, I was thinking 3.2. > Update build to use Eclipse 3.1.2 and EMF 2.1.2 > --- > > Key: GERONIMODEVTOOLS-55 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-55 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Environment: Eclipse 3.1 > Reporter: Donald Woods > Assignee: Sachin Patel > Attachments: DevTools-55.patch > > Eclipse 3.1.2 and EMF 2.1.2 have been released. > The following recent update - > Revision: 373210 Author: sppatel Date: 1:41:36 PM, Saturday, January 28, > 2006 Message: committers build > uses WTP build M200601281544, which lists Eclipse 3.1.2 and EMF 2.1.2 as the > prereqs to use this build level - > http://download.eclipse.org/webtools/committers/drops/M-M200601281544-200601281544/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1503) keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners
[
http://issues.apache.org/jira/browse/GERONIMO-1503?page=comments#action_12364456
]
Vamsavardhana Reddy commented on GERONIMO-1503:
---
Q: Does this patch fix the Jetty problem that if an empty String is specified
it is treated as null (and presumably does not work)?
A: NO. HTTPS Connector portlet does not allow specifying empty string as
password. In the Connector portlet, if password fields are left empty, it is
treated as either "password not specified" or "password not being changed"
(incase of edit) and the corresponding member is not set/replaced in the
Connector object. If Connector portlet needs to allow empty string for
passwords, it needs some work. We will have to forgo some conventions like
"password field left empy means password is not being changed" etc.
Q: is there a change needed to the Keystore portlet to use the new GBean
parameter?
A: NO. No passwords are passed between the portlet and the KeyStoreGBean. So,
Keystore portlet does not need to be changed.
Q: after applying the patch, can the keystore generated by the portlet be used
by both Tomcat and Jetty HTTPS connectors?
A: YES. configs/console-tomcat/src/plan/plan.xml makes sure that
keystorePassword and keyPassword are the same.
configs/console-jetty/src/plan/plan.xml specifies a non-empty string as
keyPassword.
> keystore generated by KeyStore portlet could not be used to add either Jetty
> or Tomcat HTTPS Listeners
> --
>
> Key: GERONIMO-1503
> URL: http://issues.apache.org/jira/browse/GERONIMO-1503
> Project: Geronimo
> Type: Bug
> Components: console, security, Tomcat, web
> Versions: 1.0
> Environment: WinXP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
> Fix For: 1.0.1, 1.1
> Attachments: GERONIMO-1503.patch
>
> ssl-keystore-1 generated by KeyStore portlet could not be used to add either
> Jetty or Tomcat HTTPS Listeners. Steps to regenerate this error.
> 1. Start Geronimo server
> 2. Using KeyStore portlet in Geronimo Console, generate keypair.
> ("ssl-keystore-1" file is created in this step)
> 3. Using WebServers portlet, add a new HTTPS Listener. Enter
> "var/security/ssl-keystore-1" in the keystore field in this step.
> The new HTTPS Listener fails to start.
> The following exception is logged when attempting to add a Jetty HTTPS
> Listener.
> 21:20:05,942 WARN [SslListener] EXCEPTION
> java.security.UnrecoverableKeyException: Cannot recover key
> at sun.security.provider.KeyProtector.recover(KeyProtector.java:301)
> at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:120)
> at java.security.KeyStore.getKey(KeyStore.java:289)
> at com.sun.net.ssl.internal.ssl.X509KeyManagerImpl.(DashoA12275)
> at
> com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl.engineInit(DashoA12275)
> at javax.net.ssl.KeyManagerFactory.init(DashoA12275)
> at org.mortbay.http.SslListener.createFactory(SslListener.java:262)
> at org.mortbay.http.SslListener.newServerSocket(SslListener.java:283)
> at org.mortbay.util.ThreadedServer.open(ThreadedServer.java:477)
> at
> org.apache.geronimo.jetty.connector.JettyConnector.doStart(JettyConnector.java:233)
> at
> org.apache.geronimo.jetty.connector.HTTPSConnector.doStart(HTTPSConnector.java:128)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537)
> at
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365)
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
> at
> org.apache.geronimo.jetty.JettyWebConnector$$EnhancerByCGLIB$$e76cef7.startRecursive()
> at
> org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:143)
> at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
> at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
> at
> org.apache.
Re: Knowing when G is started?
There is an attributed that gets passed to each configuration when all configurations have started, you can check for it. This is whatis being done in the eclipse plugin. You can call kernel.getAttribute(obname, "kernelFullyStarted") - sachin On Jan 30, 2006, at 6:08 AM, Vincent Massol wrote:Hi,Is there an API that I can use from a java program to ask G whether it hasfinished starting?Thanks-Vincent
Re: Multiple servers sharing the same repo and config store
This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config stores, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is "writable" at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks <[EMAIL PROTECTED]> wrote: > Many people have talked on and off about how to set up multiple > servers sharing the same repository and config-store, but we haven't > arrived at an agreed on way to do it. We have a prospective customer > for this feature (Vincent Massol with Cargo) so I'd like to move > beyond thinking about it in my head, discuss it, and have someone > implement it. I believe any implementation will be more or less > trivial, the hard part is figuring out what to do. > > I've only thought of ways to extend what we have now, rather than > restructure anything or add big new capabilities. If someone sees a > better way, please speak up. > > So, we have a ServerInfo gbean that knows where geronimo is located > and can resolve absolute locations for other components. Then we > have things like the repository and config store gbeans that > typically are "located" outside the var dir and things like the > logging framework, local attribute manager, derby, and tomcat, that > typically keep stuff in the var directory. > > All or most of these start with the first configuration loaded so > they can't have any attributes overridden by config.xml: in fact this > file is read by one of the gbeans that we need to "relocate". > > I've thought of two related solutions. Both of them involve giving > ServerInfo knowledge of another path and another resolve method. > > One would be something like "resolveVar" and would normally resolve > to geronimo_home/var. This would involve all the gbeans currently > looking inside var having the "var" trimmed off the front of their > paths and using the new resolveVar method. In this case we'd have > different servers represented as e.g. > var1 > var2 > var3 > ... > > > The other would give ServerInfo something like resolveServer which > would normally resolve to geronimo_home. The gbeans looking inside > var would keep their current paths and just call the new resolve > method instead of the old one. In this case we'd have servers like > var > server1/var > server2/var > ... > > In either case I think starting geronimo with a command line argument > pointing to the var directory is the only way to specify which server > you want to run; the default would presumably be as now "var". > > Several people have suggested putting an additional config-store into > var for "private" use by a particular server. At the moment I think > that providing a different config-store class that uses the new > resolve method on server info would be the best way to do this. > > > I'm not attached to these ideas but this is as far as my thinking has > gone. Please comment. > > thanks > david jencks > > >
Re: Knowing when G is started?
Hi Vincent, Yes, there is. There are more then one, actually. It depends on what you're talking to. The most common API is to use JMX Remoting via maven plugin or stripping out the Maven layers - doing it programatically. Take a look at plugins/geronimo-deployment-plugin or read it http://wiki.apache.org/geronimo/Running. Example: I'm also sure you can find something more direct in the kernel or system modules, esp. in their unit tests. Jacek 2006/1/30, Vincent Massol <[EMAIL PROTECTED]>: > Hi, > > Is there an API that I can use from a java program to ask G whether it has > finished starting? > > Thanks > -Vincent > > -- Jacek Laskowski http://www.laskowski.org.pl
Re: [vote] XBean donation
James Strachan wrote: On 29 Jan 2006, at 18:50, Dain Sundstrom wrote: On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote: +1 I assume this will just be a regular subproject at present. If one of the XBean folks could talk a little about how XBean could ultimately be adopted by Geronimo (the app server), that would be great. I think we talked about ways that Geronimo and XBean could move to close the gap and thus eventually make it possible to for Geronimo to adopt XBean without it being such a massive change, but I'm a little fuzzy on the details. Thanks, Aaron You're a bit fuzzy on the detail because every is a bit fuzzy. I have a few idea about how to integrate the code, but we're not going to know exactly how the integration will work or if we want to do it at all until we try. Just wanted to drop a warning before jumping into my ideas. XBean has several modules most of which are designed for direct XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to only address the kernel and server module. The kernel in XBean has a very light weight kernel compared to the Geronimo kernel. For example, the Geronimo kernel directly supports object name queries, and in XBean name querying is an optional service. The other big difference is the code is just easier to follow :) *If* we decide to switch to the XBean kernel, we can easily create an implementation of the current Geronimo kernel interface that simply calls through to the XBean kernel. I had this working with the XBean 1.0 kernel, but haven't written a bridge for the 2.0 kernel yet. The server module is more tricky. The server module contains simplified start up code, support for spring based configurations and some experimental class loaders. All of these will take work to determine if they are beneficial to Geronimo and if so, how to integrate them with out breaking current users. I think that more importantly than integrating the code is integrating the ideas in the server module. For example, the startup code in XBean would allow us to eliminate the serialized object graph in the our startup jars, which contain important attributes that we can't edit. Agreed. I think once we import the code into an xbean module we can start experimenting with a cleaner & more lightweight POJO based kernel/ server/deployer that avoids much of the GBean plumbing. e.g. I'd love a real simple way to define classloader hierarchies and to auto- deploy & redeploy spring.xml & xbean.xml files inside those class loaders as a nice simple Spring/POJO container. This sounds like my dreams come true - I can't wait :-) Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
[jira] Unassigned Patches: week of 01-30-2006
Project: Apache Geronimo Status: Open Assignee: Unassigned Geronimo Info: Patch Available Total: 20 items DATE UPDATED KEY SUMMARY Dec 18 2005 - GERONIMO-1381 - [Daytrader] Removed unused code Dec 22 2005 - GERONIMO-1400 - modularize daytrader deployment plan Jan 3 2006 - GERONIMO-1413 - Console needs to set JSP and Servlet contentType to UTF-8 Jan 3 2006 - GERONIMO-1414 - Console About page does not set the shortcut icon Jan 4 2006 - GERONIMO-1418 - allow user to specify deployment targets by "nickname" Jan 5 2006 - GERONIMO-1419 - javax.mail.internet.InternetHeaders has some non implemented features Jan 6 2006 - GERONIMO-1392 - update "additional samples" redirect in geronimo website Jan 8 2006 - GERONIMO-1260 - simplify construction of the combined deployment plan: deployment plan template and preprocessor Jan 9 2006 - GERONIMO-1163 - improve jmx debug console Jan 14 2006 - GERONIMO-1453 - GBeanOverride throws NullPointerException when more than one reference element specified Jan 19 2006 - GERONIMO-1498 - DriverDownloader.DriverInfo causes java.io.NotSerializableException during server shutdown Jan 19 2006 - GERONIMO-1499 - Daytrader: uncomment the drop table statements in daytrader.sql Jan 19 2006 - GERONIMO-1501 - Daytrader: remove hardcoded dependency versions in project.xml Jan 23 2006 - GERONIMO-1534 - Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db Jan 26 2006 - GERONIMO-1037 - Clicking on "uninstall" link in Applications management pages deletes the configuration without any confirmation from user Jan 26 2006 - GERONIMO-1503 - keystore generated by KeyStore portlet could not be used to add either Jetty or Tomcat HTTPS Listeners Jan 27 2006 - GERONIMO-1341 - POP3 Implementation Jan 28 2006 - GERONIMO-1544 - Installer - Straighten out licensing issues for IzPack sub-components. Jan 28 2006 - GERONIMO-1527 - InternetAddress does not properly implement address parsing. Jan 30 2006 - GERONIMO-1554 - Installer - Move advanced features to non-default installer path (simplify default installation)
Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
James Strachan wrote: On 30 Jan 2006, at 11:00, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:29, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Agreed - but in the case of a distributed session, it may not be mapped to a database - I guess we are not a typical JCache scenario ? Exactly. JCache is usually used for distributed caching of persistent state. So for most users of JCache, pessimistic locking has no real value. The exception to this rule is for folks who want to use JCache as a database (being the master copy of the state) which is usually as a result of folks trying to solve the distributed-session- state problem. But its much better IMHO to just solve the distributed session state problem correctly than turn JCache into a database :) not sure that I follow you here - so you are saying 'don't use jcache for distributed sessions' ? - or am I misunderstanding ? How would you 'solve the distributed session state problem correctly' ? I'm saying that reusing JCache as a database to solve the distributed session state problem is more a case of trying to find a problem to reuse a solution rather than actually trying to find the best solution to the problem (quite a common occurrence in IT). If you have a hammer all problems look like nails to be bashed. Sure you could use JCache for the distributed session problem, just as you could use a database - but its not necessarily the best solution, depending on your requirements; there are leaky abstractions in there. As usual in IT, it depends on exactly which distributed-state-problem you are trying to solve and what your requirements are. e.g. I'd hope WADI was a better solution to the distributed session problem than just using JCache as WADI is designed as a solution to the problem; JCache is designed for the distributed caching of (usually persistent or expensive-to-generate) state. Good - we agree then :-) So, I guess I need to roll back a little on the WADI/AS convergence thing and then move forward again in a slightly different direction... Rather than a 'Meet' reusing a Cache, we should consider sharing components/fn-ality at a lower level, where the difference between a Mapped item and an Unmapped one is not significant. Being able to use WADI's PartitionManager in AS, or AS' transaction support in WADI would be two potential benefits here... Though rather like messaging; there's a zillion ways of solving the problem; which is why I'm a big fan of nice simple, abstract APIs to specific technology problems so that implementation diversity can be hidden behind the API. (e.g. the JMS API for messaging, the Session API for distributed state management and JCache for distributed caching) Sure, understood. Thanks for the clarification. Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
On 30 Jan 2006, at 11:00, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:29, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Agreed - but in the case of a distributed session, it may not be mapped to a database - I guess we are not a typical JCache scenario ? Exactly. JCache is usually used for distributed caching of persistent state. So for most users of JCache, pessimistic locking has no real value. The exception to this rule is for folks who want to use JCache as a database (being the master copy of the state) which is usually as a result of folks trying to solve the distributed-session- state problem. But its much better IMHO to just solve the distributed session state problem correctly than turn JCache into a database :) not sure that I follow you here - so you are saying 'don't use jcache for distributed sessions' ? - or am I misunderstanding ? How would you 'solve the distributed session state problem correctly' ? I'm saying that reusing JCache as a database to solve the distributed session state problem is more a case of trying to find a problem to reuse a solution rather than actually trying to find the best solution to the problem (quite a common occurrence in IT). If you have a hammer all problems look like nails to be bashed. Sure you could use JCache for the distributed session problem, just as you could use a database - but its not necessarily the best solution, depending on your requirements; there are leaky abstractions in there. As usual in IT, it depends on exactly which distributed-state-problem you are trying to solve and what your requirements are. e.g. I'd hope WADI was a better solution to the distributed session problem than just using JCache as WADI is designed as a solution to the problem; JCache is designed for the distributed caching of (usually persistent or expensive-to-generate) state. Though rather like messaging; there's a zillion ways of solving the problem; which is why I'm a big fan of nice simple, abstract APIs to specific technology problems so that implementation diversity can be hidden behind the API. (e.g. the JMS API for messaging, the Session API for distributed state management and JCache for distributed caching) James --- http://radio.weblogs.com/0112098/
Knowing when G is started?
Hi, Is there an API that I can use from a java program to ask G whether it has finished starting? Thanks -Vincent
RE: Multiple servers sharing the same repo and config store
Big +1 to either :-) Thanks David -Vincent > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: lundi 30 janvier 2006 08:23 > To: dev@geronimo.apache.org > Subject: Multiple servers sharing the same repo and config store > > Many people have talked on and off about how to set up multiple > servers sharing the same repository and config-store, but we haven't > arrived at an agreed on way to do it. We have a prospective customer > for this feature (Vincent Massol with Cargo) so I'd like to move > beyond thinking about it in my head, discuss it, and have someone > implement it. I believe any implementation will be more or less > trivial, the hard part is figuring out what to do. > > I've only thought of ways to extend what we have now, rather than > restructure anything or add big new capabilities. If someone sees a > better way, please speak up. > > So, we have a ServerInfo gbean that knows where geronimo is located > and can resolve absolute locations for other components. Then we > have things like the repository and config store gbeans that > typically are "located" outside the var dir and things like the > logging framework, local attribute manager, derby, and tomcat, that > typically keep stuff in the var directory. > > All or most of these start with the first configuration loaded so > they can't have any attributes overridden by config.xml: in fact this > file is read by one of the gbeans that we need to "relocate". > > I've thought of two related solutions. Both of them involve giving > ServerInfo knowledge of another path and another resolve method. > > One would be something like "resolveVar" and would normally resolve > to geronimo_home/var. This would involve all the gbeans currently > looking inside var having the "var" trimmed off the front of their > paths and using the new resolveVar method. In this case we'd have > different servers represented as e.g. > var1 > var2 > var3 > ... > > > The other would give ServerInfo something like resolveServer which > would normally resolve to geronimo_home. The gbeans looking inside > var would keep their current paths and just call the new resolve > method instead of the old one. In this case we'd have servers like > var > server1/var > server2/var > ... > > In either case I think starting geronimo with a command line argument > pointing to the var directory is the only way to specify which server > you want to run; the default would presumably be as now "var". > > Several people have suggested putting an additional config-store into > var for "private" use by a particular server. At the moment I think > that providing a different config-store class that uses the new > resolve method on server info would be the best way to do this. > > > I'm not attached to these ideas but this is as far as my thinking has > gone. Please comment. > > thanks > david jencks
Re: [vote] XBean donation
On 29 Jan 2006, at 18:50, Dain Sundstrom wrote: On Jan 27, 2006, at 1:11 PM, Aaron Mulder wrote: +1 I assume this will just be a regular subproject at present. If one of the XBean folks could talk a little about how XBean could ultimately be adopted by Geronimo (the app server), that would be great. I think we talked about ways that Geronimo and XBean could move to close the gap and thus eventually make it possible to for Geronimo to adopt XBean without it being such a massive change, but I'm a little fuzzy on the details. Thanks, Aaron You're a bit fuzzy on the detail because every is a bit fuzzy. I have a few idea about how to integrate the code, but we're not going to know exactly how the integration will work or if we want to do it at all until we try. Just wanted to drop a warning before jumping into my ideas. XBean has several modules most of which are designed for direct XBean users like Service-Mix, ActiveMQ and XFire, so I'm going to only address the kernel and server module. The kernel in XBean has a very light weight kernel compared to the Geronimo kernel. For example, the Geronimo kernel directly supports object name queries, and in XBean name querying is an optional service. The other big difference is the code is just easier to follow :) *If* we decide to switch to the XBean kernel, we can easily create an implementation of the current Geronimo kernel interface that simply calls through to the XBean kernel. I had this working with the XBean 1.0 kernel, but haven't written a bridge for the 2.0 kernel yet. The server module is more tricky. The server module contains simplified start up code, support for spring based configurations and some experimental class loaders. All of these will take work to determine if they are beneficial to Geronimo and if so, how to integrate them with out breaking current users. I think that more importantly than integrating the code is integrating the ideas in the server module. For example, the startup code in XBean would allow us to eliminate the serialized object graph in the our startup jars, which contain important attributes that we can't edit. Agreed. I think once we import the code into an xbean module we can start experimenting with a cleaner & more lightweight POJO based kernel/ server/deployer that avoids much of the GBean plumbing. e.g. I'd love a real simple way to define classloader hierarchies and to auto- deploy & redeploy spring.xml & xbean.xml files inside those class loaders as a nice simple Spring/POJO container. James --- http://radio.weblogs.com/0112098/
Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
James Strachan wrote: On 30 Jan 2006, at 10:29, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Agreed - but in the case of a distributed session, it may not be mapped to a database - I guess we are not a typical JCache scenario ? Exactly. JCache is usually used for distributed caching of persistent state. So for most users of JCache, pessimistic locking has no real value. The exception to this rule is for folks who want to use JCache as a database (being the master copy of the state) which is usually as a result of folks trying to solve the distributed-session-state problem. But its much better IMHO to just solve the distributed session state problem correctly than turn JCache into a database :) not sure that I follow you here - so you are saying 'don't use jcache for distributed sessions' ? - or am I misunderstanding ? How would you 'solve the distributed session state problem correctly' ? thanks for the clarification, Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: [vote] XBean donation
+1 On 27 Jan 2006, at 20:08, Dain Sundstrom wrote: The XBean project has voted to donate all of the code located at https://svn.codehaus.org/xbean (view with fisheye http:// cvs.codehaus.org/viewrep/xbean) to Apache Geronimo. The completed IP clearance check list can be found here https://svn.codehaus.org/ xbean/xbean-ip-clearance.html [+1/-1/0] Accept the XBean code donation -dain James --- http://radio.weblogs.com/0112098/
Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
On 30 Jan 2006, at 10:29, Jules Gosnell wrote: James Strachan wrote: On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Agreed - but in the case of a distributed session, it may not be mapped to a database - I guess we are not a typical JCache scenario ? Exactly. JCache is usually used for distributed caching of persistent state. So for most users of JCache, pessimistic locking has no real value. The exception to this rule is for folks who want to use JCache as a database (being the master copy of the state) which is usually as a result of folks trying to solve the distributed-session-state problem. But its much better IMHO to just solve the distributed session state problem correctly than turn JCache into a database :) James --- http://radio.weblogs.com/0112098/
login-service refactoring: uniform treatment for the default principal
In login-service re-factoring, I'd like to unify treatment of the default principal. Default principal should be designated by a role, not as an instance of a principal; To find an instance of a default-principal find a principal that is mapped to a role that has 'run-as' attribute set to true (same as 'run-as' principal) Default (and run-as) principal should be logged in as any other principal; Login service will create a subject with all types of principals that are applicable to the specified security realm and login domain; (Currently this is done by utility code, not login service) You would not be able to insert a subject into the context unless subject is authenticated (contains valid identification principal). Authentication of a default (run-as) principal can be done in several ways; Most obvious is to specify authentication credential when mapping default (run-as) principal; (There are other ways such that you do not have to specify credentials at all (later)). I looked at interceptors and it seems that default-principal is either passed in, or subject for the default principal is passed in; So interceptors can either perform default-principal (run-as) authentication or have default (run-as) subject passed in that is already authenticated; Then an interceptor can insert default (run-as) principal into context without any additional steps; It looks like interceptor code could be optimized so it does not login default (run-as) principals more than once; Comments? Simon
Re: [wadi-dev] Re: Clustering - WADI/ActiveSpace Synergy...
James Strachan wrote: On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Agreed - but in the case of a distributed session, it may not be mapped to a database - I guess we are not a typical JCache scenario ? Optimistic locks are much more efficient & useful in a distributed caching system (which is why we implemented them in ActiveSpace). Though using the PartitionManager as a way of implementing a sparse cache is a good endevour. Incidentally ehcache has support for distributed caching now... http://ehcache.sourceforge.net/ I will revisit it ... Maybe we can persuade the ehcache team to adopt the JCache API and plug in any distributed strategies or sparse caching strategies into that. (ActiveSpace was using the RI of JCache which is less functional than ehcache) Sounds like an idea :-) Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: Clustering - WADI/ActiveSpace Synergy...
On 30 Jan 2006, at 10:06, Jules Gosnell wrote: Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location- independance, with a pessimistic approach and/or a partitioned clustering substrate... BTW I don't see using a pessimistic lock as being very useful for a cache; typically in a JCache scenario you are caching state that is stored in some database/system; so if you really want a pessimistic lock you should lock the database (they are very good at doing distributed locks) rather than having a pessimistic lock in a cache which is a different lock to where the actual data is. Optimistic locks are much more efficient & useful in a distributed caching system (which is why we implemented them in ActiveSpace). Though using the PartitionManager as a way of implementing a sparse cache is a good endevour. Incidentally ehcache has support for distributed caching now... http://ehcache.sourceforge.net/ Maybe we can persuade the ehcache team to adopt the JCache API and plug in any distributed strategies or sparse caching strategies into that. (ActiveSpace was using the RI of JCache which is less functional than ehcache) James --- http://radio.weblogs.com/0112098/
Re: web clustering componentization
James Strachan wrote: On 30 Jan 2006, at 09:24, Jules Gosnell wrote: Dain Sundstrom wrote: On Jan 27, 2006, at 10:54 AM, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:20, Jules Gosnell wrote: Dain, David is talking about how SessionManagers (effectively extended SessionFactories) should be plumbed into Geronimo (i.e. GBeans), not about the API's describing Sessions themselves. I've looked at the stuff in modules/session - it looks very similar to some WADI internals - there is loads of overlap here. I have some serious plans for converging WADI with ActiveSpace and would be happy to consider further changes to reuse or contribute to your sessions module. We should talk. I'll jot my ideas down and post them shortly. How about just implementing the Session APi directly using WADI? :) That's something that we could look at. I'd be interested to hear you plans for actually integrating the sessions with some container (web, ejb, etc...) as well - WADI is already doing this. Did you have a route in mind ? My plans extend to EJB integration, We already have one well under way... Where? and I think James is going integrate this into lingo and service mix, but I also think the API will work for servlet. I'm going to look more closely at it today Cool I am quite interested in seeing a single API for session management (not all of clustering just session management) I'm not clear here - you mean a single API for Session Clustering - yes ? This is also one of WADI's goals... Please take a look at the API; its a simple API designed for end users wanting to integrate some implementation of session management into a container; it hides all the details of how a session management solution might actually work. Make sure you read the documentation in the javadoc; we've tried to document it and make it totally obvious how to use it. As I've said several times recently, it should be pretty trivial to implement the session API using WADI. Also note that there can be many implementations of session management depending on requirements - e.g. just use a database. I had a quick look at it last week - I will give it a closer look this week. Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: web clustering componentization
James Strachan wrote: On 30 Jan 2006, at 09:13, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:54, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:20, Jules Gosnell wrote: Dain, David is talking about how SessionManagers (effectively extended SessionFactories) should be plumbed into Geronimo (i.e. GBeans), not about the API's describing Sessions themselves. I've looked at the stuff in modules/session - it looks very similar to some WADI internals - there is loads of overlap here. I have some serious plans for converging WADI with ActiveSpace and would be happy to consider further changes to reuse or contribute to your sessions module. We should talk. I'll jot my ideas down and post them shortly. How about just implementing the Session APi directly using WADI? :) That's something that we could look at. I'd be interested to hear you plans for actually integrating the sessions with some container (web, ejb, etc...) as well - WADI is already doing this. WADI is doing this for web only; the Session API is designed as a client API to use for OpenEJB, Lingo, ServiceMix, Tuscany et al. i.e. the containers would use the API directly. err - wrong :-) WADI already has various tier-independant abstractions and a partial working OpenEJB integration )for SFSBs - Gianny Damour Where does this live? Its news to me. Gianny Damour has been working on it. On the WADI side, our Contextualiser interface now takes a tier independant InvocationContext object and we have a WebInvocationContext impl. I think that the rest of it is checked into the Geronimo repo - see ./openejb/modules/core/src/java/org/openejb/cluster - Gianny has an EJBInvocationContext etc... I know that Gianny has successfully migrated SFSBs from one node to another, but I'm not sure how far he has got with client side proxies etc... which have been discussed in various clustering threads on geronimo-dev. I am pretty sure that I have mentioned the WADI/OpenEJB integration before on geronimo-dev. WADI is definitely suggested as one possible solution for SFSBs in the clustering doc that I posted recently ) and I am talking to Rajith Attapattu about Sessions for a number of Web Service transports. So, I think we need to figure out how to draw these two divergent threads together. I will look more closely at your API and consider how WADI might implement them. Long-term, I intend for WADI to converge closely with ActiveSpace. Are you intending to use this Session API with AS ? or do you have other plans ? I'm not really considering distributed caching or POJO abstractions to distributed programming in this thread; its a completely different problem. From Dain's posting my understanding was that your API was for clustered sessions - maybe it is just for any Session ? If so, no problem, I just need to understand what it is intended for so that WADI can do the right thing. I have posted details of AS/WADI synergy on another thread... Jules James --- http://radio.weblogs.com/0112098/ -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Clustering - WADI/ActiveSpace Synergy...
My understanding of ActiveSpace is that it supports two state clustering abstractions : - Cache - a Map-like API - Space - a JavaSpace like paradigm (also allowing a pub/sub model) WADI provides a third model, I have been trying unsuccessfully, to think of a nice name for it - lets call it a 'Meet' (in WADI it is currently called a 'Contextualiser'). You give a Meet a Session ID and a self-contained Invocation (HttpReq/Res pair, OpenEJB Invocation, etc...). It guarantees that, if the Session is known, the Invocation will be run against it, but, importantly, it does not say anything about where in the cluster this may occur. i.e. Invocation and Session will 'meet' somewhere in the cluster. It is important to maintain location independance as this enables the cluster to decide for itself the most efficient way to get this done and opens up opportunities for state-balancing and intelligent invocation routing etc (customer prioritising etc...). Perhaps this model can be implemented on top of a CacheCommand? If so, we don't really need the 'Meet' - it just becomes syntactic sugar. So, it should be fairly simple to implement a LocalMeet, i.e. a Meet where the Invocation is always run locally, by throwing the Meet API around an ActiveSpace Cache - as this will always migrate the Session to the Invocation. This would be worthwhile, because we would be able to plug e.g. an AS ClusteredCache straight into Jetty/Tomcat/OpenEJB, using WADI as the integration. We will also get Transactions, via AS' TransactionalCache. WADI's current implementation of a Meet implements a form of partitioned cache. The benefit of this is that a cluster can support more sessions than can be held on any single node (a constraint that applies if every node holds a copy of every session). The downside is that this approach is much more complex. By implementing a LocalMeet on top of AS Cache impls, we can quickly provide a simpler impl than WADI's default, which is able to immediately fill demand in smaller sized clusters, whilst we continue to work on the large-scale solution in WADI. The final difference between WADI and and AS (impl) is that WADI locks pessimistically, whereas, my understanding is that, existing AS impls lock optimistically (I understand that the AS API does not mandate any particular locking approach, but I am talking about impls available to us today). Provided that you can guarantee that all concurrent invocations will always land on the same node, an optimistic approach should be enough. In the web world, certain higher end http load blancers can provide this guarantee and in the EJB world, we can certainly do the same. This means that an AS based solution, integrated with various containers via WADI code, will, in many cases, be sufficient. Finally, as discussed with James on numerous occasions, we should look at how WADI's pessimistic locking and PartitionManager might be componentised so that they can be plugged into AS to provide Cache and Space users, who are not interested in location-independance, with a pessimistic approach and/or a partitioned clustering substrate... Jules -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: web clustering componentization
On 30 Jan 2006, at 09:24, Jules Gosnell wrote: Dain Sundstrom wrote: On Jan 27, 2006, at 10:54 AM, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:20, Jules Gosnell wrote: Dain, David is talking about how SessionManagers (effectively extended SessionFactories) should be plumbed into Geronimo (i.e. GBeans), not about the API's describing Sessions themselves. I've looked at the stuff in modules/session - it looks very similar to some WADI internals - there is loads of overlap here. I have some serious plans for converging WADI with ActiveSpace and would be happy to consider further changes to reuse or contribute to your sessions module. We should talk. I'll jot my ideas down and post them shortly. How about just implementing the Session APi directly using WADI? :) That's something that we could look at. I'd be interested to hear you plans for actually integrating the sessions with some container (web, ejb, etc...) as well - WADI is already doing this. Did you have a route in mind ? My plans extend to EJB integration, We already have one well under way... Where? and I think James is going integrate this into lingo and service mix, but I also think the API will work for servlet. I'm going to look more closely at it today Cool I am quite interested in seeing a single API for session management (not all of clustering just session management) I'm not clear here - you mean a single API for Session Clustering - yes ? This is also one of WADI's goals... Please take a look at the API; its a simple API designed for end users wanting to integrate some implementation of session management into a container; it hides all the details of how a session management solution might actually work. Make sure you read the documentation in the javadoc; we've tried to document it and make it totally obvious how to use it. As I've said several times recently, it should be pretty trivial to implement the session API using WADI. Also note that there can be many implementations of session management depending on requirements - e.g. just use a database. James --- http://radio.weblogs.com/0112098/
Re: web clustering componentization
On 30 Jan 2006, at 09:13, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:54, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:20, Jules Gosnell wrote: Dain, David is talking about how SessionManagers (effectively extended SessionFactories) should be plumbed into Geronimo (i.e. GBeans), not about the API's describing Sessions themselves. I've looked at the stuff in modules/session - it looks very similar to some WADI internals - there is loads of overlap here. I have some serious plans for converging WADI with ActiveSpace and would be happy to consider further changes to reuse or contribute to your sessions module. We should talk. I'll jot my ideas down and post them shortly. How about just implementing the Session APi directly using WADI? :) That's something that we could look at. I'd be interested to hear you plans for actually integrating the sessions with some container (web, ejb, etc...) as well - WADI is already doing this. WADI is doing this for web only; the Session API is designed as a client API to use for OpenEJB, Lingo, ServiceMix, Tuscany et al. i.e. the containers would use the API directly. err - wrong :-) WADI already has various tier-independant abstractions and a partial working OpenEJB integration )for SFSBs - Gianny Damour Where does this live? Its news to me. ) and I am talking to Rajith Attapattu about Sessions for a number of Web Service transports. So, I think we need to figure out how to draw these two divergent threads together. I will look more closely at your API and consider how WADI might implement them. Long-term, I intend for WADI to converge closely with ActiveSpace. Are you intending to use this Session API with AS ? or do you have other plans ? I'm not really considering distributed caching or POJO abstractions to distributed programming in this thread; its a completely different problem. James --- http://radio.weblogs.com/0112098/
Re: web clustering componentization
Dain Sundstrom wrote: On Jan 27, 2006, at 10:54 AM, Jules Gosnell wrote: James Strachan wrote: On 27 Jan 2006, at 18:20, Jules Gosnell wrote: Dain, David is talking about how SessionManagers (effectively extended SessionFactories) should be plumbed into Geronimo (i.e. GBeans), not about the API's describing Sessions themselves. I've looked at the stuff in modules/session - it looks very similar to some WADI internals - there is loads of overlap here. I have some serious plans for converging WADI with ActiveSpace and would be happy to consider further changes to reuse or contribute to your sessions module. We should talk. I'll jot my ideas down and post them shortly. How about just implementing the Session APi directly using WADI? :) That's something that we could look at. I'd be interested to hear you plans for actually integrating the sessions with some container (web, ejb, etc...) as well - WADI is already doing this. Did you have a route in mind ? My plans extend to EJB integration, We already have one well under way... and I think James is going integrate this into lingo and service mix, but I also think the API will work for servlet. I'm going to look more closely at it today I am quite interested in seeing a single API for session management (not all of clustering just session management) I'm not clear here - you mean a single API for Session Clustering - yes ? This is also one of WADI's goals... that we can all share and is neutral towards implementation. I expect we will see multiple implementations of the API from opensource (wadi, activecluster, ehcache, etc), ISVs (Tangosol, IBM, etc), and general JCache (JSR 107). cheers, Jules -dain -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
