[jira] Closed: (GERONIMO-791) Remove GBeanInstance support for J2EEManagedObject methods
[ http://issues.apache.org/jira/browse/GERONIMO-791?page=all ] Dain Sundstrom closed GERONIMO-791: --- Fix Version: 1.0-M5 Resolution: Fixed Deleting modules/kernel/src/java/org/apache/geronimo/gbean/GBeanLifecycleController.java Sending modules/kernel/src/java/org/apache/geronimo/gbean/runtime/GBeanInstance.java Sending modules/kernel/src/java/org/apache/geronimo/gbean/runtime/GBeanInstanceState.java Sendingmodules/kernel/src/test/org/apache/geronimo/kernel/GBeanTest.java Sending modules/kernel/src/test/org/apache/geronimo/kernel/MockEndpoint.java Sendingmodules/kernel/src/test/org/apache/geronimo/kernel/MockGBean.java Transmitting file data . Committed revision 225470. Remove GBeanInstance support for J2EEManagedObject methods -- Key: GERONIMO-791 URL: http://issues.apache.org/jira/browse/GERONIMO-791 Project: Geronimo Type: Bug Components: kernel Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Dain Sundstrom Fix For: 1.0-M5 The current GBean Framework provides support for the methods of J2EEManagedObject, meaning they're effectively implemented for every GBean regardless of whether the GBean itself implements them. This happens in GBeanInstace.addManagedObjectAttributes, and the attributes in question are: objectName (String, special) stateManageable (boolean, framework) statisticsProvider (boolean, framework) eventProvider (boolean, framework) These should be removed. If a GBean wants to implement J2EEManagedObject, it should provide its own implementation of this stuff. (It can get its ObjectName injected as a magic attribute.) -- 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-778) Geronimo XDoclet 1.2.2 module contribution
[ http://issues.apache.org/jira/browse/GERONIMO-778?page=comments#action_12316866 ] Bruce Snyder commented on GERONIMO-778: --- Why not just contribute this to the XDoclet project? I hazard a guess the XDoclet team might offer you committer status to keep working on it. Let it be built as part of XDoclet and Geronimo will simply be a consumer of it. There's no need for the G build to grab and build all of XDoclet. Geronimo XDoclet 1.2.2 module contribution -- Key: GERONIMO-778 URL: http://issues.apache.org/jira/browse/GERONIMO-778 Project: Geronimo Type: New Feature Reporter: John Sisson Assignee: John Sisson Priority: Minor Attachments: geronimo-xdoclet.zip In December 2004 I did done some work on XDoclet 1.2.2 support for Geronimo but did not get around to contributing it. Currently it supports the generation of the openejb-jar.xml file for session and message-driven beans. See the following mail thread for discussion on this contribution. http://marc.theaimsgroup.com/?t=11200245871r=1w=2 Note that there are a number of issues discussed below that need to be resolved before this is ready to be included with Geronimo releases. In other words, it isn't complete :-). How to build === 1. Download the appropriate (zip/tar) xdoclet-src-1.2.2 file from http://sourceforge.net/project/showfiles.php?group_id=31602: 2. Extract the xdoclet-src-1.2.2-* file you downloaded 3. Copy the geronimo directory (in the attached zip file) to the xdoclet-1.2.2\modules directory 4. Build the XDoclet code by running ant ( ant 1.5 works, later versions get an error) in the xdoclet-1.2.2 directory. After the build has completed the xdoclet-1.2.2\target\lib directory should contain xdoclet-geronimo-module-1.2.2.jar . 5. Generate the html documentation (it will be placed in the xdoclet-1.2.2\target\docs directory) by issuing the command maven site:generate in the xdoclet-1.2.2 directory. After the documentation has been generated you should be able to see the documentation for the geronimo XDoclet tags in the file xdoclet-1.2.2/target/docs/tags/geronimo-tags.html . Note that a link to the geronimo tags is not added to the main XDoclet page ( xdoclet-1.2.2/target/docs/index.html ) so it seems the link has to be added manually. Issues to discuss == * how to integrate into Geronimo build. Currently to build the Geronimo XDoclet module, it requires the XDoclet source code to be available. It may be possible to write some ant/maven build files that can build the geronimo XDoclet module without requiring the Xdoclet source code download (although I haven't seen any other projects build an XDoclet module this way yet). * create test application utilising the geronimo XDoclet tags * currently the configId attribute must be specified in the ant file when invoking the geronimo subtask. The configId value is placed in the generated plan. The parentId attribute can also be optionally specified. Is this the best way? See documentation in the file xdoclet-1.2.2/target/docs/ant/xdoclet/modules/geronimo/ejb/GeronimoSubTask.html . * the tag parameter names match the xml element names in the deployment plan, but for the parameters used to specify portions of jsr-77 object names (e.g. domain, server, application, module, ..), I have prefixed the parameter with objname- to make it clearer that they are part of a group. *Should the parameter names (e.g. the ref-name parameter of the @geronimo.resource-ref tag) should be more consistent with the parameters of the @ejb tags (e.g. the res-refname parameter of the @ejb.resource-ref tag). * Should we be trying to have unique parameter names so that it is easier to search for the particular parameter. For example, currently the ref-name parameter is used on the @geronimo.ejb-local-ref , @geronimo.ejb-ref and @geronimo.resource-ref tags. If we do change the parameter names to be unique it will mean the parameter names will no longer match the generated XML element names (this may make troubleshooting generated XML harder). Further work to be done the following contributions/help by others are welcome :-) : - Improvements to the tag documentation ( xdoclet-1.2.2/target/docs/tags/geronimo-tags.html ) - web support - web services support - entity beans support - GBeans support - Corba support - Testing with Eclipse WTP and other IDEs -- 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: Clustering (long)
Andy Piper wrote: Hi Jules It sounds like you've been working hard! yes - I need a break :-) I think you might find you run into reliability issues with a singleton coordinator. This is one of those well known Hard Problems and for session replication its not really necessary. In essence the coordinator is a single point of failure and making it reliable is provably non trivial. I agree on the SPoF thing - but I think you misunderstand my Coordinator arch. I do not have a single static Coordinator node, but a dynamic Coordinator role, into which a node may be elected. Thus every node is a potential Coordinator. If the elected Coordinator dies, another is immediately elected. The election strategy is pluggable, although it will probably end up being hardwired to oldest-cluster-member. The reason behind this is that relaying out your cluster is much simpler if it is done in a single vm. I originally tried to do it in multiple vms, each taking responsibility for pieces of the cluster, but if the vms views are not completely in sync, things get very hairy, and completely in sync is an expensive thing to achieve - and would introduce a cluster-wide single point of contention. So I do it in a single vm, as fast as I can, with fail over, in case that vm evaporates. Does that sound better than the scenario that you had in mind ? The Coordinator is not there to support session replication, but rather the management of the distributed map (map of which a few buckets live on each node) which is used by WADI to discover very efficiently whether a session exists and where it is located. This map must be rearranged, in the most efficient way possible, each time a node joins or leaves the cluster. Replication is NYI - but I'm running a few mental background threads that suggest that an extension to the index will mean that it associates the session's id not just to its current location, but also to the location of a number of replicants. I also have ideas on how a session might choose nodes into which it will place its replicants and how I can avoid the primary session copy ever being colocated with a replicant (potential SPoF - if you only have one replicant), etc... Cluster re-balancing is also a hairy issue in that its easy to run into cascading failures if you pro-actively move sessions when a server leaves the cluster. Yes, I can see that happening - I have an improvement (NYI) to WADI's evacuation strategy (how sessions are evacuated when a node wishes to leave). Each session will be evacuated to the node which owns the bucket into which its id hashes. This is because colocation of the session with the bucket allows many messages concered with its future destruction and relocation to be optimised away. Future requests falling elsewhere but needing this session should, in the most efficient case, be relocated to this same node, other wise the session may be relocated, but at a cost... I'm happy to talk more about these issues off-line if you want. I would be very grateful in any thoughts or feedback that you could give me. I hope to get much more information about WADI into the wiki over the next few weeks. That should help generate more discussion, although I would be more than happy for people to ask me questions here on Geronimo-dev because this will give me an idea of what documentation I should write and how existing documentation may be lacking or misleading. Please fire away, Jules Thanks andy At 02:31 PM 6/30/2005, Jules Gosnell wrote: Guys, I thought that it was high time that I brought you up to date with my efforts in building a clustering layer for Geronimo. The project, wadi.codehaus.org, started as an effort to build a scalable clustered HttpSession implementation, but in doing this, I have built components that should be useful in clustering the state held in any tier of Geronimo e.g. OpenEJB SFSBs etc. WADI (Web Application Distribution Infrastructure) has two main elements - the vertical and the horizontal. Vertically, WADI comprises a stack of pluggable stores. Each store has a pluggable Evicter responsible for demoting aging Sessions downwards. Requests arriving at the container are fed into the top of the stack and progress downwards, until their corresponding Session is found and promoted to the top, where the request is correctly rendered in its presence. Typically the top-level store is in Memory. Aging Sessions are demoted downwards onto exclusively owned LocalDisc. The bottom-most store is a database shared between all nodes in the Cluster. The first node joining the Cluster promotes all Sessions from the database into exclusively-owned store - e.g. LocalDisc. The last node to leave the Cluster demotes all Sessions down back into the database. Horizontally, all nodes in a WADI Cluster are connected (p2p) via a Clustered Store component within this stack. This typically sits at the boundary between exclusive
Re: GBeans: Saving Changes
I'm listening to this discussion and trying to make sense of it so that I can understand how it will affect our users. Keep in mind that I'm still grasping at the fundamentals of Geronimo and G-beans so this may be off in the weeds (and for which I will apologize for right now). As I think David Jencks mentioned earlier, are think there are different types of configuration data? Can we list some of the specific types of configuration items that we are talking about and group them? Perhaps that can simplify the problem. Here's my attempt: First, there is "configuration" which affects the structure of the solution itself (let's call it "solution configuration") ... such as changing the access protocol, changing the J2EE container, changing the security service, the persistent store, etc These are all changes that have substantial impact on the nature and behavior of the server. These are things that I would expect of somebody that is building a complete solution to be concerned with and I don't think it would be a problem if the changes were "maven-like" and required creating a new bundle (ie. not hosted in the admin console for runtime changes). Second, there is "configuration" which affects the behavior of the solution but not the nature of it (let's call this "server configuration"). These are more minor changes such as changing ports, hostnames, thread pool sizes, etc... This is standard end user configuration and items that I would expect an end user that is running a solution to have to "tweak" on a regular basis. These are types of configuration changes where I think it would be useful to be able to export and then later import the configuration for another server and that should be persisted apart from the Gbeans. This configuration may even include the set of deployed applications for the server. If we consider these items as being fundamentally different types of configuration with different users then I think it might simplify the problem. The "server configuration" changes should be available via the admin console and should not impact any G-Bean configuration as I understand it. The "solution configuration" would potentially affect the creation of and dependencies between Gbeans and would not necessarily require a WYSIWYG mechanism for change such as an admin console. Of course there will always be items in the "gray" area that are somewhere between these or may need to be changed by both types of users. Items in the "gray" area could be addressed on an individual basis such that it would not necessarily require mutable bundles (such as by defining both HTTP and HTTPS connectors and enabling or disabling as appropriate for the configuration). One final question I'll toss out (and possibly show my ignorance ... but at least I'll learn the answer :-) ) ... Aren't the applications that are deployed themselves represented by Gbeans in the bundle and therefore the bundle is already mutable in that sense? I read an article in JAX that indicated this was the case ( http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ). Is that correct or was the author mistaken? Aaron Mulder wrote: We're making progress! :) On Tue, 26 Jul 2005, Jeremy Boynes wrote: First caveat - o/a/g/Server is too monolithic which is contributing factor to these discussions. The reasons why this is a problem and how to start to fix it have been discussed elsewhere. True, though there are certain advantages too (like the ability to start and stop all that stuff with one command). Anyway, that's another topic. Second caveat, change through the web console is one use case. It applies to small installations (desktop, single server) but is less applicable to larger installations, say with 10 servers. It also does not apply to "headless" servers which may not be running a web container at all. Agreed. I have two I've given some thought to although they're not fully thought out - but hey, we're brainstorming right? Yes. Of the two, I like option 5 more -- and more than all the UUID-based options. I'm not sure the mutability needs to be reflected in the configuration name, though -- couldn't we have non-name properties for the version and mutability? That way the start/stop command would be the same and so on. You would refer to a prerequisite by providing the name and version range separately, and perhaps even indicating explicitly whether you're willing to depend on a mutable version. If you provide nothing but the name, that implies "any version will do". I'd propose we add a tool that can export one or more configurations named on the command line (or all current configs) and optionally: - mark them immutable - assign them a specific version or UUID - update any references between exported modules to use the new version number or UUID - include an explicit list of all their repository references if
What's a bundle?, was: GBeans: Saving Changes
Joe Bohn wrote: One final question I'll toss out (and possibly show my ignorance ... but at least I'll learn the answer :-) ) ... Aren't the applications that are deployed themselves represented by Gbeans in the bundle and therefore the bundle is already mutable in that sense? I read an article in JAX that indicated this was the case ( http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ). Is that correct or was the author mistaken? I just read the article and Srinath focuses more on GBeans themselves than on the bundle mechanism. There's a concept in Geronimo of a configuration bundle represented by an org.apache.geronimo.kernel.Configuration. What this represents is a collection of closely-coupled co-operating components that work together to provide a service. The server runtime is built up by assembling multiple bundles together to provide a coherent set of services that support a given programming model such as J2EE. In detail, a bundle comprises: * a set of dependencies which define the codebase for the bundle These dependencies, including a parent, define the set of classes available to the bundle and are used to define a ClassLoader for it. There are limitations to what is currently implemented and some well known improvements that should be made. * the set of components that are pre-wired to provide a specific service This is basically a list of GBeans based on their names and references between them * the default state for all those service providers This is basically the initial attribute values for those beans The bundle concept comes from recognizing that some services (like the HTTPS connector I described elsewhere) may be built up from multiple components. Users of the service don't want to know all the wiring details, they just want to deal with the service as a whole. What any particular runtime is doing is determined by which bundles are running. So we run a J2EE server by having it run a set of bundles that provide a J2EE environment - System, Server, SystemDatabase, ... One problem that we have is that the Server bundle is monolithic providing too many services; for example, it includes the web container and now we have two different implementations of that service (Jetty and Tomcat) they should be broken out into separate bundles. The runtime does not know anything about applications - all it deals with is how to run bundles (including setting up the environment a bundle needs to run (currently just its codebase dependencies)). What the deployer does is convert application level artifacts such as an EAR file into a bundle that the runtime can handle. So using hints from the deployment plan, it takes that EAR file, constructs GBeans for the individual components that it contains (like Servlets or EJBs), wires them together and packages them all up as a bundle. When/where you want to run that application, we load the bundle into the appropriate server instance and start it up. Each application running in the server is a separate bundle so we never mutate them. -- Jeremy
Bundle metadata, was: GBeans: Saving Changes
Aaron Mulder wrote: Of the two, I like option 5 more -- and more than all the UUID-based options. I'm not sure the mutability needs to be reflected in the configuration name, though -- couldn't we have non-name properties for the version and mutability? That way the start/stop command would be the same and so on. You would refer to a prerequisite by providing the name and version range separately, and perhaps even indicating explicitly whether you're willing to depend on a mutable version. If you provide nothing but the name, that implies any version will do. snipBecause I think this is a key issue and drives the rest/snip First a chunk of background to establish context, skip to +++ for the proposal. One of the problems we have is that the configuration management system is very naive - I kept the first version real simple to see how needs would drive it and, of course, its limitations are now coming back to bite us. It works on the assumption that all the information about a bundle can be captured in its unique id. So no matter how many services a bundle offers, all a user of those services needs to know is the bundle's id and if it references that those services will be there. This allows us to have a very basic system where dependencies get resolved based on ids alone. It got us this far but I think we're starting to hit the limitations. One thing we talked about from the start was a capability model where bundles advertised distinct services (versioned) and dependencies between bundles were resolved using those rather than just the basic id. So, for example, a web container could advertise jetty, jetty 5, jetty 5.1.4, servlet, servlet 2.4 etc. An application that needed a web container could require servlet 2.4 which would mean it could run in any instance no matter what implementation of servlet 2.4 was present (e.g. either Jetty or Tomcat) or it could require jetty 5.1.4 because perhaps it had specific classes that it was using. For example, a generic webapp may just need the servlet bits but one with a custom Valve would require a Tomcat based version. The intention was to build up an ever richer set of services that could be provided and consumed. In the end you would end up with very rich bundle descriptions such as I am a bundle that provides Acme Inc. Order Entry System V7.5.2 tuned for 100 concurrent users at 500ms reponse time and 40 operations per second on an Acme-4000 Linux system with a Harmony JVM, 4 4.2Ghz CPUs and 2GB RAM. I provide these web services (...) and EJBs (...). I need access to a Acme Inc. Order Entry Schema V7 via a JDBC 3.0 driver on a database tuned for 80 transactions per second and to the following JMS queues (...) capable of handling 20 messages per second. This captures not only the physical and logical requirements needed to run the application but also the environment characteristics that drive response time and throughput. With this in place, there starts to be sufficient information for the configuration manager to start to make intelligent decisions about where/when to run application bundles in order to meet business level service agreement targets. +++ The key to this whole thing is having sufficient metadata in place about the bundles, which ties back to your point at the start. I think it has become clear that we have progressed to the point where a simple unique id is insufficient and we need to start adding metadata. The first bits relate to temporal stability: adding in a version identifier and adding in an indicator that a bundle is temporally unstable (i.e. its a SNAPSHOT). We should add to that metadata about the services that a bundle provides and consumes. I think that at a minimum that comprises a service id, version and stablilty flag the same as for bundles themselves. If we do that first for codebase services (i.e. the classes that a bundle uses and provides) then we not only get a start on the metadata description side, we also fix the classloader issues that lead to monolithic bundles like o/a/g/Server. -- Jeremy
Re: What's a bundle?, was: GBeans: Saving Changes
Thanks Jeremy. That helps a lot. I think it also helps me understand how potentially different types of configuration data might be organized and managed (which I'd also like to hear some thoughts on too). IIUC then, any configuration that changes a GBean's persistent state in the server or other configuration data that is not part of the GBean dependency definitions is fine. However, any changes that would result in the addition/removal of a GBean within the server bundle or modification of a GBean's dependencies would not be permitted in an immutable server. That scopes the type of configuration changes then that would cause potential problems from an admin console to a much smaller set. Can we get more specific on those types of changes? crazy thinking A follow up question on the bundles and GBeans. Has there been thought given to defining a type of GBean and/or bundle that can act as an interface? Something such that o/a/g/server could have a dependency on a Servlet Container GBean/bundle but not necessarily on a particular implementation. Multiple implementation of the interface could be included in the image and the appropriate one would could be loaded based upon configuration choices. Another possibility (although this clobbers the notion of what a GBean is and so I expect is just crazy :-) ) could be to define less granular GBeans for these types of dependencies and the behavior of the GBean would vary based upon configuration choices (ie. a Servlet Container GBean that contains the necessary logic/classes for several containers but only activates one based upon some more dynamic configuration data). These would handle the case of server dependencies that must be fulfilled by a single implementation but don't address the case where multiple instances of the same type are required simultaneously by applications (such as with connectors). However, are these really part of the o/a/g/server or are they additive to the solution (just like applications even if not bundled directly with the applications as already proposed earlier in this thread)? /crazy thinking Jeremy Boynes wrote: Joe Bohn wrote: One final question I'll toss out (and possibly show my ignorance ... but at least I'll learn the answer :-) ) ... Aren't the applications that are deployed themselves represented by Gbeans in the bundle and therefore the bundle is already mutable in that sense? I read an article in JAX that indicated this was the case ( http://jaxmag.com/itr/online_artikel/psecom,id,690,nodeid,147.html ). Is that correct or was the author mistaken? I just read the article and Srinath focuses more on GBeans themselves than on the bundle mechanism. There's a concept in Geronimo of a configuration bundle represented by an org.apache.geronimo.kernel.Configuration. What this represents is a collection of closely-coupled co-operating components that work together to provide a service. The server runtime is built up by assembling multiple bundles together to provide a coherent set of services that support a given programming model such as J2EE. In detail, a bundle comprises: * a set of dependencies which define the codebase for the bundle These dependencies, including a parent, define the set of classes available to the bundle and are used to define a ClassLoader for it. There are limitations to what is currently implemented and some well known improvements that should be made. * the set of components that are pre-wired to provide a specific service This is basically a list of GBeans based on their names and references between them * the default state for all those service providers This is basically the initial attribute values for those beans The bundle concept comes from recognizing that some services (like the HTTPS connector I described elsewhere) may be built up from multiple components. Users of the service don't want to know all the wiring details, they just want to deal with the service as a whole. What any particular runtime is doing is determined by which bundles are running. So we run a J2EE server by having it run a set of bundles that provide a J2EE environment - System, Server, SystemDatabase, ... One problem that we have is that the Server bundle is monolithic providing too many services; for example, it includes the web container and now we have two different implementations of that service (Jetty and Tomcat) they should be broken out into separate bundles. The runtime does not know anything about applications - all it deals with is how to run bundles (including setting up the environment a bundle needs to run (currently just its codebase dependencies)). What the deployer does is convert application level artifacts such as an EAR file into a bundle that the runtime can handle. So using hints from the deployment plan, it takes that EAR file, constructs GBeans for the individual components that it
[jira] Created: (GERONIMO-821) Invalid sigantures in JavaMail API jar
Invalid sigantures in JavaMail API jar -- Key: GERONIMO-821 URL: http://issues.apache.org/jira/browse/GERONIMO-821 Project: Geronimo Type: Bug Components: specs Versions: 1.0-M4 Reporter: Jeremy Boynes Assigned to: Davanum Srinivas Priority: Blocker Fix For: 1.0-M4 Recent changes to the JavaMail API classes affect the package signatures: javax.mail.internet.MimeMultipart has an additional public inner class MimeBodyPartInputStream javax.mail.internet.ParameterList has an additional public method split(java.lang.String,char) -- 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] Created: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=comments#action_12316948 ] Dain Sundstrom commented on GERONIMO-823: - Why not allow them to override the default built in simple types? We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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] Created: (GERONIMO-822) Need more flexibility in interpreting jaxrpc mappings of ArrayOfFoo elements
Need more flexibility in interpreting jaxrpc mappings of ArrayOfFoo elements Key: GERONIMO-822 URL: http://issues.apache.org/jira/browse/GERONIMO-822 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.0-M5 The IBM jaxrpc-mapping file generator likes to produce things like this: java-xml-type-mapping java-typecom.ibm.websphere.samples.trade.OrderDataBean[]/java-type root-type-qname xmlns:rtq=http://trade.samples.websphere.ibm.com;rtq:ArrayOfOrderDataBean/root-type-qname qname-scopecomplexType/qname-scope variable-mapping java-variable-nameorderDataBean/java-variable-name xml-element-nameOrderDataBean/xml-element-name /variable-mapping /java-xml-type-mapping which we currently don't accept. The spec is silent on whether such a mapping should exist or its contents. It is certainly questionable what the variable-mapping element is supposed to mean, since the java-type is not a javabean. However, in the interests of portability we should endevour to accept such constructs and extract as much information as possible from them, ignoring the meaningless parts. -- 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] Created: (GERONIMO-824) MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
Key: GERONIMO-824
URL: http://issues.apache.org/jira/browse/GERONIMO-824
Project: Geronimo
Type: Bug
Components: OpenEJB
Versions: 1.0-M4, 1.0-M5, 1.0, 1.1
Reporter: Matt Hogstrom
org.openejb.deployment.MdbBuilder.java assigns null to the ListenerType if the
type cannot be determined. This causes runtime errors that are manifested in
the MdbContainerBuilder as Null Pointer Exceptions.
This fix assigns a type of javax.jms.MessageListener to the interface type as a
default.
Index: MdbBuilder.java
===
RCS file:
/home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java,v
retrieving revision 1.21
diff -r1.21 MdbBuilder.java
173c173,179
builder.setEndpointInterfaceName(OpenEJBModuleBuilder.getJ2eeStringValue(messageDrivenBean.getMessagingType()));
---
String messageInterfaceType = null;
if (messageDrivenBean.isSetMessagingType()) {
messageInterfaceType =
messageDrivenBean.getMessagingType().getStringValue().trim();
} else {
messageInterfaceType = javax.jms.MessageListener;
}
builder.setEndpointInterfaceName(messageInterfaceType);
--
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-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=comments#action_12316950 ] David Jencks commented on GERONIMO-823: --- Thanks for volunteering! For now I'll stick with what I think I can implement :-) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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-824) MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
[ http://issues.apache.org/jira/browse/GERONIMO-824?page=all ]
Aaron Mulder updated GERONIMO-824:
--
Fix Version: 1.0-M4
1.0-M5
Version: 1.0-M3
(was: 1.0-M4)
(was: 1.0-M5)
(was: 1.0)
(was: 1.1)
Please don't mark a bug as affecting versions that haven't been released yet.
To get on the road map, they need to be marked with a Fix Version of the
versions that haven't been released yet.
MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
Key: GERONIMO-824
URL: http://issues.apache.org/jira/browse/GERONIMO-824
Project: Geronimo
Type: Bug
Components: OpenEJB
Versions: 1.0-M3
Reporter: Matt Hogstrom
Fix For: 1.0-M4, 1.0-M5
org.openejb.deployment.MdbBuilder.java assigns null to the ListenerType if
the type cannot be determined. This causes runtime errors that are
manifested in the MdbContainerBuilder as Null Pointer Exceptions.
This fix assigns a type of javax.jms.MessageListener to the interface type as
a default.
Index: MdbBuilder.java
===
RCS file:
/home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java,v
retrieving revision 1.21
diff -r1.21 MdbBuilder.java
173c173,179
builder.setEndpointInterfaceName(OpenEJBModuleBuilder.getJ2eeStringValue(messageDrivenBean.getMessagingType()));
---
String messageInterfaceType = null;
if (messageDrivenBean.isSetMessagingType()) {
messageInterfaceType =
messageDrivenBean.getMessagingType().getStringValue().trim();
} else {
messageInterfaceType = javax.jms.MessageListener;
}
builder.setEndpointInterfaceName(messageInterfaceType);
--
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-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Blevins closed GERONIMO-823: -- Resolution: Fixed Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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
FW: JavaMail and JAF available as Open Source!
FYI. Do not cross-post replies. --- Noel -Original Message- From: A mailing list for discussion of the JavaMail(tm) API [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 14:28 To: [EMAIL PROTECTED] Subject: JavaMail and JAF available as Open Source! As we announced at JavaOne, Sun has released its J2EE (now called Java EE) application server as an open source project on java.net. The project is called GlassFish and you can find out more at http://glassfish.dev.java.net. GlassFish is available under the CDDL open source license. GlassFish contains JavaMail and JAF, so the source code for both is available under CDDL as well. GlassFish currently contains JAF 1.1ea and a version of JavaMail slightly newer than 1.3.3ea. Right now, JavaMail and JAF are only built as part of a GlassFish build. Eventually I hope to improve the build system so that the standalone releases of JavaMail and JAF can be built from the GlassFish source base. (Unfortunately, I have about 100 other more important things to do before I get to that.) Those of you looking for source code for debugging purposes, or with a need to improve JavaMail for your own use, should start with the GlassFish source. You'll need to be a java.net member and you'll need to accept the terms of the CDDL license, but note that CDDL is an OSI-approved Open Source license (it's the same license used by OpenSolaris, and a derivative of the Mozilla Public License) so you're free to use it in many ways that were previously restricted. If you make improvements to JavaMail or JAF, and would like give those improvements back to Sun (which you're not required to do), you'll need to sign a Sun Contributor Agreement so that we're sure you have to rights to give us what you're giving us. (Signing the SCA once allows you to contribute to any Sun open source project, including GlassFish, OpenSolaris, NetBeans, etc.) Note that improvements to the JavaMail and JAF APIs (the javax.* APIs) need to be approved by the JCP. Enjoy the latest JavaMail and JAF source, and please be patient as we transition our build and release processes to java.net. The JavaMail Team
Re: FW: JavaMail and JAF available as Open Source!
Is there a build in a Maven repo? Are we allowed to distribute it as part of Geronimo, given that it's under the CDDL? Thanks, Aaron On Wed, 27 Jul 2005, Noel J. Bergman wrote: FYI. Do not cross-post replies. --- Noel -Original Message- From: A mailing list for discussion of the JavaMail(tm) API [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 14:28 To: [EMAIL PROTECTED] Subject: JavaMail and JAF available as Open Source! As we announced at JavaOne, Sun has released its J2EE (now called Java EE) application server as an open source project on java.net. The project is called GlassFish and you can find out more at http://glassfish.dev.java.net. GlassFish is available under the CDDL open source license. GlassFish contains JavaMail and JAF, so the source code for both is available under CDDL as well. GlassFish currently contains JAF 1.1ea and a version of JavaMail slightly newer than 1.3.3ea. Right now, JavaMail and JAF are only built as part of a GlassFish build. Eventually I hope to improve the build system so that the standalone releases of JavaMail and JAF can be built from the GlassFish source base. (Unfortunately, I have about 100 other more important things to do before I get to that.) Those of you looking for source code for debugging purposes, or with a need to improve JavaMail for your own use, should start with the GlassFish source. You'll need to be a java.net member and you'll need to accept the terms of the CDDL license, but note that CDDL is an OSI-approved Open Source license (it's the same license used by OpenSolaris, and a derivative of the Mozilla Public License) so you're free to use it in many ways that were previously restricted. If you make improvements to JavaMail or JAF, and would like give those improvements back to Sun (which you're not required to do), you'll need to sign a Sun Contributor Agreement so that we're sure you have to rights to give us what you're giving us. (Signing the SCA once allows you to contribute to any Sun open source project, including GlassFish, OpenSolaris, NetBeans, etc.) Note that improvements to the JavaMail and JAF APIs (the javax.* APIs) need to be approved by the JCP. Enjoy the latest JavaMail and JAF source, and please be patient as we transition our build and release processes to java.net. The JavaMail Team
Re: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
Oops...my JIRA was 824 :) - Original Message - From: David Blevins (JIRA) dev@geronimo.apache.org To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 3:55 PM Subject: [jira] Closed: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file [ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Blevins closed GERONIMO-823: -- Resolution: Fixed Checked into OpenEJB by Matt Hogstrom. Closing the issue for him as he doesn't have Geronimo access. We should accept (and ignore) simple type mappings in a jaxrpc-mapping file -- - Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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-824) MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
[ http://issues.apache.org/jira/browse/GERONIMO-824?page=all ]
David Jencks closed GERONIMO-824:
-
Fix Version: (was: 1.0-M4)
Resolution: Fixed
Assign To: David Jencks
Should actually be assigned to Matt Hogstrom.
Fixed by patch above applied by matt, rev 1.22
I unified with fix for GERONIMO-780 and fixed a lot of getStringValue().trim()
issues, rev 1.23
I think we should consider applying this to M4
MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
Key: GERONIMO-824
URL: http://issues.apache.org/jira/browse/GERONIMO-824
Project: Geronimo
Type: Bug
Components: OpenEJB
Versions: 1.0-M3
Reporter: Matt Hogstrom
Assignee: David Jencks
Fix For: 1.0-M5
org.openejb.deployment.MdbBuilder.java assigns null to the ListenerType if
the type cannot be determined. This causes runtime errors that are
manifested in the MdbContainerBuilder as Null Pointer Exceptions.
This fix assigns a type of javax.jms.MessageListener to the interface type as
a default.
Index: MdbBuilder.java
===
RCS file:
/home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java,v
retrieving revision 1.21
diff -r1.21 MdbBuilder.java
173c173,179
builder.setEndpointInterfaceName(OpenEJBModuleBuilder.getJ2eeStringValue(messageDrivenBean.getMessagingType()));
---
String messageInterfaceType = null;
if (messageDrivenBean.isSetMessagingType()) {
messageInterfaceType =
messageDrivenBean.getMessagingType().getStringValue().trim();
} else {
messageInterfaceType = javax.jms.MessageListener;
}
builder.setEndpointInterfaceName(messageInterfaceType);
--
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-780) mdb builder needs jms message listener as default
[ http://issues.apache.org/jira/browse/GERONIMO-780?page=comments#action_12316982 ] David Jencks commented on GERONIMO-780: --- GERONIMO-824 is a second instance of the same problem. I don't know how I fixed one and not the other and thought I was done. Thanks to Matt for finding and fixing the second one. mdb builder needs jms message listener as default - Key: GERONIMO-780 URL: http://issues.apache.org/jira/browse/GERONIMO-780 Project: Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Assignee: David Jencks Fix For: 1.0-M4, 1.0-M5 message-listener may not be specified in the spec dd, it should default to jms MessageListener. -- 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] Reopened: (GERONIMO-823) We should accept (and ignore) simple type mappings in a jaxrpc-mapping file
[ http://issues.apache.org/jira/browse/GERONIMO-823?page=all ] David Jencks reopened GERONIMO-823: --- read carefully before closing, Matt fixed GERONIMO-824 We should accept (and ignore) simple type mappings in a jaxrpc-mapping file --- Key: GERONIMO-823 URL: http://issues.apache.org/jira/browse/GERONIMO-823 Project: Geronimo Type: Bug Components: webservices Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.0-M5 The IBM jaxrpc mapping generator likes to produce redundant unneccesary type mappings for built in simple types such as java-xml-type-mapping java-typejava.math.BigDecimal/java-type root-type-qname xmlns:rtq=http://www.w3.org/2001/XMLSchema;rtq:decimal/root-type-qname qname-scopesimpleType/qname-scope /java-xml-type-mapping The spec doesn't appear to mention or prohibit these. In the interests of portability we should ignore these rather than objecting to them. -- 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] Created: (GERONIMO-825) schemaLocation attribute values in deployment plans contain problematic schema\ prefix.
schemaLocation attribute values in deployment plans contain problematic schema\ prefix. - Key: GERONIMO-825 URL: http://issues.apache.org/jira/browse/GERONIMO-825 Project: Geronimo Type: Bug Versions: 1.0-M4 Reporter: Sachin Patel Priority: Minor From IRC conversation... [16:33] sppatel: I'm looking at the deployment plan schemas, and noticed something odd. Could someone explain why the path /schema is being included in some the schemaLocations in several of the xsd files where other schemas are being imported. This looks like an error to me. For example geronimo-web.xsd imports xs:import namespace=http://geronimo.apache.org/xml/ns/security; schemaLocation=schema/geronimo-security.xsd/ whereas geronimo-application.xsd references the same schema but its schemaLocation=geronimo-security.xsd Why is the schema/ prefix being included? [16:45] djencks: sppatel: I think one of those is an error, but I'm not sure which [16:46] djencks: it's using an entity resolver in the xmlbeans2 maven plugin that looks in the classpath jars for the xsd file [16:46] sppatel: djencks: I'm attempting to generate EMF models for the deployment plans, and was forced to remove the prefix /schema in all scheamaLocations for it to correctly resolve [16:46] djencks: what is emf? [16:46] djencks: don't think is is electromotive force :-) [16:47] sppatel: Eclipse Modeling Framework:) [16:47] sppatel: I'm working on providing deployment plan editors for the Geronimo Server Adapter [16:47] djencks: cool [16:47] djencks: where are you getting the schemas from? [16:48] sppatel: from the schema folder in a install image [16:48] sppatel: since their bundled all togather, the schema/ prefx doesn't make sense [16:48] djencks: can you read them out of a classpath using a classloader? [16:49] djencks: not critical, just asking [16:49] sppatel: not sure how to do that [16:49] djencks: it would be a useful capability I think for the EMF [16:50] djencks: well, there are at least 2 solutions I can think of: [16:50] djencks: 1. figure out a way so xmlbeans doesn't need the prefix... this may be actually more in line with what xmlbeans wants to do anyway [16:51] djencks: 2. modify the copies of the schemas to remove the /schema prefix [16:51] djencks: can you file a JIRA issue? [16:51] sppatel: sure, np. 2 is fine with me for now... just wanted to bring it up [16:52] *** sbailliez has joined #geronimo. [16:52] djencks: Is this blocking your progress? Can you remove the prefix by hand until we figure out what to do? I would prefer (1) if it works [16:53] sppatel: no its not blocking, i'm changing the refs by hand. yeah 1 would be ideal, especially if the scheams are going to be changing in the future [16:54] djencks: well, we are hoping that we will have stabilized them by 1.0 to a n, n-2 support model :-) -- 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] Resolved: (GERONIMO-145) [PATCH] White box tests for o.a.g.kernel.log package
[ http://issues.apache.org/jira/browse/GERONIMO-145?page=all ] Dain Sundstrom resolved GERONIMO-145: - Fix Version: 1.0-M5 Resolution: Fixed Applied The CachingLog4jTest and Log4jLog no longer seem relevant, but the rest of the tests were committed. Adding modules/system/src/test/org/apache/geronimo/system/logging Adding modules/system/src/test/org/apache/geronimo/system/logging/log4j Adding modules/system/src/test/org/apache/geronimo/system/logging/log4j/AbstractLog4jLogTest.java Adding modules/system/src/test/org/apache/geronimo/system/logging/log4j/Foo.java Adding modules/system/src/test/org/apache/geronimo/system/logging/log4j/MockLogger.java Adding modules/system/src/test/org/apache/geronimo/system/logging/log4j/XLevelTest.java Transmitting file data Committed revision 225645. [PATCH] White box tests for o.a.g.kernel.log package Key: GERONIMO-145 URL: http://issues.apache.org/jira/browse/GERONIMO-145 Project: Geronimo Type: Improvement Components: kernel Reporter: Ed Letifov Assignee: Dain Sundstrom Priority: Trivial Fix For: 1.0-M5 Attachments: patch.jar Had these around for quite a while. Thought it is worth to submit them. The CachingLog4jLogTest runs for at least 3 minutes due to the cache latency, but since it is runned only when needed I guess it should be fine. -- 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] Created: (GERONIMO-826) Added support to configure min and max threads to the Jetty Container
Added support to configure min and max threads to the Jetty Container - Key: GERONIMO-826 URL: http://issues.apache.org/jira/browse/GERONIMO-826 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Attachments: jetty.diff The Jetty WebContainer cannot be configured for min and max threads. Added attributes to the JettyConnector to set min / max threads as well as query threads and idle threads. -- 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-826) Added support to configure min and max threads to the Jetty Container
[ http://issues.apache.org/jira/browse/GERONIMO-826?page=all ] Matt Hogstrom updated GERONIMO-826: --- Attachment: jetty.diff Added support to configure min and max threads to the Jetty Container - Key: GERONIMO-826 URL: http://issues.apache.org/jira/browse/GERONIMO-826 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Attachments: jetty.diff The Jetty WebContainer cannot be configured for min and max threads. Added attributes to the JettyConnector to set min / max threads as well as query threads and idle threads. -- 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-826) Added support to configure min and max threads to the Jetty Container
[ http://issues.apache.org/jira/browse/GERONIMO-826?page=all ] Jeremy Boynes reassigned GERONIMO-826: -- Assign To: Jeremy Boynes Added support to configure min and max threads to the Jetty Container - Key: GERONIMO-826 URL: http://issues.apache.org/jira/browse/GERONIMO-826 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Jeremy Boynes Attachments: jetty.diff The Jetty WebContainer cannot be configured for min and max threads. Added attributes to the JettyConnector to set min / max threads as well as query threads and idle threads. -- 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] Reopened: (GERONIMO-824) MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
[ http://issues.apache.org/jira/browse/GERONIMO-824?page=all ]
David Jencks reopened GERONIMO-824:
---
Needs to go into M4 as well.
MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
Key: GERONIMO-824
URL: http://issues.apache.org/jira/browse/GERONIMO-824
Project: Geronimo
Type: Bug
Components: OpenEJB
Versions: 1.0-M3
Reporter: Matt Hogstrom
Assignee: David Jencks
Fix For: 1.0-M5
org.openejb.deployment.MdbBuilder.java assigns null to the ListenerType if
the type cannot be determined. This causes runtime errors that are
manifested in the MdbContainerBuilder as Null Pointer Exceptions.
This fix assigns a type of javax.jms.MessageListener to the interface type as
a default.
Index: MdbBuilder.java
===
RCS file:
/home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java,v
retrieving revision 1.21
diff -r1.21 MdbBuilder.java
173c173,179
builder.setEndpointInterfaceName(OpenEJBModuleBuilder.getJ2eeStringValue(messageDrivenBean.getMessagingType()));
---
String messageInterfaceType = null;
if (messageDrivenBean.isSetMessagingType()) {
messageInterfaceType =
messageDrivenBean.getMessagingType().getStringValue().trim();
} else {
messageInterfaceType = javax.jms.MessageListener;
}
builder.setEndpointInterfaceName(messageInterfaceType);
--
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-826) Added support to configure min and max threads to the Jetty Container
[ http://issues.apache.org/jira/browse/GERONIMO-826?page=all ] Matt Hogstrom updated GERONIMO-826: --- Attachment: jetty.diff prior diff did not include Jetty-Builder changes. This is the complete diff Added support to configure min and max threads to the Jetty Container - Key: GERONIMO-826 URL: http://issues.apache.org/jira/browse/GERONIMO-826 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Jeremy Boynes Attachments: jetty.diff, jetty.diff The Jetty WebContainer cannot be configured for min and max threads. Added attributes to the JettyConnector to set min / max threads as well as query threads and idle threads. -- 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-824) MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
[ http://issues.apache.org/jira/browse/GERONIMO-824?page=all ]
David Jencks closed GERONIMO-824:
-
Fix Version: 1.0-M4
Resolution: Fixed
m4 fix:
Checking in
modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java;
new revision: 1.20.4.2; previous revision: 1.20.4.1
MdbBuilder sets the Listener Type incorrectly causing NPEs at initialization
Key: GERONIMO-824
URL: http://issues.apache.org/jira/browse/GERONIMO-824
Project: Geronimo
Type: Bug
Components: OpenEJB
Versions: 1.0-M3
Reporter: Matt Hogstrom
Assignee: David Jencks
Fix For: 1.0-M5, 1.0-M4
org.openejb.deployment.MdbBuilder.java assigns null to the ListenerType if
the type cannot be determined. This causes runtime errors that are
manifested in the MdbContainerBuilder as Null Pointer Exceptions.
This fix assigns a type of javax.jms.MessageListener to the interface type as
a default.
Index: MdbBuilder.java
===
RCS file:
/home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/MdbBuilder.java,v
retrieving revision 1.21
diff -r1.21 MdbBuilder.java
173c173,179
builder.setEndpointInterfaceName(OpenEJBModuleBuilder.getJ2eeStringValue(messageDrivenBean.getMessagingType()));
---
String messageInterfaceType = null;
if (messageDrivenBean.isSetMessagingType()) {
messageInterfaceType =
messageDrivenBean.getMessagingType().getStringValue().trim();
} else {
messageInterfaceType = javax.jms.MessageListener;
}
builder.setEndpointInterfaceName(messageInterfaceType);
--
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
Jetty Max Threads Patch
Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnector.java I've verified that the underlying product supports all the methods in there (I put the URLs in the JavaDoc). There's also a SecureConnector.java interface in the same dir for the SSL connector. Thanks, Aaron
[jira] Resolved: (GERONIMO-796) Web Server Manager portlet returns error in view mode.
[ http://issues.apache.org/jira/browse/GERONIMO-796?page=all ] Aaron Mulder resolved GERONIMO-796: --- Fix Version: 1.0-M5 Resolution: Fixed Assign To: Aaron Mulder Web Server Manager portlet returns error in view mode. Key: GERONIMO-796 URL: http://issues.apache.org/jira/browse/GERONIMO-796 Project: Geronimo Type: Bug Components: management Versions: 1.0-M5 Environment: windows xp Reporter: Joe Bohn Assignee: Aaron Mulder Fix For: 1.0-M5 The Web Server page includes a Web Server Manager portlet that is intended to return server statistics. This portlet appears to be broken as the view only displays Error occurred in portlet! Here the the exception from the geronimo.log 09:19:13,683 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.webmanager.WebManagerPortlet.doView(WebManagerPortlet.java:111) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145) 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:140) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:272) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:161) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70) at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168) at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:832) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:823) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:473) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:272) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:161) at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:106) at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:291) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at
Please revert 219816 assembly/maven.xml change
Please revert the change to modules/assembly/maven.xml in HEAD from revision 219816. I don't know if there's a polite way to present this, but I am -1 on this change as it results in the openejb schemas not being present in the output schema/ directory. The change was made by djencks with the comment dependency cleanup. I don't want to just do it and start a back and forth war without making sure you don't have some overriding concern. http://svn.apache.org/viewcvs.cgi?rev=219816view=rev Thanks, Aaron
Re: Jetty Max Threads Patch
I was going to do that tonight or tomorrow and give Tomcat the same lovin. Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 8:44 PM Subject: Jetty Max Threads Patch Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec tor.java I've verified that the underlying product supports all the methods in there (I put the URLs in the JavaDoc). There's also a SecureConnector.java interface in the same dir for the SSL connector. Thanks, Aaron
Re: Jetty Max Threads Patch
Tomcat will be a little more complicated because we have to break everything out of the initProps, and create a subclass for the SSL connector GBean, but it does support all the stuff we need, so it's mostly a matter of re-arranging. Thanks, Aaron On Wed, 27 Jul 2005, Matt Hogstrom wrote: I was going to do that tonight or tomorrow and give Tomcat the same lovin. Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 8:44 PM Subject: Jetty Max Threads Patch Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec tor.java I've verified that the underlying product supports all the methods in there (I put the URLs in the JavaDoc). There's also a SecureConnector.java interface in the same dir for the SSL connector. Thanks, Aaron
Re: Please revert 219816 assembly/maven.xml change
I certainly have no problem with getting all the schemas into the output schema directory. I don't remember too clearly but I think I commented that out because it was causing an error. All the schemas should be present in the builder jar files now, so I will look for a more uniform way of extracting all of them. It may be tomorrow before I can look at this, I hope that is not a problem. thanks david jencks On Jul 27, 2005, at 6:04 PM, Aaron Mulder wrote: Please revert the change to modules/assembly/maven.xml in HEAD from revision 219816. I don't know if there's a polite way to present this, but I am -1 on this change as it results in the openejb schemas not being present in the output schema/ directory. The change was made by djencks with the comment dependency cleanup. I don't want to just do it and start a back and forth war without making sure you don't have some overriding concern. http://svn.apache.org/viewcvs.cgi?rev=219816view=rev Thanks, Aaron
Re: Please revert 219816 assembly/maven.xml change
The only case I'm aware of where it caused an error was if you didn't do an uberbuild (because at the time the latest published OpenEJB JARs didn't have the schemas included). Anyway, it's not urgent, but I don't want to forget either. Our schema directory tends to steadily depopulate itself over time. :) Thanks, Aaron On Wed, 27 Jul 2005, David Jencks wrote: I certainly have no problem with getting all the schemas into the output schema directory. I don't remember too clearly but I think I commented that out because it was causing an error. All the schemas should be present in the builder jar files now, so I will look for a more uniform way of extracting all of them. It may be tomorrow before I can look at this, I hope that is not a problem. thanks david jencks On Jul 27, 2005, at 6:04 PM, Aaron Mulder wrote: Please revert the change to modules/assembly/maven.xml in HEAD from revision 219816. I don't know if there's a polite way to present this, but I am -1 on this change as it results in the openejb schemas not being present in the output schema/ directory. The change was made by djencks with the comment dependency cleanup. I don't want to just do it and start a back and forth war without making sure you don't have some overriding concern. http://svn.apache.org/viewcvs.cgi?rev=219816view=rev Thanks, Aaron
EJB Relationship Mapping Names
What's the purpose of the ejb-relation-name and ejb-relationship-role-name elements at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ ejb-relationship-role-name It seems that we ignore those, and don't validate them against each other even if they're present in both ejb-jar.xml and openejb-jar.xml (they're optional in both files). I guess it could be used for documentation, but then I'd prefer to make it a description element instead of something that looks like it ought to be present. Thanks, Aaron
Re: EJB Relationship Mapping Names
Hi, They are indeed not used except for documentation purposes. I am not sure that we should rename them documentation as this will not mirror the standard DD. Thanks, Gianny On 28/07/2005 12:43 PM, Aaron Mulder wrote: What's the purpose of the ejb-relation-name and ejb-relationship-role-name elements at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ ejb-relationship-role-name It seems that we ignore those, and don't validate them against each other even if they're present in both ejb-jar.xml and openejb-jar.xml (they're optional in both files). I guess it could be used for documentation, but then I'd prefer to make it a description element instead of something that looks like it ought to be present. Thanks, Aaron
Re: EJB Relationship Mapping Names
Aaron Mulder wrote: What's the purpose of the ejb-relation-name and ejb-relationship-role-name elements at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ ejb-relationship-role-name It seems that we ignore those, and don't validate them against each other even if they're present in both ejb-jar.xml and openejb-jar.xml (they're optional in both files). I guess it could be used for documentation, but then I'd prefer to make it a description element instead of something that looks like it ought to be present. I believe there are certain scenarios where multiple relationships can exist between a pair of entities and there is no other way to tell them apart. -- Jeremy
Re: EJB Relationship Mapping Names
On 28/07/2005 1:01 PM, Aaron Mulder wrote: On Wed, 27 Jul 2005, Jeremy Boynes wrote: I believe there are certain scenarios where multiple relationships can exist between a pair of entities and there is no other way to tell them apart. Well if this was true, then our code is broken, because it ignores those fields. But in truth, I believe that the cmr-field is unique -- it wouldn't ever make sense to have the same cmr-field listed in more than one relationship, right? We currently require that at least one of the ejb-relationship-roles in the ejb-relation includes a cmr-field, which I think is also OK as how could you have relationship if neither side had a CMR field? This was exactly my reasoning when this was implemented. At least one role defines a CMR field and based on this later and the role source we can infer the other one. BTW, this is why we need the foreign-key-column-on-source optional element... Thanks, Gianny Aaron
Re: EJB Relationship Mapping Names
I don't like including fields for documentation purposes that have a name that doesn't make it clear that they're only for documentation. As Jeremy just demonstrated, it's easy to convince yourself that those fields should be used in some cases (and I was moderately convinced of that myself earlier this evening). But in fact, they're totally unnecessary, and if you set them to contradict the same fields in ejb-jar.xml for the same relation (or relationship role) then there's no ill effect whatsoever. If we were going to try to match the ejb-jar.xml schema, then we should validate that values are the same across the ejb-jar block and openejb-jar block (assuming they're both present). But really, what's the benefit of not just including a description element instead? That way someone can put in matches relation 'foo' in ejb-jar.xml or they can put some other meaningful description or leave it out entirely, and it's obvious that it's not an important field as far as the server is concerned. Thanks, Aaron On Thu, 28 Jul 2005, Gianny Damour wrote: Hi, They are indeed not used except for documentation purposes. I am not sure that we should rename them documentation as this will not mirror the standard DD. Thanks, Gianny On 28/07/2005 12:43 PM, Aaron Mulder wrote: What's the purpose of the ejb-relation-name and ejb-relationship-role-name elements at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ ejb-relationship-role-name It seems that we ignore those, and don't validate them against each other even if they're present in both ejb-jar.xml and openejb-jar.xml (they're optional in both files). I guess it could be used for documentation, but then I'd prefer to make it a description element instead of something that looks like it ought to be present. Thanks, Aaron
Re: Jetty Max Threads Patch
Aaron Mulder wrote: Tomcat will be a little more complicated because we have to break everything out of the initProps, and create a subclass for the SSL connector GBean, but it does support all the stuff we need, so it's mostly a matter of re-arranging. For subclassing to make an SSL Gbean, I am against this...this nails up a particular connector GBean, where what I have allows the connector to be used for just that...a connector...any protocol, etc, makes no difference here. The Connector architecture I have implemented allows for a direct pass through to Tomcat's Connector object, and thus makes it as flexible as possible. If this is something you want to occur, then I would appreciate that this is opened up for discussion before anyone goes subclassing the ConnectorGBean. Thanks, Aaron On Wed, 27 Jul 2005, Matt Hogstrom wrote: I was going to do that tonight or tomorrow and give Tomcat the same lovin. Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 8:44 PM Subject: Jetty Max Threads Patch Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec tor.java I've verified that the underlying product supports all the methods in there (I put the URLs in the JavaDoc). There's also a SecureConnector.java interface in the same dir for the SSL connector. Thanks, Aaron
Re: Jetty Max Threads Patch
On Wed, 27 Jul 2005, Jeff Genender wrote: For subclassing to make an SSL Gbean, I am against this...this nails up a particular connector GBean, where what I have allows the connector to be used for just that...a connector...any protocol, etc, makes no difference here. The Connector architecture I have implemented allows for a direct pass through to Tomcat's Connector object, and thus makes it as flexible as possible. Here's the problem: if ConnectorGBean offers SSL settings, you're offered the opportunity to provide/configure a bunch of stuff that is totally irrelevant to a non-SSL connector (you know, user views an HTTP connector, it asks them for a keystore -- what's up with that?). I don't believe we should offer configuration and management setting that don't apply. So, I'd prefer to do this: ConnectorGBean - all connector code - non-SSL config options SSLConnectorGBean extends ConnectorGBean - no additional connector code (config/mgmt only) - always sets secure=true - includes SSL config options (inherits non-SSL config options) - ultimately can refer to an external keystore GBean That wat if you go to manage a HTTP connector, it has only settings pertinent to an HTTP connector, and if you go to manage an HTTPS connector is has all the settings pertinent to an HTTPS connector. Again, I'm not at all suggesting that we split up the code that deals with the underlying Tomcat objects. If this is something you want to occur, then I would appreciate that this is opened up for discussion before anyone goes subclassing the ConnectorGBean. Sorry -- I thought I wrote to the list about this aready, but it was stuck in my postponed messages. Here was my original thought on the topic. Aaron --- So as part of this management API, I'd like to move a bunch of properties out of the initParams and into separate properties for the Tomcat connectors. Then those properties can be reflected in the management interface. One issue is that all connectors seem to support the same settings -- in particular, the SSL settings, which I guess are just ignored unless the secure flag is set. But it doesn't make sense to me to offer SSL management properties for HTTP connectors. That being the case, I'd like to break out an SSLConnectorGBean from the ConnectorGBean. The SSL version would just extend the basic one, add more manageable properties, and default the secure flag to true. For now, you could still configure a SSL connector using the standard ConectorGBean just to frustrate me, but eventually I'd like to move all the connector properties into GBean properties and remove the initParams all together. On Wed, 27 Jul 2005, Matt Hogstrom wrote: I was going to do that tonight or tomorrow and give Tomcat the same lovin. Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 8:44 PM Subject: Jetty Max Threads Patch Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec tor.java I've verified that the underlying product supports all the methods in there (I put the URLs in the JavaDoc). There's also a SecureConnector.java interface in the same dir for the SSL connector. Thanks, Aaron
[jira] Resolved: (GERONIMO-760) Move tmporb SNAPSHOT dependency to a dated version in M4 Geronimo OpenEJB branches
[ http://issues.apache.org/jira/browse/GERONIMO-760?page=all ] Dain Sundstrom resolved GERONIMO-760: - Resolution: Fixed Changed tmporb to 1.0-DEAD Move tmporb SNAPSHOT dependency to a dated version in M4 Geronimo OpenEJB branches Key: GERONIMO-760 URL: http://issues.apache.org/jira/browse/GERONIMO-760 Project: Geronimo Type: Task Components: dependencies Versions: 1.0-M4 Reporter: John Sisson Assignee: Dain Sundstrom Fix For: 1.0-M4 Since tmporb isn't going to be removed from the M4 branch (it has been fixed in HEAD ready for the M5 release) the SNAPSHOT jar needs to be changed to a dated/versioned JAR. Dain are you able to do this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jetty Max Threads Patch
Aaron Mulder wrote: On Wed, 27 Jul 2005, Jeff Genender wrote: For subclassing to make an SSL Gbean, I am against this...this nails up a particular connector GBean, where what I have allows the connector to be used for just that...a connector...any protocol, etc, makes no difference here. The Connector architecture I have implemented allows for a direct pass through to Tomcat's Connector object, and thus makes it as flexible as possible. Here's the problem: if ConnectorGBean offers SSL settings, you're offered the opportunity to provide/configure a bunch of stuff that is totally irrelevant to a non-SSL connector (you know, user views an HTTP connector, it asks them for a keystore -- what's up with that?). I don't believe we should offer configuration and management setting that don't apply. So, I'd prefer to do this: ConnectorGBean - all connector code - non-SSL config options SSLConnectorGBean extends ConnectorGBean - no additional connector code (config/mgmt only) - always sets secure=true - includes SSL config options (inherits non-SSL config options) - ultimately can refer to an external keystore GBean What about AJP? I guess its fine to subclass as long as the ConnectorGBean is available, so other types of connectors could be created. That wat if you go to manage a HTTP connector, it has only settings pertinent to an HTTP connector, and if you go to manage an HTTPS connector is has all the settings pertinent to an HTTPS connector. Again, I'm not at all suggesting that we split up the code that deals with the underlying Tomcat objects. Good...this was really my main concern. If this is something you want to occur, then I would appreciate that this is opened up for discussion before anyone goes subclassing the ConnectorGBean. Sorry -- I thought I wrote to the list about this aready, but it was stuck in my postponed messages. Here was my original thought on the topic. Now things make sense ;-) But I am addressing one area ... comments inline below. Aaron --- So as part of this management API, I'd like to move a bunch of properties out of the initParams and into separate properties for the Tomcat connectors. Then those properties can be reflected in the management interface. One issue is that all connectors seem to support the same settings -- in particular, the SSL settings, which I guess are just ignored unless the secure flag is set. But it doesn't make sense to me to offer SSL management properties for HTTP connectors. That being the case, I'd like to break out an SSLConnectorGBean from the ConnectorGBean. The SSL version would just extend the basic one, add more manageable properties, and default the secure flag to true. For now, you could still configure a SSL connector using the standard ConectorGBean just to frustrate me, but eventually I'd like to move all the connector properties into GBean properties and remove the initParams all together. That will be a problem in the future. The whole idea about the initParams is it allows you to plug in other beans and the GBean will dynamically set the properties through introspection without having to write a GBean that nails up an attribute to a class property. I think its ok to do this with SSL, etc, but an accross the board cut of the initparams would force us to write a new GBean if I have a new connector object (or new Valve or Realm or Host). I originally was doing a one for one Gbean attribute to class parameter when I started Tomcat. But this became unfeasible when I noticed the whole Tomcat architecture revolved around pluggable components that introspect the component properties. No one single Valve or Realm fit ... they seemed to have different properties based upon the class used. Introspection was the cure. Now we can use any kind of connector/Valve/Realm/Host/Engine by declaring the class name and setting initParams...Gbean will introspect...and it works. What I would suggest perhaps is to look at this from a bigger picture and review the way Gbeans work with attributes, and would there be a way to allow for dynamic parameters w/o the need to explicitly code the attributes. Some form of introspection would be ideal (as I am currently using in the Tomcat Gbeans). This way we can make pluggable pojo classes that allow for dynamically configurable properties. Perhaps the Spring kernel will allow this? Jeff On Wed, 27 Jul 2005, Matt Hogstrom wrote: I was going to do that tonight or tomorrow and give Tomcat the same lovin. Matt - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: dev@geronimo.apache.org Sent: Wednesday, July 27, 2005 8:44 PM Subject: Jetty Max Threads Patch Matt, If you're up to it, can you submit an additional patch for the Jetty connectors to fully implement
[jira] Assigned: (GERONIMO-518) Deploying Struts app fails on Logging ClassCastException
[ http://issues.apache.org/jira/browse/GERONIMO-518?page=all ] Dain Sundstrom reassigned GERONIMO-518: --- Assign To: Aaron Mulder (was: Dain Sundstrom) Which app causes this? Deploying Struts app fails on Logging ClassCastException Key: GERONIMO-518 URL: http://issues.apache.org/jira/browse/GERONIMO-518 Project: Geronimo Type: Bug Components: web, core Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Critical Fix For: 1.0-M5 Deploying a web app based on Struts results in the ClassCastException in commons logging displayed below. The web app includes a version of commons-logging in its WEB-INF/lib. The same web app can be successfully deployed in Tomcat 5.0.25 with no problems. Exception in thread Thread-4 java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:199) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:240) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:447) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:298) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:512) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:244) ... Caused by: org.apache.commons.logging.LogConfigurationException: java.lang.ClassCastException: org.apache.geronimo.kernel.log.GeronimoLogFactory at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609) at java.security.AccessController.doPrivileged(Native Method) at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561) at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:298) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395) at org.apache.struts.action.ActionServlet.clinit(ActionServlet.java:375) ... 67 more Caused by: java.lang.ClassCastException: org.apache.geronimo.kernel.log.GeronimoLogFactory at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:571) ... 72 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-797) proxies in collection references aren't registered with ProxyManager
[ http://issues.apache.org/jira/browse/GERONIMO-797?page=all ]
Dain Sundstrom resolved GERONIMO-797:
-
Fix Version: (was: 1.1)
Resolution: Fixed
Proxies are registered in the BasicProxyManager:188
public synchronized Object createProxy(ObjectName target) {
assert target != null: target is null;
Callback callback = getMethodInterceptor(proxyType, kernel, target);
// @todo trap CodeGenerationException indicating missing no-arg ctr
enhancer.setCallbacks(new Callback[]{callback});
Object proxy = enhancer.create();
interceptors.put(proxy, callback); === registered here
return proxy;
}
proxies in collection references aren't registered with ProxyManager
Key: GERONIMO-797
URL: http://issues.apache.org/jira/browse/GERONIMO-797
Project: Geronimo
Type: Bug
Versions: 1.0-M5
Reporter: David Jencks
Assignee: Dain Sundstrom
Apparently proxies for collection valued references aren't registered with
the proxy manager. I haven't verified this in detail but I couldn't get the
ObjectName back out of the proxies in a collection when I tried in
JettyModuleBuilder for GERONIMO-790.
--
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-677) Repeated login (after session invalidation) with different credentials results in incorrect role set.
[ http://issues.apache.org/jira/browse/GERONIMO-677?page=all ] Kevan Miller updated GERONIMO-677: -- Attachment: my-changes.patch Repeated login (after session invalidation) with different credentials results in incorrect role set. - Key: GERONIMO-677 URL: http://issues.apache.org/jira/browse/GERONIMO-677 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4 Reporter: Ivan Dubrov Assignee: David Jencks Priority: Critical Fix For: 1.0-M5 Attachments: db_create.sql, geronimo-application.xml, my-changes.patch, test.zip Consider we have two users, user with role user and manager with role manager and two secured areas /user/* and /manager/*, so only user's can access pages with URL /user/* and only manager's can access pages with URL /manager/*. If we log in as user, we can access only /user/* pages, 403 Forbidden if we try to access /manager/* pages. It is OK. Now, if we clean the session (request.getSession().invalidate()), we will be logged out, so we cannot access nor /user/*, nor /manager/* pages - server redirects to the login page. It is OK. But if we login second time, as a manager, we can access both page sets - /user/* and /manager/*! It means that authenticated user owns both roles user and manager, but this is impossible combination! -- 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-677) Repeated login (after session invalidation) with different credentials results in incorrect role set.
[
http://issues.apache.org/jira/browse/GERONIMO-677?page=comments#action_12317015
]
Kevan Miller commented on GERONIMO-677:
---
The problem lies in org.apache.geronimo.security.realm.providers.SQLLoginModule
(that's why David wasn't able to reproduce using Properties File-based login.
SQLLoginModule.login() adds GroupPrincipals to a groups HashSet. The
GroupPrincipals from groups are then retrieved from the HashSet during
commit() processing and added to the Subject. The problem is that groups is
never reset between logins. So, any new login will get all preceding
GroupPrincipals for this LoginModule instance... 8-{
In Ivan's example, user logs in and the user principal is added to groups.
This user principal is added to the Subject during commit() processing. When
manager logs in, the manager principal is added to groups. When commit() is
called both the user and manager principals are added to the Subject...
The following changes to SQLLoginModule would seem to address the problem:
Index: src/java/org/apache/geronimo/security/realm/providers/SQLLoginModule.java
===
--- src/java/org/apache/geronimo/security/realm/providers/SQLLoginModule.java
(revision 225640)
+++ src/java/org/apache/geronimo/security/realm/providers/SQLLoginModule.java
(working copy)
@@ -170,12 +170,15 @@
principals.add(iter.next());
}
+groups.clear();
+
return true;
}
public boolean abort() throws LoginException {
cbUsername = null;
cbPassword = null;
+groups.clear();
return true;
}
Note that this is simply addressing the problem at hand. I'm not familiar with
JAAS. So, it's possible that I don't fully grok (e.g. perhaps the same
LoginModule shouldn't be invoked for these separate logins, or groups should be
cleared at some other time, etc.). Also, I'm not at all convinced that
SQLLoginModule is behaving properly wrt logout(). I'm certain that it's not
very efficient (e.g. iterating over all users during login()). Ah, I see this
inefficiency is listed as a Future Change in the Security section of the Wiki
(http://wiki.apache.org/geronimo/Security)
Repeated login (after session invalidation) with different credentials
results in incorrect role set.
-
Key: GERONIMO-677
URL: http://issues.apache.org/jira/browse/GERONIMO-677
Project: Geronimo
Type: Bug
Components: security
Versions: 1.0-M4
Reporter: Ivan Dubrov
Assignee: David Jencks
Priority: Critical
Fix For: 1.0-M5
Attachments: db_create.sql, geronimo-application.xml, my-changes.patch,
test.zip
Consider we have two users, user with role user and manager with role
manager and two secured areas /user/* and /manager/*, so only user's can
access pages with URL /user/* and only manager's can access pages with URL
/manager/*.
If we log in as user, we can access only /user/* pages, 403 Forbidden if
we try to access /manager/* pages. It is OK.
Now, if we clean the session (request.getSession().invalidate()), we will be
logged out, so we cannot access nor /user/*, nor /manager/* pages - server
redirects to the login page. It is OK.
But if we login second time, as a manager, we can access both page sets -
/user/* and /manager/*! It means that authenticated user owns both roles
user and manager, but this is impossible combination!
--
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: EJB Relationship Mapping Names
You convinced me. Let's rename these elements description. Thanks, Gianny On 28/07/2005 1:07 PM, Aaron Mulder wrote: I don't like including fields for documentation purposes that have a name that doesn't make it clear that they're only for documentation. As Jeremy just demonstrated, it's easy to convince yourself that those fields should be used in some cases (and I was moderately convinced of that myself earlier this evening). But in fact, they're totally unnecessary, and if you set them to contradict the same fields in ejb-jar.xml for the same relation (or relationship role) then there's no ill effect whatsoever. If we were going to try to match the ejb-jar.xml schema, then we should validate that values are the same across the ejb-jar block and openejb-jar block (assuming they're both present). But really, what's the benefit of not just including a description element instead? That way someone can put in matches relation 'foo' in ejb-jar.xml or they can put some other meaningful description or leave it out entirely, and it's obvious that it's not an important field as far as the server is concerned. Thanks, Aaron On Thu, 28 Jul 2005, Gianny Damour wrote: Hi, They are indeed not used except for documentation purposes. I am not sure that we should rename them documentation as this will not mirror the standard DD. Thanks, Gianny On 28/07/2005 12:43 PM, Aaron Mulder wrote: What's the purpose of the ejb-relation-name and ejb-relationship-role-name elements at: openejb-jar/relationships/ejb-relation/ejb-relation-name openejb-jar/relationships/ejb-relation/ejb-relationship-role/ ejb-relationship-role-name It seems that we ignore those, and don't validate them against each other even if they're present in both ejb-jar.xml and openejb-jar.xml (they're optional in both files). I guess it could be used for documentation, but then I'd prefer to make it a description element instead of something that looks like it ought to be present. Thanks, Aaron
Re: Jetty Max Threads Patch
You might look at the dynamic attributes used in ManagedConnectionFactoryWrapper, AdminObjectWrapper, and ResourceAdapterWrapper. They require some xml up front from ra.xml to determine the exposed properties, but don't require extra code/implementation class. I am still not happy with the idea of exposing stuff purely by reflection without a definite indication of some sort that it is really intended to be exposed. david jencks On Jul 27, 2005, at 8:53 PM, Jeff Genender wrote: Aaron Mulder wrote: On Wed, 27 Jul 2005, Jeff Genender wrote: For subclassing to make an SSL Gbean, I am against this...this nails up a particular connector GBean, where what I have allows the connector to be used for just that...a connector...any protocol, etc, makes no difference here. The Connector architecture I have implemented allows for a direct pass through to Tomcat's Connector object, and thus makes it as flexible as possible. Here's the problem: if ConnectorGBean offers SSL settings, you're offered the opportunity to provide/configure a bunch of stuff that is totally irrelevant to a non-SSL connector (you know, user views an HTTP connector, it asks them for a keystore -- what's up with that?). I don't believe we should offer configuration and management setting that don't apply. So, I'd prefer to do this: ConnectorGBean - all connector code - non-SSL config options SSLConnectorGBean extends ConnectorGBean - no additional connector code (config/mgmt only) - always sets secure=true - includes SSL config options (inherits non-SSL config options) - ultimately can refer to an external keystore GBean What about AJP? I guess its fine to subclass as long as the ConnectorGBean is available, so other types of connectors could be created. That wat if you go to manage a HTTP connector, it has only settings pertinent to an HTTP connector, and if you go to manage an HTTPS connector is has all the settings pertinent to an HTTPS connector. Again, I'm not at all suggesting that we split up the code that deals with the underlying Tomcat objects. Good...this was really my main concern. If this is something you want to occur, then I would appreciate that this is opened up for discussion before anyone goes subclassing the ConnectorGBean. Sorry -- I thought I wrote to the list about this aready, but it was stuck in my postponed messages. Here was my original thought on the topic. Now things make sense ;-) But I am addressing one area ... comments inline below. Aaron --- So as part of this management API, I'd like to move a bunch of properties out of the initParams and into separate properties for the Tomcat connectors. Then those properties can be reflected in the management interface. One issue is that all connectors seem to support the same settings -- in particular, the SSL settings, which I guess are just ignored unless the secure flag is set. But it doesn't make sense to me to offer SSL management properties for HTTP connectors. That being the case, I'd like to break out an SSLConnectorGBean from the ConnectorGBean. The SSL version would just extend the basic one, add more manageable properties, and default the secure flag to true. For now, you could still configure a SSL connector using the standard ConectorGBean just to frustrate me, but eventually I'd like to move all the connector properties into GBean properties and remove the initParams all together. That will be a problem in the future. The whole idea about the initParams is it allows you to plug in other beans and the GBean will dynamically set the properties through introspection without having to write a GBean that nails up an attribute to a class property. I think its ok to do this with SSL, etc, but an accross the board cut of the initparams would force us to write a new GBean if I have a new connector object (or new Valve or Realm or Host). I originally was doing a one for one Gbean attribute to class parameter when I started Tomcat. But this became unfeasible when I noticed the whole Tomcat architecture revolved around pluggable components that introspect the component properties. No one single Valve or Realm fit ... they seemed to have different properties based upon the class used. Introspection was the cure. Now we can use any kind of connector/Valve/Realm/Host/Engine by declaring the class name and setting initParams...Gbean will introspect...and it works. What I would suggest perhaps is to look at this from a bigger picture and review the way Gbeans work with attributes, and would there be a way to allow for dynamic parameters w/o the need to explicitly code the attributes. Some form of introspection would be ideal (as I am currently using in the Tomcat Gbeans). This way we can make pluggable pojo classes that allow for dynamically configurable
[jira] Updated: (GERONIMO-677) Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED
[ http://issues.apache.org/jira/browse/GERONIMO-677?page=all ] David Jencks updated GERONIMO-677: -- Summary: Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED (was: Repeated login (after session invalidation) with different credentials results in incorrect role set.) Fix Version: 1.0-M4 Priority: Blocker (was: Critical) If Kevins analysis is correct, login modules are being reused. This is a very serious problem that must be fixed for M4. Repeated login (after session invalidation) with different credentials results in incorrect role set. LOGIN MODULES ARE BEING REUSED Key: GERONIMO-677 URL: http://issues.apache.org/jira/browse/GERONIMO-677 Project: Geronimo Type: Bug Components: security Versions: 1.0-M4 Reporter: Ivan Dubrov Assignee: David Jencks Priority: Blocker Fix For: 1.0-M4, 1.0-M5 Attachments: db_create.sql, geronimo-application.xml, my-changes.patch, test.zip Consider we have two users, user with role user and manager with role manager and two secured areas /user/* and /manager/*, so only user's can access pages with URL /user/* and only manager's can access pages with URL /manager/*. If we log in as user, we can access only /user/* pages, 403 Forbidden if we try to access /manager/* pages. It is OK. Now, if we clean the session (request.getSession().invalidate()), we will be logged out, so we cannot access nor /user/*, nor /manager/* pages - server redirects to the login page. It is OK. But if we login second time, as a manager, we can access both page sets - /user/* and /manager/*! It means that authenticated user owns both roles user and manager, but this is impossible combination! -- 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: Jetty Max Threads Patch
David Jencks wrote: You might look at the dynamic attributes used in ManagedConnectionFactoryWrapper, AdminObjectWrapper, and ResourceAdapterWrapper. They require some xml up front from ra.xml to determine the exposed properties, but don't require extra code/implementation class. I'll have a look. I am still not happy with the idea of exposing stuff purely by reflection without a definite indication of some sort that it is really intended to be exposed. In this instance it should not be an issue. I basically extended what is done already today in Tomcat. The Tomcat digester runs all of its xml parameters as found in the server.xml and context.xml through the IntrospectionUtils, and thus it operates on properties purely through reflection. I am simply doing the same with the Gbeans. The last thing I want to do is take away functionality from the Tomcat piece. We should be minimally matching this functionality. Without allowing for dynamic attributes or properties through reflection, we would be taking away functionality from Tomcat. If you can come up with a better way, I would love to hear about it...but I honestly cannot see any other alternative. Jeff david jencks On Jul 27, 2005, at 8:53 PM, Jeff Genender wrote: Aaron Mulder wrote: On Wed, 27 Jul 2005, Jeff Genender wrote: For subclassing to make an SSL Gbean, I am against this...this nails up a particular connector GBean, where what I have allows the connector to be used for just that...a connector...any protocol, etc, makes no difference here. The Connector architecture I have implemented allows for a direct pass through to Tomcat's Connector object, and thus makes it as flexible as possible. Here's the problem: if ConnectorGBean offers SSL settings, you're offered the opportunity to provide/configure a bunch of stuff that is totally irrelevant to a non-SSL connector (you know, user views an HTTP connector, it asks them for a keystore -- what's up with that?). I don't believe we should offer configuration and management setting that don't apply. So, I'd prefer to do this: ConnectorGBean - all connector code - non-SSL config options SSLConnectorGBean extends ConnectorGBean - no additional connector code (config/mgmt only) - always sets secure=true - includes SSL config options (inherits non-SSL config options) - ultimately can refer to an external keystore GBean What about AJP? I guess its fine to subclass as long as the ConnectorGBean is available, so other types of connectors could be created. That wat if you go to manage a HTTP connector, it has only settings pertinent to an HTTP connector, and if you go to manage an HTTPS connector is has all the settings pertinent to an HTTPS connector. Again, I'm not at all suggesting that we split up the code that deals with the underlying Tomcat objects. Good...this was really my main concern. If this is something you want to occur, then I would appreciate that this is opened up for discussion before anyone goes subclassing the ConnectorGBean. Sorry -- I thought I wrote to the list about this aready, but it was stuck in my postponed messages. Here was my original thought on the topic. Now things make sense ;-) But I am addressing one area ... comments inline below. Aaron --- So as part of this management API, I'd like to move a bunch of properties out of the initParams and into separate properties for the Tomcat connectors. Then those properties can be reflected in the management interface. One issue is that all connectors seem to support the same settings -- in particular, the SSL settings, which I guess are just ignored unless the secure flag is set. But it doesn't make sense to me to offer SSL management properties for HTTP connectors. That being the case, I'd like to break out an SSLConnectorGBean from the ConnectorGBean. The SSL version would just extend the basic one, add more manageable properties, and default the secure flag to true. For now, you could still configure a SSL connector using the standard ConectorGBean just to frustrate me, but eventually I'd like to move all the connector properties into GBean properties and remove the initParams all together. That will be a problem in the future. The whole idea about the initParams is it allows you to plug in other beans and the GBean will dynamically set the properties through introspection without having to write a GBean that nails up an attribute to a class property. I think its ok to do this with SSL, etc, but an accross the board cut of the initparams would force us to write a new GBean if I have a new connector object (or new Valve or Realm or Host). I originally was doing a one for one Gbean attribute to class parameter when I started Tomcat. But this became unfeasible when I noticed the whole Tomcat architecture revolved
