Re: ResourceAdapter.start() not getting called?
On 11/07/2004 5:24 AM, David Jencks wrote: Since it is unlikely that anyone will be running more than one TransactionManager/XATerminator in a geronimo server, perhaps this should be made a little clearer by specifying the WorkManager directly in the ResourceAdapter config and constructing a BootstrapContext per ResourceAdapter instance. Opinions? I agree. Perhaps that there is also something not so obvious - at least for me: a BootstrapContext must reference the same XATerminator used under the cover by the XAWork referenced by the WorkManager of this context. The current dependencies are something like that: TransactionManager XAWork WorkManager BootstrapContext; ^ | | --- So, is it possible to make it clearer by providing to the (Geronimo)WorkManager a TransactionManager(Proxy)? This latter still provides an XAWork view in order to recreate resource adpater transactions; one adds to the (Geronimo)WorkManager a getter for this XATerminator reference/attribute; and BootstrapContext only needs by now a simple reference to (Geronimo)WorkManager. This way, the dependencies could be more abvious - one more time, at least for me: TransactionManager WorkManager BootstrapContext. By the way, as I am talking about XAWork, I think that there are some concurrency issues: the begin and end methods should be synchronized otherwise, it is possible to run two Work concurrently having the same ExecutionContext. Also, perhaps we should adopt a naming convention for all these gbeans such as geronimo.server:type=BootstrapContext,name=MyBootstrapContext Is it possible to have a distinct domain for the JCA services? I mean something like: geronimo.jca:type=BootstrapContext,name=MyBootstrapContext Moreover, one could perhaps use the naming conventions proposed by JSR-77. For instance, a WorkManager could be name: geronimo.jca:type=WorkManager,BootstrapContext=MyBootstrapContext Many thanks, Gianny
Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB
On 14/07/2004 6:44 AM, [EMAIL PROTECTED] wrote: Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/browse/GERONIMO-267 Here is an overview of the issue: - Key: GERONIMO-267 Summary: NoSuchOperationError on deployment of SSB Type: Bug Status: Unassigned Priority: Major snip Assignee: Reporter: toby cabot snip Description: i'm trying to deploy and run the test ejb in ./modules/j2ee/target/test-ejb.jar. after fixing the ejb-jar.xml (see bug 266) it deploys cleanly but when I bring the server up I get a org.apache.geronimo.gbean.jmx.NoSuchOperationError: snip org.apache.geronimo.gbean.jmx.NoSuchOperationError: No implementation method: objectName=geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession, method=public abstract org.openejb.EJBContainer org.openejb.EJBContainer.getUnmanagedReference() This is my fault I have recently changed the way GBean attributes names are derived from a method name: basically, from the getUnmanagedReference method, the new implementation looks for an attribute name unmanagedReference. As the name of this attribute is actually UnmanagedReference, this exception is raised. Sorry for the inconvenience. I will notify the OpenEJB community to update their code. Gianny
Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB
On 14/07/2004 9:17 AM, Gianny Damour wrote: org.apache.geronimo.gbean.jmx.NoSuchOperationError: No implementation method: objectName=geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession, method=public abstract org.openejb.EJBContainer org.openejb.EJBContainer.getUnmanagedReference() This is my fault I have recently changed the way GBean attributes names are derived from a method name: basically, from the getUnmanagedReference method, the new implementation looks for an attribute name unmanagedReference. As the name of this attribute is actually UnmanagedReference, this exception is raised. I have just updated the way GBean attribute names are derived: When GBeans are proxied via RawGBeanInvokers, attribute names may start with an upper-case letter. For instance, if a GBean has a method getFoo, then the implementation tries to find an attribute having the name Foo. This was the behavior before my updates and I have restored it. Now, if such an attribute is not defined, then the implementation tries to find an attribute having the name foo. When GBeans are proxied via JMXGBeanInvokers, attribute names are derived based on the exact name embedded in the method name. For instance, if a GBean has a method getfoo, then the implementation tries to find an attribute having the name foo. This was the behavior before my updates and I have restored it. Gianny
Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB
On 14/07/2004 12:09 PM, Dain Sundstrom wrote: On 14/07/2004 9:17 AM, Gianny Damour wrote: I have just updated the way GBean attribute names are derived: When GBeans are proxied via RawGBeanInvokers, attribute names may start with an upper-case letter. For instance, if a GBean has a method getFoo, then the implementation tries to find an attribute having the name Foo. This was the behavior before my updates and I have restored it. Now, if such an attribute is not defined, then the implementation tries to find an attribute having the name foo. When GBeans are proxied via JMXGBeanInvokers, attribute names are derived based on the exact name embedded in the method name. For instance, if a GBean has a method getfoo, then the implementation tries to find an attribute having the name foo. This was the behavior before my updates and I have restored it. Uh, I think you lost me. I suggest we first try an exact match using JMX standard MBean rules (getFoo looks for a method Foo) and if that fails we do a case insensitive match. What ever we do, it must be consistent between the GBeanInvokers, since the programmer has not input into the invoker type the container chooses. Sorry; indeed, this is perhaps not the right approach. However, I was pretty confident that this new behavior was more correct: As far as I understand, the JMX GBeanInvokers are used only when the framework mounts a reference, which does not have an attribute named GBeanMBean.RAW_INVOKER. Most of the time, this means that the reference is an home-made MBean (an MBean, which is not a GBeanMBean). So, I thought that we could safely say that programmers have applied the JMX standards. In other words, if the attribute is named serverVersion, then the getter must be getserverVersion. Having said that, the RawGBeanInvokers are used, most of the time, when the reference is a GBeanMBean. Based on the naming conventions of the attribute names (lower-case for the first character), I saw two approaches: - renaming of the getters and setters of the various GBeans in order to be aligned with the JMX standards; or - update of the way methods and attribute names were matched. The second approach has been implemented. This means that from a method getFoo, the implementation will look for Foo. In case of failure, it will then look for foo. I am happy to make this second look-up case insensitive. Yet, I am not sure that JMX GBeanInvokers should mirror this behavior. In other words, and as far as I understand, programmers know the invoker type, which will be used by the container: - if they use a GBean, it will be the Raw type; - if they implement an MBean having an attribute GBeanMBean.RAW_INVOKER, then it will also be the Raw type; otherwise - it will be the JMX type. In this specific case, one could assume that the JMX naming conventions have been applied. There is something wrong in my reasoning; nonetheless, I do not know where. Thanks, Gianny
Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB
On 15/07/2004 3:10 AM, Dain Sundstrom wrote: On Jul 14, 2004, at 4:47 AM, Gianny Damour wrote: Sorry; indeed, this is perhaps not the right approach. However, I was pretty confident that this new behavior was more correct: As far as I understand, the JMX GBeanInvokers are used only when the framework mounts a reference, which does not have an attribute named GBeanMBean.RAW_INVOKER. Most of the time, this means that the reference is an home-made MBean (an MBean, which is not a GBeanMBean). So, I thought that we could safely say that programmers have applied the JMX standards. In other words, if the attribute is named serverVersion, then the getter must be getserverVersion. When you want to interact with a GBean over a remote MBean server (JSR 160), you will use the JMXGBeanInvokers. Also, this is an attempt to make our interactions through JMX easier. Thanks for that; it was a missing block in my reasoning. I definitely think the two should work exactly the same and the programmer should not know which one is being used (other then the JMX one is way slower). My biggest reason to have these work the same is the person using the GBeanInvoker is caller, and the caller would have to know how the target GBean was implemented in order to get the calling code correct. You are right. So, to sum it up, in a first pass one applies the JMX standards; and in case of failure, a case insensitive match of method and attribute names is performed. Thanks, Gianny
Re: build broken (assembly module)?
On 16/07/2004 7:54 AM, David Jencks wrote: Can you check that your openejb copy is up to date? I've been trying to fix these case problems in both projects while doing actual development work and I think but am not entirely sure that at least this problem is fixed. These attribute names should start with lower case as in cvs. This is weird. The http://dist.codehaus.org maven repository does not seem to be up-to-date: the itests and jca archives have been updated on 15-Jul-2004 and the last update of core was on 12-Jul-2004. In other words, assembly still fail. Thanks, Gianny
sandbox/messaging - your feedbacks are welcome
Hello, I am working on a prototype, sandbox/messaging, focused on providing the infrastructure for the implementation of clustered applications. This proto has reached a stage, which is according to me good enough for judgment. I will try to describe here the main features of this infrastructure; hence, this memo will be a little bit long. Its core ideas are: - to provide a mechanism to cluster/inter-connect N Geronimo servers. The way these servers are inter-connected should be at the same time manageable (e.g. I want this server to be connected to this one) and to some extent automatic (e.g. when a new server is detected, it should be added automatically to the cluster); and - to provide a set of base services built on top of the above infrastructure to simplify the implementation of clustered applications (e.g. creation of proxies for services running on remote Geronimo server). Let's talk in more details about the way Geronimo servers are clustered. The implementation achieve this goal by organizing servers in a known and configurable topology, e.g. star, ring, hyper-cube, where edges of the associated graphs represent connections. At the very beginning, a server and two heartbeat services, namely heartbeat sender and heartbeat monitor, are started. The heartbeat sender sends periodically an heartbeat consisting of the meta-data (IP address, port and name) of its associated server to a multicast group. The heartbeat monitor monitors these heartbeats and detects the availability or failure of servers. When a new server is available or a failure is detected, a new topology is computed and cascaded to the servers of the current topology. Let's consider the following scenario: Geronimo servers are organized in a ring topology; four servers are started and one server is killed. 1. starts the first server, namely LearderNode. As it is the first server, it is in a stand-alone mode; 2. starts the second server, namely Node1. This server is detected by LeaderNode, which triggers a reconfiguration. The topology is LeaderNode -- Node1 -- LeaderNode; 3. starts the third server, namely Node2. LeaderNode inserts Node2 between itself and Node1. The topology is LeaderNode -- Node1 -- Node2 -- LeaderNode; 4. starts a fourth server, namely Node3. Detected by LeaderNode, it inserts Node3 between itself and Node2. The topology is LeaderNode -- Node1 -- Node2 -- Node3 -- LeaderNode; and 5. stops Node2. LeaderNode drops it from the ring. The topology is LeaderNode -- Node1 -- Node3 -- LeaderNode. As the proto supports the ring topology, it is possible to trial this scenario: cd sandbox/messaging maven (ClusterHBTest may fail, so ignore the test failures if required) maven -patch cd ../.. java -jar target/bin/server.jar org/apache/geronimo/LeaderCluster java -jar target/bin/server-1101.jar org/apache/geronimo/Cluster8091 java -jar target/bin/server-1102.jar org/apache/geronimo/Cluster8092 java -jar target/bin/server-1103.jar org/apache/geronimo/Cluster8093 kill the process java -jar target/bin/server-1102.jar org/apache/geronimo/Cluster8092 As a conclusion, this prototype tries to federate Geronimo servers in specific topologies. As an aside, it is rather simple to support other kinds of topologies without significant efforts. For instance, one of the JUnit test (NodeImplTest) uses a bus topology. Based on the knowledge of the enforced topology, it should be possible to implement efficient clustered applications. For instance, the replication of Web sessions could work as follow: replicate the sessions created on this server to all of its direct neighbours (neighbours can be easily retrieved via a topology). This way the load is evenly distributed as long as sessions are evenly created in the cluster. On top of this infrastructure, the proto implements a set of basic services, which could simplify the implementation of such clustered applications. These services are: - customization of the marshalling/unmarshalling of Objects to be sent/received to/from a remote server: it is possible to replace specific objects; - InputStream can be passed between servers: by leveraging the previous feature, InputStreams are replaced by a proxy which can be used to pull the content of an InputStream hosted on a remote server. This can be useful when dumping the content of a server to another server in order to initialize its state; - primitive reference layer: Objects implementing a specific interface can be passed around even if not serializable. For instance, the current implementation can pass around a MBeanServer (this is a bad example as JSR 160 is intended for that). If you have a look to MBeanServerEndPointImpl, you will see that this is actually the ability to return by reference an object to the remote caller. As this caller can also provide parameters, which implements this specific interface, one can achieves a pass by reference for both the parameters and the
Re: sandbox/messaging - your feedbacks are welcome
On 21/07/2004 5:28 PM, [EMAIL PROTECTED] wrote: For clustering, we've been working quite heavily for some time on this abstraction... http://activecluster.codehaus.org/ (Note that ActiveCluster is not Geronimo specific and so can be used to build clusters or anything). The current implementation works on top of any JMS provider, such as ActiveMQ, which can work over UDP, multicast, TCP, SSL, g-network, JGroups, JXTA etc. As far as I know, ActiveCluster does not provide high-availability on top of any JMS server. JMS servers are not designed equally from an high-availability point-of-view. Some of them are high-available and others aren't. For instance, if the JMS server used by ActiveCluster fails, then it is the cluster as a whole which is down. If ActiveCluster yields clients of this problem by using a ConnectionFactory, which uses under the cover N ConnectionFactory to N distinct JMS servers or if it has the ability to detect the failure of a JMS server and migrates it on another node, then yes it supports high-availability. So, ActiveCluster does not turn any JMS provider into an highly-available JMS provider and if the JMS provider fails, then the cluster as a whole fails. Jules has been working hard on distributed session state and handling fail-over gracefully and cluster wide topology organisation protocols such as for arranging buddies over subnets / DR zones and the like using WADI http://wadi.codehaus.org/ which is using ActiveCluster and Jules is starting to put together various algorithms for choosing buddies, pairs, sub-nets, controllers and the like. Notice the simpler API for ActiveCluster which just reuses a few interfaces from JMS. It seems your new messaging.cluster API is pretty similar to ActiveCluster. Any ideas why you didn't just use ActiveCluster? (Especially as I mentioned it to you quite a while ago :) I know. Actually, I was so closed to reach a presentable state of g-messaging that I have done the last step: at this very moment, N servers can be started and the proto will auto-discover and syndicate them. There is not a single point of failure. Actually this is wrong as a migratable service is executed by a server and not migrated to another node upon failure. This is a standard feature that should be provided out-of-the-box: the ability to run a service only once in a cluster and migrate it on demand/failure to another node. Also, as I said to you a while ago, I don't see why the messaging package doesn't use the JMS API for things like Msg / MsgBody / MsgConsumer / MsgProducer and so forth. Not only would this mean your API would become more J2EE standard, it'd mean you could reuse heaps of open source and commercial implementations. At the very beginning, I was really seduced by this idea. On second thought, I prefer this simplified API. No cumbersome JMSException at each and every simple call on a JMS Message. One can see the various MsgX as wrappers around the JMS API. Actually, any open source or vendor provided JMS implementations could be re-used: the org.apache.geronimo.messaging.remotenode is done to hook-in others transports such as JMS. As an aside, we are talking here about only 5 classes in a code base couting the little more than 100 classes. Having said all that, I am still having a serious look to ActiveCluster. However, I do not see how its current implementation avoids a cluster wide failure in case of a JMS server failure. Cheers, Gianny
Unpacked module - RAR and WAR support
Hello, It is now possible to install unpacked RAR and WAR. I have been forced to introduce a temporary interface, namely ModuleBuilderWithUnpack, such that the build is not broken (OpenEJB impact). When OpenEJBModuleBuilder will also support unpacked EJB, this interface will need to be merged with ModuleBuilder. Cheers, Gianny
Re: Proposal for output of assembly module
On 7/08/2004 4:22 AM, David Jencks wrote:
The assembly module doesn't conform to the maven standard action of
producing an artifact, and its results are not in the module itself.
Furthermore it doesn't produce an easily installable geronimo instance.
I'd like to suggest that the assembly module should produce a zip file
of what it builds, currently into
target/geronimo-${pom.currentVersion}, and install it in the local
repo as a zip artifact.
Then we can extend the geronimo-maven plugin with a little bit of
jelly script to unpack this zip into the target of the module using
the plugin. This will make it easy to get back to pristine geronimo
installations.
I think that it would be awesome. +1.
As far as I understand, assembly is the way to build a Geronimo server
from nothing: people can only download this module and let maven pulls
the various artifacts and install a full server. Personally, I see this
module as an installation procedure via maven.
So, I do have another question: Is it possible to put the assembly
module somewhere else than nested inside modules? Perhaps that it could
be nested inside an installer project?
Thanks,
Gianny
Re: Dynamic classpaths
On 25/08/2004 2:45 AM, John Woolsey wrote: I am trying to deploy my bean and I need to add the jar to the classpath (I know rewrite my classloader) so that I can see classes and interfaces in the jar. Just wondering for a good spot to look for that. - thanx - JAW Hi John, I do not understand exactly what you are trying to achieve. Yet, if you are trying to deploy (Enterprise Java)bean, then you just have to package them as you were used to do it. Having said that, Geronimo is not yet able to handle Class-Path entries defined in Manifest files. Hence, if you are trying to deploy an (Enterprise Java)bean using this mechanism, then you may face some ClassNotFoundException. Could you please provide more details on your needs? FYI, Dain speaks of Geronimo's class-loading strategy there: http://www.theserverside.com/talks/videos/DainSundstrom/dsl/interview.html I think that you should check it out to understand what it buys you as an end-user. Thanks, Gianny
Re: help ! security realms
On 25/08/2004 2:43 AM, Prem kalyan wrote: hi all, I am going through the security part of geronimo and the corresponding deployment descriptor elements.I have few questions in this regard 1. What are all the different security realms supported in geronimo. 2. What values does the attribute 'realm-name' in tag realm takes. Hi Prem, I think that you should have a look to a previous thread named Security providers. Alan is describing how the security layer is implemented and covers more or less these questions. 3. What is the equivalent in geronimo for filerealm in weblogic. If you have a look in var/security of a Geronimo installation, you will see for instance a users.properties file. This guy is to Geronimo what fileRealm.properties is for WebLogic (OK, the WebLogic one does not store the password in clear). Cheers, Gianny
Re: NullPointerException at findToolsJarFile
On 13/09/2004 9:12 PM, Jacek Laskowski wrote: Jacek Laskowski wrote: Hi, I've decided to try to run the server with no additional arguments and here's what I got. Has anyone seen this before? It's a fresh build. /geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT $ java -jar bin/server.jar 13:03:04,160 WARN [ToolsJarHack] Could not all find java compiler: tools.jar file not found at C:\Program Files\Java\j2 re1.4.2_05\lib\tools.jar 13:03:04,180 WARN [ToolsJarHack] Could not all find java compiler: tools.jar file not found at C:\Program Files\Java\li b\tools.jar java.lang.ExceptionInInitializerError Caused by: java.lang.NullPointerException at org.apache.geronimo.system.main.ToolsJarHack.findToolsJarFile(ToolsJarHack.java:97) at org.apache.geronimo.system.main.ToolsJarHack.install(ToolsJarHack.java:59) at org.apache.geronimo.system.main.Daemon.clinit(Daemon.java:54) Exception in thread main In fact, I can't run the server at all, with or without specified configuration :( (I don't have any other way then to sort it out. This problem may happen if you try to run the server via the standalone JRE (C:\Program Files\Java\j2re1.4.2_05\bin\java.exe). You need to run it either via the JDK (say, C:\j2sdk1.4.2_05\bin\java.exe) or the JRE shipped with the JDK (say, C:\j2sdk1.4.2_05\jre\bin\java.exe) Jacek Gianny
Re: Problem building from subversion
On 18/09/2004 8:41 AM, Jacek Laskowski wrote: Kristian Köhler wrote: Hi after refreshing from scm and running rebuild i get an error (attached). Am I alone? ;-) Oops, I'm checking it out This problem is fixed. It was due to the fact that the geronimo-tomcat artifact was not copied to the geronimo repository prior to deploy TomcatGBean. BTW, I have noticed a couple of issues: * there is an indirect dependency between Catalina (the class) and the javax.management package. I have discovered this problem when mounting the geronimo-tomcat module within Eclipse. So we will need to declare a new dependency; and * to some extent we are lucky to have a build of geronimo-tomcat after assembly. Indeed, geronimo-tomcat assumes that the assembly module has been built, yet it does not declare a dependency to force a correct build order. I think that geronimo-tomcat should be installed like the other modules (e.g. geronimo-jetty). Thanks, Gianny
Re: contextPriorityClassLoader
On 7/10/2004 3:34 PM, Dain Sundstrom wrote: On Oct 6, 2004, at 5:33 PM, Dain Sundstrom wrote: BTW, I find the name contextPriorityClassLoader a bit non-intuitive, what do other app servers call this (specifically weblogic and webshpere). I'm still interested in this if anyone has the info... For WebLogic, this is prefer-web-inf-classes. Gianny -dain
Re: error
On 14/10/2004 3:20 AM, mouli wrote: [mkdir] Created dir: C:\asf\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\bin [mkdir] Created dir: C:\asf\geronimo\modules\assembly\target\geronimo-1.0-SN APSHOT\config-store [echo] Building server.jar [java] Server URI: org/apache/geronimo/System [echo] Building server configuration [java] org.apache.geronimo.deployment.DeploymentException: Unable to load pa rents [java] at org.apache.geronimo.deployment.DeploymentContext.init(Deplo ymentContext.java:114) ... When configurations, modules or plans, are successfully deployed, the deployer displays their URIs. So, for sure org/apache/geronimo/System has been installed. [java] Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: N o configuration with id: org/apache/geronimo/System [java] at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.lo ad(ConfigurationManagerImpl.java:129) [java] at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.lo adRecursive(ConfigurationManagerImpl.java:175) [java] at org.apache.geronimo.deployment.DeploymentContext.init(Deplo ymentContext.java:112) ... I am so happy! I am not the only one to have faced this problem. If you look into your modules/assembly/target/geronimo-1.0-SNAPSHOT/config-store directory you will see the standard index.properties file along with another file named indexID.tmp. This latter should have replaced index.properties, yet it seems that index.properties has not been successfully deleted. So, perhaps that LocalConfigStore should check that index.properties has been successfully deleted and that indexID.tmp has been successfully renamed. what needs to be done to fix this? On my side, I have simply rebuilt the assembly module and it was OK. I have not been able to re-create the problem. Are we the only ones to have encountered this problem? Thanks, Gianny
Re: Praise Gianny
On 15/10/2004 2:19 PM, Dain Sundstrom wrote: I'd like to take a moment to praise Gianny for all his hard work on the CMP implementation. Gianny has quietly been working hard on the CMP implementation and has just completed a major chunk of CMP 2. I haven't reviewed the entire patch yet, but it looks like we now have CMR support, CMP to SQL mapping, compound primary key support, and unknown (auto-generated) primary key support. This is an amazing amount of work, especially given the complexity of the TranQL codebase. I know that others are equally impressed with all of the work that Gianny has done, and that he has recently been given commit on OpenEJB and TranQL. So thanks, Gianny, for a job well done! Dain, many thanks for that :-). I am now a little bit embarrassed: because my patch had some bugs (will fix them in the next hours) and also because I did not take a moment to praise all of you guys, when you have no more no less put together Geronimo. Cheers, Gianny
CMP2.x - new features available - shake out phase
Hi, We have recently hooked in what we believe is sufficient enough to give a fair try to petstore1.3.1_02. The new capabilities are (Dain, thanks for having logged these issues): * GERONIMO-177 - Support for user defined primary key classes: nothing very special in here; it is now possible to specify a compound primary key, which may be mapped to multiple CMP fields. /jira/browse/GERONIMO-177 * GERONIMO-179 - Support for CMRs /jira/browse/GERONIMO-179: OTO, OTM and MTM container managed relationships are enabled. * GERONIMO-176 - CMP table mapping support /jira/browse/GERONIMO-176: it is the capability to map the CMP and CMR fields of an EntityBean to a database. There are a couple of examples for each (primary key type, relationship multiplicity) couple in here: openejb\modules\core\src\test-cmp * GERONIMO- 377 - Unknown primary key support: this is used to support the deployment of EntityBean having an unknown primary key class. By now, no test-cases have been committed. Having said that, here is an explanation of how to use it: EntityBeans having an unknown primary key class, i.e. java.lang.Object, must declare a automatic-key-generation element. This latter specifies the name of a primary key generator along with the class type returned by this same generator. A primary key generator can return either simple or compound primary keys. In the former case, a primkey-field needs to be specified along with the automatic-key-generation. In the latter case, no primkey-field must be specified. Virtual CMP fields are to be defined in order to store the auto-generated primary keys. One does via the standard cmp-field-mapping element; though, one must also declare the class type of such virtual CMP fields via the cmp-field-class element. As of this writing, two primary key generators are supported: - sequence, store procedure or more generaly any SQL statement returning a unique identifier: this is the GBean org.openejb.entity.cmp.pkgenerator.SQLPrimaryKeyGeneratorWrapper; and - sequence table, where a sequence is simulated via a table: this is the GBean org.openejb.entity.cmp.pkgenerator.SequenceTablePrimaryKeyGeneratorWrapper. Example of unknown primary key definition - to be specified in openejb-jar.xml: entity ejb-nameProfileEJB/ejb-name // ProfileEJB has an unknown primary key as per ejb-jar.xml. table-nameProfileEJBTable/table-name cmp-field-mapping cmp-field-nameid/cmp-field-name // id is not defined in ejb-jar.xml; this is a virtual CMP field. cmp-field-classjava.lang.Integer/cmp-field-class // one must specify the class type virtual CMP fields. table-columnid/table-column /cmp-field-mapping ... primkey-fieldid/primkey-field // defines the virtual CMP field storing the auto-generated identity. automatic-key-generation generator-namegeronimo.server:role=CMPPKGenerator,name=IntegerGenerator/generator-name // reference a primary key generators primary-key-classjava.lang.Integer/primary-key-class /automatic-key-generation entity // this is the declaration of the primary key generator used by ProfileEJB. gbean name=geronimo.server:role=CMPPKGenerator,name=IntegerGenerator class=org.openejb.entity.cmp.pkgenerator.SequenceTablePrimaryKeyGeneratorWrapper reference name=ManagedConnectionFactoryWrappergeronimo.server:J2EEServer=geronimo,j2eeType=JCAManagedConnectionFactory,name=MySQL/reference attribute name=tableName type=java.lang.StringSEQUENCE_TABLE/attribute attribute name=sequenceName type=java.lang.StringSEQUENCE_NAME/attribute attribute name=batchSize type=int10/attribute /gbean For sure, there are some bugs and it will take a couple of weeks to identify and fix them. So, if you want to trial these new features with your home-grown CMP2.x EntityBean and help in this shake out process, then that would be awesome. Thanks, Gianny
Re: Build Error in Assembly
Hi Mouli, A couple of tests have been added to detect File.delete or File.renameTo failures. Moreover, if File.renameTo fails, then an atttempt to create a new index file from scratch is done. Could you please update your local copy and give it another try? Thanks, Gianny On 20/10/2004 11:54 AM, mouli wrote: I still get the error == [echo] C:\asf\geronimo [echo] Preprocessing client-system-plan.xml [echo] Preprocessing default-database-plan.xml [echo] Preprocessing deployer-system-plan.xml [echo] Preprocessing j2ee-client-plan.xml [echo] Preprocessing j2ee-deployer-plan.xml [echo] Preprocessing j2ee-secure-plan.xml [echo] Preprocessing j2ee-server-plan.xml [echo] Preprocessing system-activemq-plan.xml [echo] Preprocessing system-database-plan.xml [echo] Preprocessing system-jms-plan.xml [echo] Preprocessing system-plan.xml [echo] Bootstrapping service deployer [echo] Building server.jar [java] Server URI: org/apache/geronimo/System [echo] Building server configuration [java] org.apache.geronimo.deployment.DeploymentException: Unable to load pa rents [java] at org.apache.geronimo.deployment.DeploymentContext.init(Deplo ymentContext.java:114) [java] at org.apache.geronimo.deployment.service.ServiceConfigBuilder.b uildConfiguration(ServiceConfigBuilder.java:101) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java: 174) [java] at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java: 83) [java] at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMet aDataImpl.java:213) [java] at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java :220) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke( DefaultMBeanServerInterceptor.java:815) [java] at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer. java:784) [java] at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231) [java] at org.apache.geronimo.system.main.CommandLine.init(CommandLin e.java:106) [java] at org.apache.geronimo.system.main.CommandLine.main(CommandLine. java:64) [java] Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: N o configuration with id: org/apache/geronimo/System [java] at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.lo ad(ConfigurationManagerImpl.java:129) [java] at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.lo adRecursive(ConfigurationManagerImpl.java:175) [java] at org.apache.geronimo.deployment.DeploymentContext.init(Deplo ymentContext.java:112) [java] ... 10 more BUILD FAILED File.. C:\Documents and Settings\mouli\.maven\cache\maven-multiprojec t-plugin-1.3.1\plugin.jelly Element... maven:reactor Line.. 217 Column 9 Unable to obtain goal [default] -- C:\asf\geronimo\modules\assembly\maven.xml:22 5:84: ant:java Java returned: 2 Total time: 1 minutes 45 seconds Finished at: Tue Oct 19 21:25:25 EDT 2004 = As suggested earlier I have removed indexid.tmp but it gets created when I run the build again. Any suggestions... Thanks, Mouli ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Re: [VOTE] M3 pre ApacheCon
+1 Gianny On 4/11/2004 3:48 AM, Jeremy Boynes wrote: On the belief we need to formally vote on making a release, should we produce a M3 release?
Re: Vote: Remove old deployer, rename new deployer
+1 As an aside, the new deployer can not distribute unpacked modules. Is it intentional? Thanks, Gianny On 7/11/2004 4:35 AM, Aaron Mulder wrote: I'd like to remove the current deployer.jar tool, remove the command-line processing logic from the Deployer class, rename new-deployer.jar to deployer.jar and change the bootstrapper to build the new one instead of the old one. Currently there are two so we'd have some sort of transition (fallback in case of problems), but since the build script is pretty much only using the new one now, there are some NPE's in the old one, and no one seems to have had any problems with the new one, I'd like to go ahead and eliminate the old one. Please indicate whether you agree. Thanks, Aaron
Re: [VOTE] M3 pre ApacheCon
On 8/11/2004 8:19 AM, David Jencks wrote:
I'm not exactly ready to vote -1, but I think we should resolve these
issues before M3:
1. http://issues.apache.org/jira/browse/GERONIMO-386 Make cmp work
with derby. Prove it with the itests
I had a look to this one. I have committed a partial implementation and
switched itests to Derby.
As far as I know, these CMP EJBs are not portable as they are using an
auto-generated primary key by the DB. In other words, additional vendor
specific configurations are to be provided to map them to such a table.
The identity of these EJBs have been declared as auto-generated by the
GBean AutoIncrementTablePrimaryKeyGeneratorWrapper. This latter uses
JDBC3.0 to return auto-generated table primary keys.
More accurately, it inserts a dummy record into the entity table via
INSERT INTO entity (first_name) VALUES ('MOCK') and retrieves the
auto-generated primary key. This works; yet I will revisit the
implementation to get ride of this query to be manually specified.
Thanks,
Gianny
BLOB manipulation - question
Hi, I am working on the support of Dependent Value Classes. The implementation is rather simple: if a binding is not explicitely defined for a CMP field class (see org.tranql.sql.jdbc.binding.BindingFactory) and if the class implements Serializable, then one assumes that the CMP field is a Dependent Value Class. Such CMP fields are stored into BLOB columns. The serialized object is stored into the BLOB via the PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x, int length) method. As a matter of fact, this works with Derby. Yet, it seems that this is not the correct way. More accurately, it seems that PreparedStatement.setBlob (int i, Blob x) is the correct way. Anyone knows if PreparedStatement.setBinaryStream is portable? Thanks, Gianny
Re: BLOB manipulation - question
Dain, Jeremy, thanks for your replies.
Here is a short description of what I have so far understood about LOB
manipulations:
setBinaryStream
setBinaryStream does work with Derby, MySQL and Oracle (except where the
content is bigger than 4k). The JDBC specifications 3.0 mandate that
the method setBinaryStream may also be used to store BLOB.
BLOB creation
* in the case of Oracle, the empty_blob() method is indeed to be used to
create an empty BLOB. I tried unsuccessfully other approaches
(setNull(index, Types.BLOB), setBinaryStream(index, null, 0) and INSERT
TABLE A (myBLOBColumn) VALUES ('')).
* in the case of MySQL a simple INSERT TABLE A (myBLOBColumn) VALUES
('') works.
BLOB update
BLOB updates are done either directly to the LOB itself or to a copy. It
is implementation dependent and the method
DatabaseMetaData.locatorsUpdateCopy() indicates which of this
implementation is supported by a driver.
* Oracle works directly with the LOB. This means that to update a BLOB,
one just needs to do that:
statement.executeUpdate(CREATE TABLE A (a1 VARCHAR(10), a2 BLOB));
// execute this query to create a BLOB.
preparedStatement = connection.prepareStatement(INSERT INTO A (a1, a2)
VALUES ('a1', EMPTY_BLOB()));
preparedStatement .execute();
// update it in place
preparedStatement = connection.prepareStatement(SELECT a2 FROM A WHERE
a1 = 'a1' FOR UPDATE);
resultSet = preparedStatement .executeQuery();
rs.next();
Blob blob = rs.getBlob(1);
OutputStream out = blob.setBinaryStream(1);
// update the Blob by writing new data via out.write()
// truncate Blob if required via blob.truncate(long);
connection.commit();
The above snippet works with Oracle10g JDBC driver and above. Prior to
this version, Oracle specific classes need to be used.
* MySQL works with a copy of the LOB. This means that to update a BLOB,
one needs to update it via setBlob or updateBlob. The previous snippet
becomes:
// execute this query to create a BLOB.
preparedStatement = connection.prepareStatement(INSERT INTO A (a1, a2)
VALUES ('a1', ''));
preparedStatement .execute();
// update the BLOB copy
preparedStatement = connection.prepareStatement(SELECT a2 FROM A WHERE
a1 = 'a1' FOR UPDATE);
resultSet = preparedStatement .executeQuery();
rs.next();
Blob blob = rs.getBlob(1);
OutputStream out = blob.setBinaryStream(1);
// update the Blob by writing new data via out.write()
// truncate Blob if required via blob.truncate(long);
// update the BLOB itself
preparedStatement = c.prepareStatement(UPDATE A SET a2 = ? WHERE a1 =
'a1');
preparedStatement .setBlob(1, blob);
preparedStatement .execute();
connection.commit();
Based on these findings, I have started to implement a solution which
does this:
* use setBinaryStream if specified; or
* decompose INSERT and UPDATE statements into two or three statements
depending on a locatorsUpdateCopy configuration.
Thanks,
Gianny
Re: BLOB manipulation - question
On 2/12/2004 11:52 AM, Dain Sundstrom wrote: Great news. I suggest that we declare that we only officially support the 10g driver. Maybe add a wiki page with supported drivers. Good idea. This is in progress in here: http://wiki.apache.org/geronimo/Working_20with_20Enterprise_20JavaBeans Thanks, Gianny
Re: EJB QL Support?
On 14/12/2004 6:55 AM, Aaron Mulder wrote: Is anyone working on EJB QL support? There's a guy here at work who's interested in fussing with antlr and EJB QL, but I don't want to step on anyone if it's already underway. Aaron Happy New Year All! Aaron, could you please tell me if this task is been progressed? I am back from holidays and have time to work on it. Thanks, Gianny
Re: abstract-schema-name doesn't seem to work for CMP20
You are right: abstract-schema-name does not work. By now, one need to use the ejb-name instead of the abstract-schema-name in the basic EJBQL queries, which are currently supported. I have already fixed this bug on my working copy and will commit the fix as part of upcoming EJBQL stuff. I plan to do an intermediate check in over the week-end. Thanks, Gianny On 5/01/2005 11:03 PM, Alan D. Cabrera wrote: abstract-schema-name doesn't seem to work for CMP20. I thought that this used to work. Can anyone confirm? Regards, Alan
Re: svn commit: r126427 - /geronimo/trunk/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java
Hi David,
It seems that this is related to this JIRA issue:
[ http://nagoya.apache.org/jira/browse/GERONIMO-504?page=comments#action_55900
]
that Jeremy has commented.
Thanks,
Gianny
On 26/01/2005 8:33 AM, David Jencks wrote:
I'd like to check that this doesn't violate any philosophical
principles behind deployment. I think that all classes used at
runtime should be available at deployment time: this patch checks
that all dependencies are in fact present at deployment time. Any
arguments?
thanks
david jencks
On Jan 25, 2005, at 1:30 PM, [EMAIL PROTECTED] wrote:
Author: djencks
Date: Tue Jan 25 13:30:16 2005
New Revision: 126427
URL: http://svn.apache.org/viewcvs?view=revrev=126427
Log:
If a dependency is missing, let us know immediately, not when a
class can't be loaded
Modified:
geronimo/trunk/modules/service-builder/src/java/org/apache/geronimo/
deployment/service/ServiceConfigBuilder.java
Modified:
geronimo/trunk/modules/service-builder/src/java/org/apache/geronimo/
deployment/service/ServiceConfigBuilder.java
Url:
http://svn.apache.org/viewcvs/geronimo/trunk/modules/service-builder/
src/java/org/apache/geronimo/deployment/service/
ServiceConfigBuilder.java?view=diffrev=126427p1=geronimo/trunk/
modules/service-builder/src/java/org/apache/geronimo/deployment/
service/ServiceConfigBuilder.javar1=126426p2=geronimo/trunk/modules/
service-builder/src/java/org/apache/geronimo/deployment/service/
ServiceConfigBuilder.javar2=126427
===
===
---
geronimo/trunk/modules/service-builder/src/java/org/apache/geronimo/
deployment/service/ServiceConfigBuilder.java(original)
+++
geronimo/trunk/modules/service-builder/src/java/org/apache/geronimo/
deployment/service/ServiceConfigBuilder.javaTue Jan 25 13:30:16 2005
@@ -53,6 +53,7 @@
import org.apache.geronimo.kernel.Kernel;
import org.apache.geronimo.kernel.config.ConfigurationModuleType;
import org.apache.geronimo.kernel.repository.Repository;
+import
org.apache.geronimo.kernel.repository.MissingDependencyException;
import org.apache.xmlbeans.XmlException;
/**
@@ -153,7 +154,7 @@
public static void addIncludes(DeploymentContext context,
DependencyType[] includes, Repository repository) throws
DeploymentException {
for (int i = 0; i includes.length; i++) {
DependencyType include = includes[i];
-URI uri = getDependencyURI(include);
+URI uri = getDependencyURI(include, repository);
String name = uri.toString();
int idx = name.lastIndexOf('/');
if (idx != -1) {
@@ -176,7 +177,7 @@
public static void addDependencies(DeploymentContext context,
DependencyType[] deps, Repository repository) throws
DeploymentException {
for (int i = 0; i deps.length; i++) {
-URI dependencyURI = getDependencyURI(deps[i]);
+URI dependencyURI = getDependencyURI(deps[i], repository);
context.addDependency(dependencyURI);
URL url;
@@ -264,7 +265,7 @@
return gBeanData;
}
-private static URI getDependencyURI(DependencyType dep) throws
DeploymentException {
+private static URI getDependencyURI(DependencyType dep,
Repository repository) throws DeploymentException {
URI uri;
if (dep.isSetUri()) {
try {
@@ -280,6 +281,9 @@
} catch (URISyntaxException e) {
throw new DeploymentException(Unable to construct
URI for groupId= + dep.getGroupId() + , artifactId= +
dep.getArtifactId() + , version= + dep.getVersion(), e);
}
+}
+if (!repository.hasURI(uri)) {
+throw new DeploymentException(new
MissingDependencyException(uri + uri + not found in repository));
}
return uri;
}
Re: tranql test failure
Sorry for that. I was pretty sure to have done a rebuild prior to commit... Dain, thanks for having fixed this problem. Gianny David Jencks [EMAIL PROTECTED] wrote: (haven't discovered a tranql list...) I'm getting a test failure in tranql on os x [junit] Running org.tranql.sql.sql92.InjectRegisteredEmptyVisitorTest [junit] Tests run: 3, Failures: 3, Errors: 0, Time elapsed: 0.308 sec [junit] [ERROR] TEST org.tranql.sql.sql92.InjectRegisteredEmptyVisitorTest FAILED Anyone else seeing this? thanks david jencks
Re: ObjectInputStream with classloading
On 4/02/2005 5:02 AM, David Jencks wrote: 1. tranql has 2 implementations, one using the thread context cl and one using a known classloader. These are both broken. However, tranql is required to build geronimo modules so I dont think we should have tranql require geronimo modules as well. Any ideas? Does the TCCL one actually need the TCCL? The TCCL one (SerializableConverter.TCCLObjectInputStream) can be replaced by one using the configurationClassLoader of the Configuration which has loaded it. AFAIK, the one using a known ClassLoader (FieldMarshaller.MarshalledInputStream) can not be used as is. Instead, a not yet existing ClassLoaderDelegate (similar to DataSourceDelegate and TransactionManagerDelegate) needs to be provided. Regarding the correct implementation of the ObjecInputStream to support arrays and proxies, I assume that we will have to copy and paste the Geronimo helpers to TranQL. Is that OK? Thanks, Gianny
Re: Build was broken but might be fixed...
MockWebServiceInvoker has been wrongly committed? Thanks, Gianny On 5/02/2005 3:21 PM, David Jencks wrote: After getting too enthusiastic after fixing some bugs I checked in various files today that broke other things. My apologies. I think that everything is restored to working condition, I will rebuild on another system to make sure. Please complain if there are still problems. thanks david jencks
EJB QL is now supported
Hi, Just a quick mail to let you know that EJB QL is now supported. I am still in the process of writing JUnit tests, yet this is pretty it. I will keep GERONIMO-192 and GERONIMO-186 open until I complete my JUnit tests and will then close them. Meanwhile, if you discover a bug with the implementation, then I would prefer to add them appended to one of these two issues by now. Thanks, Gianny
RMI classloading
Hi, I would like to know if it would be helpful to have a RMI class server. Currently, I see two potential usage: * deployment: currently, we need to be carefull about the exceptions nested within DeploymentException otherwise we will get a ClassNotFoundException. As a matter of fact, by installing a security manager and with the correct policy file, local deployments work properly. Indeed, as the ClassLoader used under the cover by Configuration is a URLClassLoader, marshalled classes are properly annotated. * IIOP: here I guess that we will need to download the stubs somehow to the clients. If you think that this is a good thing to have, then I am happy to get it working. Thanks, Gianny
Assembly - two artefacts: assembly-deployer and assembly-server
Hi, I think that we should produce two artefacts as part of the assembly steps: * geronimo-assembly-server: only the stuff for the server; and * geronimo-assembly-deployer: only the stuff for the deployer. This way is it more easy for end-users to understand what is actually used by a geronimo deployer and a geronimo server. I know that assembly is planned to be moved outside of modules; and it should be great to split it into two projects at the same time. Any thoughts? Thanks, Gianny
Re: Getting a YourKit License
I am also interested. Thanks, Gianny Hiram Chirino [EMAIL PROTECTED] wrote: Hi Geronimo Developers, I shot an email out to the YourKit folks to see about getting a license for their most excellent profiler. Seems like the are willing to give us free licenses. Who interested, and would there be problem with dropping a link to YourKit from our website? Regards, Hiram Begin forwarded message: From: [EMAIL PROTECTED] Date: March 22, 2005 5:56:45 AM EST To: Hiram Chirino [EMAIL PROTECTED] Subject: Re: YourKit License Reply-To: [EMAIL PROTECTED] Hello Hiram, thank you for your interest in our product. Sure, we can grant free of charge licenses to developers of Apache Geronimo project. Please send us list of developers which need licenses (first and last names). In return it would like to have a link to YourKit somewhere in credits section of http://geronimo.apache.org/ (please take a look at http://groovy.codehaus.org/) Kind regards, Vladimir Kondratyev YourKit, LLC http://www.yourkit.com Don't get lost in data, get information!
Re: Mark DeLaFranier - new Apache Geronimo committer
BTW Mark, I hope that you will accept this offer :). Congrats for your upcoming commit status and, indeed, thanks for your hard work on interop. Gianny On 27/03/2005 10:45 AM, Dain Sundstrom wrote: Congratulation Mark and thank you for all the hard work you have in interop. -dain On Mar 25, 2005, at 2:57 AM, Geir Magnusson Jr. wrote: Dear Mark, The Apache Geronimo PMC has voted to offer you commit status on the Apache Geronimo project, as I believe that Alan and others are tired of having to commit your excellent patches :) Thank you for your participation so far in the project, and we all are excited to have you as a committer. Please let us know if you wish to accept this offer. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Incompatible API change in Configuration
My bad :( I must admit that this is a side effect that I have not duly considered. I considered the source and binary compatibility and I missed this serialization specific incompatibility. Gianny On 3/04/2005 6:15 AM, Jeremy Boynes wrote: On 3/22 in revision 158589 the API for Configuration changed in that the return type from getConfigurationClassLoader() changed from ClassLoader to a ConfigurationClassLoader. This means all configurations built before then are now inoperable with the current tree as the attribute type in the persisted GBeanData does not match the new signature. I can't find any discussion on the list around then that would alert users to this change. It is critical that we let people know when this kind of change is made. -- Jeremy
Re: John Sisson - new Apache Geronimo committer
On 6/04/2005 10:56 AM, [EMAIL PROTECTED] wrote: Thanks everyone! I would like to accept and I am waiting for approval from corporate legal. Regards, John Congratulations John! Gianny
Re: Spring cleaning
+1 I think that the webdav stuff should go too. Thanks, Gianny On 9/04/2005 1:34 AM, Jeremy Boynes wrote: It has been a very long time since we went around and cleaned up some of the things that seemed like good ideas at the time. I would like to propose a spring-cleaning exercise. For example, if we look in the sandbox we moved a lot of things there over a year ago on the basis that they might be useful later; this includes mail, remoting and explorer which have all been implemented differently in the trunk. I would suggest we remove everything from there except Gianny's webdav stuff (unless he thinks that should go too). There is also some utility stuff in the common, core and system modules that is not being used and which can be removed to reduce clutter and footprint. Finally, I'd like to revisit the dependencies we have. For example, I recently came across the case where we were using a RC version of the velocity jellybean but then they had cut the final release and we just had not upgraded. We should go back and see if there are more instances of this. We may also find that by removing some of the clutter some dependencies can also be removed entirely. Any thoughts, objections, or additional stuff that could be cleaned up? -- Jeremy
Re: How to build Geronimo offline.
Hi Kishor,
You need to add these two lines in the project.properties file located
under the root of the geronimo source code:
maven.proxy.host=hostname
maven.proxy.port=port
Thanks,
Gianny
On 1/06/2005 10:28 PM, kishor wrote:
The other problem is that I got Proxy sever to connect to internet
I think some where in maven.xml I must provide the proxy setting to
download jars.
Regards
Kishor
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 01, 2005 10:22 AM
To: dev@geronimo.apache.org
Subject: Re: How to build Geronimo offline.
kishor wrote:
Hi all,
I'm new to Geronimo,
I want to build Geronimo offline, Don't want Maven to download jars at
build
time,
Can any one tell me where I will get the docs ?
First time through it is much easier to build online to get all the
dependencies. After that:
$ maven -o
If bandwidth is a big problem, you can download a lot of the
dependencies in one go by just trying to build the assembly module:
$ cd modules/assembly
$ maven build:start
and then go back to the root and build offline. A few modules not used
by assembly will not have been downloaded resulting in failures in those
modules. You can build those using
$ maven -Dmodules=${failed_module}
Painful, but a possible workaround to avoid all the snapshot checks.
--
Jeremy
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at [EMAIL PROTECTED] and delete this mail.
_
Re: Klustering and Kache
This is a great news! The WADI community is also working on providing clustering capabilities to Geonimo. The first-pass is still not yet checked-in and I expect to have it checked it next week. The implementation will provide: * pluggable replication strategy; * support of a large number of nodes thanks to state partitioning; * session relocation (move this state to this node as an inbound request bound to this state has been received on the node); * request relocation or proxying; and * pluggable transport: Tribes, JGroups, ActiveCluster on top of ActiveMQ. As part of this integration, we are also ensuring full pluggability of clustering framework for Geronimo, i.e. Klustering and Kache can easily be plugged in. Thanks, Gianny Jeff Genender wrote: Hey community, I just wanted to pass a note that some of us are working on the geronimo-cache which is a first-pass at clustering in the sandbox: http://svn.apache.org/repos/asf/geronimo/sandbox/geronimo-cache/ Its the beginning of a full replication implementation...its a start. I would like to invite any and all to feel free to jump in and chat about it on the lists. Its not fully functional but its a hopeful move in the right direction. Thanks, Jeff
Re: Namespace-driven builders and the UPA rule
Hi, Is there a way to do this substitution of JACC implementation by providing a substitutionGroup attribute to the security element? This may be not be correct; yet, this could look like this: xs:complexType name=security xs:sequence xs:element ref=security:security minOccurs=0/ /xs:sequence /xs:complexType xs:complexType name=pluggable-security xs:complexContent xs:extension base=geronimo:security/ xs:sequence xs:element name=jacc-implementation type=xs:string/ /xs:sequence /xs:extension /xs:complexContent /xs:complexType xs:element substitutionGroup=geronimo:security name=pluggable-security type=geronimo:pluggable-security/ xs:complexType name=applicationType xs:sequence xs:element ref=sys:environment/ xs:element name=module type=geronimo:moduleType minOccurs=0 maxOccurs=unbounded/ xs:element name=ext-module type=geronimo:ext-moduleType minOccurs=0 maxOccurs=unbounded/ xs:element name=security type=geronimo:security minOccurs=0/ xs:element ref=sys:gbean minOccurs=0 maxOccurs=unbounded/ /xs:sequence !--TODO application name should be settable using name-key in the environment. Does this work? -- xs:attribute name=application-name type=xs:string use=optional/ /xs:complexType I think that this approach is more verbose than the namespace-driven approach; however, it is then easier to read the schema and understands how to swap the JACC implementation. Thanks, Gianny David Jencks wrote: For the pluggable jacc implementation (GERONIMO-1563) I've been working on making a basic namespace-driven builder framework. The code is simple and looks like it will work fine but. there's a problem with the schema unique particle attribute rule, which basically says that in order for a schema to be valid each element can only be parsed in one way, and the way must be determined without looking forward or backwards or looking very hard at the context. OK. So, I wanted to make the geronimo security element namespace-driven, so if you used the current security-1.1 namespace you'd get our current impl, if you used something else you'd get that impl. We had ... xs:element name=ext-module type=geronimo:ext-moduleType minOccurs=0 maxOccurs=unbounded/ xs:element ref=security:security minOccurs=0/ xs:element ref=sys:gbean minOccurs=0 maxOccurs=unbounded/ /xs:sequence In order to make the security element variable, it needs to be xs:any namespace=##other minOccurs=0:/ Then in order to prevent the first gbean matching this if there's no security element I have to make the gbeans work through namespace driven builder too, and get ... xs:element name=ext-module type=geronimo:ext-moduleType minOccurs=0 maxOccurs=unbounded/ xs:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ /xs:sequence This works fine for the geronimo-application schema the problem comes with the web schemas (and perhaps the openejb schema, I haven't got that far yet). We now have xs:group ref=naming:jndiEnvironmentRefsGroup/ xs:element ref=naming:message-destination minOccurs=0 maxOccurs=unbounded/ xs:sequence minOccurs=0 xs:element name=security-realm-name type=xs:string/ xs:element ref=security:security minOccurs=0/ /xs:sequence xs:element ref=sys:gbean minOccurs=0 maxOccurs=unbounded/ /xs:sequence With a similar combination as in the g-app schema we'd get: xs:group ref=naming:jndiEnvironmentRefsGroup/ xs:element ref=naming:message-destination minOccurs=0 maxOccurs=unbounded/ xs:element name=security-realm-name type=xs:string minOccurs=0/ xs:any namespace=##other processContents=lax minOccurs=0 maxOccurs=unbounded/ /xs:sequence if the security-realm-name element was required there'd be no problem, you could tell that the naming elements are not part of the anys at the end. However if it is missing, the naming elements could match the explicit elements or the anys. I don't know how to get by this problem. xmlbeans has a no-upa option which might let use use this schema, but it's an invalid schema, so this is not completely desirable. We could turn the entire schema into a bunch of anys, but this sort of loses the point of having a schema. We could make an incompatible change to the schema, or we could special case the current security namespace and effectively introduce another element to hold other builders security info, something like xs:sequence minOccurs=0 xs:element name=security-realm-name type=xs:string/ xs:choice xs:element ref=security:security minOccurs=0/ xs:element
Re: Request change to RTC Process
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: Let's take this as an example. As we haven't discussed it yet, it seems to me that such a change requires 3x+1 from PMC members. So, only when this vote (it should possibly be a separate vote with 72-hour vote period to bring more attention) passes committers who are not PMC members have their +1 binding. Am I correct? No. Only PMC votes are binding. There is only an issue here because the PMC != committers. I think the most desirable solution is PMC === committers, but other people on the PMC disagree. Indeed, I disagree and I would like have this rule relaxed in the case of RTC votes. I think that one of the main goals of RTC is to encourage discussion of code changes and have a more collaborative development process. I do not see how this restriction (only PMC votes are binding) promotes further collaborative development. Having said that, this change to RTC is a very nice change as it is now easier to follow what people are working on and more people can get involved and contribute. Ken, could you please tell us if it is possible to relax the RTC rule? If this is not possible, then is it possible to relax the pre-requisites to be able to vote? For instance, I had a look to David J. JACC patch; I am fine with it; however, I have not applied and tested it; so, I cannot vote. Thanks, Gianny - -- #kenP-|} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRJVk7prNPMCpn3XdAQIn3gQAlrUGNSNUZomw99D6efCrF2vGysX7lFVf OXGXMBcygerrUCoT7ldp0nylh18FDDiiYWoTzzAxsTWjYodwjUGVrbTX6Q/3o+hF Q+liFMYqo5p46kI2DZdbz8T//s/MsztCt9JC/zmAu5oYfQZtOpRe/t/aaJcie6Dy gCuDNpG/X4Y= =SBLj -END PGP SIGNATURE-
Re: [announce] Apache Geronimo welcomes Joe Bohn as our newest committer
Congratulations Joe! Gianny Sachin Patel wrote: In recognition of his contributions to the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Joe Bohn. Joe has contributed in many areas, including the console and as of recent, the work on our minimal distributions. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. We look forward to his continued involvement as a committer. Please join us in congratulating Joe. The Apache Geronimo PMC
Re: [VOTE] Geronimo 1.1, DayTrader 1.1 and Specs 1.1 Final-2 Vote
+1 Gianny Matt Hogstrom wrote: The corrections applied due to license files are first in this list. Thanks to John for dogging this. The distributions and builds were not affected. Based on previous feedback the vote continues. Thanks for your feedback. *Geronimo 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-1.1-final-2.1_src.zip John noted that the source zip had a META-INF. I've created a script to use in the future because with so many changes forgetting to use zip and typing jar is not acceptable. Also, note that the build itself has the LICENSE and NOTICES in two different places. The are located in modules/scripts/src/main/resources/ which put the right files in the distributions however they werenot correctly specified for source as the LICENSE and NOTICES are part of the source tree. After this release we need to address this issue so as to avoid manual problems like this. *DayTrader 1.1 Version* *Source* http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.tar.gz http://people.apache.org/~hogstrom/1.1-final2/daytrader_src-1.1-final-2.1.zip Corrected LICENSE and NOTICES files. Use zip rather than jar to create zip. *Ear* http://people.apache.org/~hogstrom/1.1-final2/daytrader-ear-1.1-final-2.1.ear Corrected LICENSE and NOTICE files in ear. John, whats the correct command to set the properties? Or, would you like to address these? No changes to the below files. *Full J2EE Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-j2ee-1.1-final-2.zip *Minimal Jetty Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-jetty-minimal-1.1-final-2.zip *Full Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-j2ee-1.1-final-2.zip *Minimal Tomcat Version* http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/geronimo-tomcat-minimal-1.1-final-2.zip *Geronimo 1.1 Spec Jars* *Source* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs_src-1.1-final-2.zip *Binaries* http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.tar.gz http://people.apache.org/~hogstrom/1.1-final2/org.apache.geronimo.specs-1.1-final-2.zip
Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
+1 Gianny David Blevins wrote: We had this whole conversation last week, lots of good discussion was had. I'd prefer not to have to have it again. Here is my exact understanding of our consensus and would like to put it to a vote to avoid reinterpretation of that consensus in the future. 1. branches/x.y would be the branch for all x.y.z releases 2. when a release is frozen, we spin off a branch with that *exact* name, as in branches/x.y.z, where z starts at zero and increments by one. 3. at that time branches/x.y is immediately updated to version x.y.(z+1)-SNAPSHOT 3. We cut releases from the frozen branch 4. When a release passes final tck testing and final vote, the frozen branch is moved to tags We create a branch at freeze time for the following reasons: 1. it takes *at least* one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed -- only 52 weeks a year. 2. stronger guarantee no one is updating the branch once frozen 3. less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed. 4. it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch. Here is my +1 -- David On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote: After the branches/1.1 was moved to tags there was some question as to what happened to the 1.1 branch. At that time some kind soul created a new branches/1.1.1. No activity has occurred in that branch and given that we'll need to define the release goals of 1.1.1 soon I'd like to propose the following. After 1.1 is released: * Delete branches/1.1.1 * Move branches/1.1.0 to tags/1.1.0 * Copy tags/1.1.0 to branches/1.1.1 * Update branches 1.1.1 to be 1.1.1-SNAPSHOT * Start working on 1.1.1 When 1.1.1 enters time for release * Move branches/1.1.1 to branches/1.1.1.0 * Change version from 1.1.1-SNAPSHOT to 1.1.1 * Create release candidate rc1 * put out for a vote * get a successful vote with no respins :) * move from branches/1.1.1.0 to tags/1.1.1.0 Based on all the confusion in the past I think this procedure makes it clear what phase were in for the release as well as avoids tagging and branching repeatedly. I'm looking for lazy consensus and not a formal vote. Matt
WADI Integration Preview
Hi, I have been working on a second integration attempt of WADI and I am posting here a high-level description of the current state of progress such that people can jump in. At this stage, this is a Jetty only attempt and I do believe that the same approach can be applied for Tomcat. The current integration provides (very unreliable) HttpSession state migration. It only works for a single Web-application; more effort is required on the WADI side to support multiple Web-applications and this will not impact the integration piece of code. I (more or less successfully) tested the integration with mod_proxy + mod_proxy_balancer and mod_proxy + mod_rewrite in front of three Geronimo servers running the WADI demo web-app. The code changes are: * new module to capture some clustering contracts – geronimo-clustering: there Node, SessionManager, Session and ClusteredInvocation are defined. * new module to provide a WADI implementation of the above – geronimo-clustering-wadi; * new module to capture clustering builder contracts – geronimo-clustering-builder: there is only one interesting interface JettyClusteringBuilder. This later defines a couple of methods to augment the environment of a Web module being built and add clustering specific GBeans; * new module to provide a WADI implementation of the above – Geronimo-clustering-builder-wadi; and * geronimo-jetty-builder and geronimo-jetty are impacted to hook in clustering. These two modules depend on geronimo-clustering and geronimo-clustering-builder and not on WADI specific modules. Two new modules are added: * jetty-clustering- wadi: this module defines default WADI GBeans such as Dispatcher, ReplicationManagerFactory, BackingStrategyFactory et cetera; and * jetty-clustering-builder-wadi: this module defines a builder to process Jetty DD and add various GBeans to the module being built. I think that the implementation is flexible enough to plug in another clustering implementation such as Kache. As a matter of fact, there are some severe reliability (e.g. locking issues) and integration (only one Web-app can be clustered) issues, which need to be fixed. So, this work is not yet ready to be RTC voted and I do not think that it will before a couple of weeks. Having said that, I have opened a JIRA (http://issues.apache.org/jira/browse/GERONIMO-2163) such that people can have a look to the integration. Thanks, Gianny
Re: [RTC] pluggable jacc
Hi, I had a look to the patch and I think that it will take me about one night to review it. As I will be on holidays this Friday, only 2 nights left, and away from any computer for 3 weeks, I am happy to vote now if need be. I do have a couple of questions, more for my education than anything else: * why is the root security element used as a placeholder for group substitution in the geronimo-application schema? I would have thought that this placeholder would be better in the geronimo-security schema where the out-of-the-box/Geronimo substitution group is defined; and * I think that SecurityBuilder should have a way to modify the Environment of a Web-app module and, hence, that an additional method should be added to do that during the createModule phase. Otherwise, I am not sure how additional parent modules or specific dependencies can be added to a Web-app module such that the GBeans added by the builder can run. Also, it is worth to underline that the definition of a substitutable service element, which is currently replaceable by a gbean element seems to be a very flexible configuration mechanism. What would be awesome is to be able to register additional ElementConverter with SchemaConversionUtils such that developers working on their home grown substitution groups do not need to change this class. Obvisously, I am sold :) Thanks, Gianny David Jencks wrote: I think my latest patch for pluggable jacc is plausible to commit, see http://issues.apache.org/jira/browse/GERONIMO-1563?page=all and be sure to apply only the v4 patches. I realize this is a significant amount of work, so at this time I'm not actually asking any PMC members to review this, but I would greatly appreciate it if at least 3 could spend a couple minutes estimating how long they think it would take them to evaluate the patch and when they might be able to complete evaluating it, as this will personally affect my plans for the next few weeks. I think all the committers and other contributors might find this information useful in planning their development activities for the next few months. Many thanks, david jencks
Re: [RTC] pluggable jacc
Gianny Damour wrote: Hi, I had a look to the patch and I think that it will take me about one night to review it. As I will be on holidays this Friday, only 2 nights left, and away from any computer for 3 weeks, I am happy to vote now if need be. I do have a couple of questions, more for my education than anything else: * why is the root security element used as a placeholder for group substitution in the geronimo-application schema? I would have thought that this placeholder would be better in the geronimo-security schema where the out-of-the-box/Geronimo substitution group is defined; and * I think that SecurityBuilder should have a way to modify the Environment of a Web-app module and, hence, that an additional method should be added to do that during the createModule phase. Otherwise, I am not sure how additional parent modules or specific dependencies can be added to a Web-app module such that the GBeans added by the builder can run. Also, it is worth to underline that the definition of a substitutable service element, which is currently replaceable by a gbean element seems to be a very flexible configuration mechanism. What would be awesome is to be able to register additional ElementConverter with SchemaConversionUtils such that developers working on their home grown substitution groups do not need to change this class. Forget this point... While trying to see how this could be done I discovered that it is actually already done, by XmlBeansUtil... Thanks, Gianny Obvisously, I am sold :) Thanks, Gianny David Jencks wrote: I think my latest patch for pluggable jacc is plausible to commit, see http://issues.apache.org/jira/browse/GERONIMO-1563?page=all and be sure to apply only the v4 patches. I realize this is a significant amount of work, so at this time I'm not actually asking any PMC members to review this, but I would greatly appreciate it if at least 3 could spend a couple minutes estimating how long they think it would take them to evaluate the patch and when they might be able to complete evaluating it, as this will personally affect my plans for the next few weeks. I think all the committers and other contributors might find this information useful in planning their development activities for the next few months. Many thanks, david jencks
Re: Patches in RTC (Geronimo - August 4, 2006)
This is simply awesome! Thanks for that David. Gianny [EMAIL PROTECTED] wrote: Geronimo - August 4, 2006 9 Patches in RTC [XBEAN-33] [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. - Assignee: Hiram Chirino - Reporter: Hiram Chirino - Created: Tue, 1 Aug 2006 13:03:57 -0700 (PDT) - Updated: Tue, 1 Aug 2006 13:13:56 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/XBEAN-33 [XBEAN-19] [RTC] Enable inverse classloading with the classpath element - Assignee: Guillaume Nodet - Reporter: Guillaume Nodet - Created: Fri, 16 Jun 2006 14:13:24 -0700 (PDT) - Updated: Tue, 1 Aug 2006 01:33:30 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/XBEAN-19 [GERONIMODEVTOOLS-93] Support for non-plugin archives for installable runtimes - Assignee: Sachin Patel - Reporter: Sachin Patel - Created: Mon, 31 Jul 2006 07:22:56 -0700 (PDT) - Updated: Thu, 3 Aug 2006 14:26:10 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-93 [GERONIMO-2248] Applications portlets: List Parent and Child components against each component - Assignee: Unassigned - Reporter: Vamsavardhana Reddy - Created: Sun, 30 Jul 2006 08:15:34 -0700 (PDT) - Updated: Tue, 1 Aug 2006 02:08:20 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2248 [GERONIMO-2224] Add a geronimo specific system property for controlling dom, sax, and transformer creation - Assignee: Dain Sundstrom - Reporter: Dain Sundstrom - Created: Mon, 24 Jul 2006 14:02:56 -0700 (PDT) - Updated: Fri, 4 Aug 2006 12:12:30 -0700 (PDT) - Votes: 1 1 Donald Woods - http://issues.apache.org/jira/browse/GERONIMO-2224 [GERONIMO-2163] WADI Integration for Jetty - Assignee: Gianny Damour - Reporter: Gianny Damour - Created: Sun, 2 Jul 2006 14:16:35 -0700 (PDT) - Updated: Fri, 4 Aug 2006 12:03:16 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2163 [GERONIMO-2084] The transaction manager needs uncesseraly ties users to the TransactionContextManager implementation - Assignee: Unassigned - Reporter: Guillaume Nodet - Created: Mon, 5 Jun 2006 14:47:20 -0700 (PDT) - Updated: Fri, 4 Aug 2006 12:01:23 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2084 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri, 12 May 2006 14:54:17 -0700 (PDT) - Updated: Fri, 4 Aug 2006 12:00:00 -0700 (PDT) - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMO-1563] [RTC] Make the JACC implementation pluggable - Assignee: David Jencks - Reporter: David Jencks - Created: Wed, 1 Feb 2006 02:26:12 -0800 (PST) - Updated: Fri, 4 Aug 2006 12:02:25 -0700 (PDT) - Votes: 2 1 Alan Cabrera 2 Donald Woods - http://issues.apache.org/jira/browse/GERONIMO-1563 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the Begin RTC Review link under the Available Workflow Actions of the JIRA page. If you do not see your vote here, click the Vote link under the Operations section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***
Re: Regarding Exploded Deployments
Manu George wrote: Hi, Does Geronimo support exploded deployments of ear's that contain wars and jars using --inPlace Argument? When I try to deploy daytrader by extracting it to a directory and passing the path to the directory as an argument to deploy along with --inPlace it is giving an error java.lang.Error: Only local file jars are supported jar:file:/C:/1.1samples/samp les/applications/daytrader/target/test/daytrader-ear-1.1/web.war!/WEB-INF/lib/st andard-1.1.1.jar There is a bug in the deployment of war module defining libraries within WEB-INF/lib/ when this module is inside an ear module. I will fix this problem. What is the correct format of an exploded EAR. Will it have the ejb-jar and webapp-war exploded as well? OR will geronimo support non exploded format as well? In the case of an in-place deployment, nested modules are auto-exploded upon deployment, if need be. For instance, if there is a non-exploded war module mywar.war within an ear, then the war is renamed mywar.war.saved, a sub-directory mywar.war is created and mywar.war.saved is unjarred within it. Thanks, Gianny Regards Manu
Re: Regarding Exploded Deployments
Hi Manu, Thanks for having a look at this piece of code. EJB modules do not need to be auto-exploded as they are JAR modules and the classloader used to load EJB classes (a MulitParentClassLoader) can directly load classes from JARs. In the case of WEB modules, they need to be exploded as, AFAIK, Jetty and Tomcat do not support packed WAR modules. Also, while re-reading my email, I spotted a potential mis-interpretation. The problem you are raising only happens when an EAR module contains a non-exploded WAR module. In other words, if you unjar web.war within a web.war sub-folder, then everything should be OK. Thanks, Gianny Manu George wrote: Hi Gianny, Thanks for the explanation. Are ejb modules also auto exploded? I saw that war's are exploded but ejb modules don't seem to be auto exploded. Any reason for this? Thanks Manu On 8/5/06, Gianny Damour [EMAIL PROTECTED] wrote: Manu George wrote: Hi, Does Geronimo support exploded deployments of ear's that contain wars and jars using --inPlace Argument? When I try to deploy daytrader by extracting it to a directory and passing the path to the directory as an argument to deploy along with --inPlace it is giving an error java.lang.Error: Only local file jars are supported jar:file:/C:/1.1samples/samp les/applications/daytrader/target/test/daytrader-ear-1.1/web.war!/WEB-INF/lib/st andard-1.1.1.jar There is a bug in the deployment of war module defining libraries within WEB-INF/lib/ when this module is inside an ear module. I will fix this problem. What is the correct format of an exploded EAR. Will it have the ejb-jar and webapp-war exploded as well? OR will geronimo support non exploded format as well? In the case of an in-place deployment, nested modules are auto-exploded upon deployment, if need be. For instance, if there is a non-exploded war module mywar.war within an ear, then the war is renamed mywar.war.saved, a sub-directory mywar.war is created and mywar.war.saved is unjarred within it. Thanks, Gianny Regards Manu
Re: Drop the m1 build
+1 Gianny Dain Sundstrom wrote: I propose we remove the m1 build. It has been broken for several days now and no one has noticed. Here is my vote: +1 to remove the m1 build -dain
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Gianny On 15/08/2006, at 4:14 AM, Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: Move trunk, tags and branches to server/*
+1 Gianny On 16/08/2006, at 11:49 AM, Matt Hogstrom wrote: +1...good first step Jason Dillon wrote: I think we should move the top-level trunk, tags and branches to server/*. This will make the top-level of our repository more consistent. Specifically, I think we should: svn mkdir https://svn.apache.org/repos/asf/geronimo/server svn mv https://svn.apache.org/repos/asf/geronimo/tags https:// svn.apache.org/repos/asf/geronimo/server/tags svn mv https://svn.apache.org/repos/asf/geronimo/trunk https:// svn.apache.org/repos/asf/geronimo/server/trunk svn mv https://svn.apache.org/repos/asf/geronimo/branches https:// svn.apache.org/repos/asf/geronimo/server/branches And then update the pom's in server/trunk to reflect the new location for scm tags. --jason
Re: svn commit: r432773 - /geronimo/trunk/modules/geronimo-testsupport/src/main/java/org/apache/geronimo/testsupport/TestSupport.java
On 19/08/2006, at 9:15 AM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Fri Aug 18 16:15:53 2006
New Revision: 432773
URL: http://svn.apache.org/viewvc?rev=432773view=rev
Log:
Comments about BASEDIR and IDE magic
Modified:
geronimo/trunk/modules/geronimo-testsupport/src/main/java/org/
apache/geronimo/testsupport/TestSupport.java
Modified: geronimo/trunk/modules/geronimo-testsupport/src/main/java/
org/apache/geronimo/testsupport/TestSupport.java
URL: http://svn.apache.org/viewvc/geronimo/trunk/modules/geronimo-
testsupport/src/main/java/org/apache/geronimo/testsupport/
TestSupport.java?rev=432773r1=432772r2=432773view=diff
==
--- geronimo/trunk/modules/geronimo-testsupport/src/main/java/org/
apache/geronimo/testsupport/TestSupport.java (original)
+++ geronimo/trunk/modules/geronimo-testsupport/src/main/java/org/
apache/geronimo/testsupport/TestSupport.java Fri Aug 18 16:15:53 2006
@@ -37,6 +37,12 @@
private static final File BASEDIR;
static {
+//
+// TODO: Add some special magic here to figure this out
when we are running from
+// and IDE, like IDEA or Eclipse. user.dir/target
might work... but need
+// to validate what env each IDE has this set to.
+//
+
String tmp = System.getProperty(basedir);
Hi Jason,
This is the trick that Dain has suggested:
private static final tmp = System.getProperty(basedir,
System.getProperty(user.dir));
Thanks,
Gianny
if (tmp == null) {
throw new Error(Missing 'basedir' property; tests
need this property set to run correctly);
[RTC] WADI Integration for Jetty
Hi, I sent an email some time ago about some work being done to integrate WADI once again with Geronimo (subject was WADI Integration Preview). In the current stage, load-balancing is working reliably with two Geronimo instances behind an Apache server using mod_rewrite. I would like this piece of work to be reviewed and discussed. The JIRA is https://issues.apache.org/jira/browse/GERONIMO-2163. I have added some set-up comments such that it is easy to trial it. Note that you will need recent WADI dependencies (Jules, if you tell me how to deploy the WADI artefacts to the CodeHaus repo, then I am happy to do it). So far, what is provided is really basic (e.g. replication is not yet enabled), however I would like to see if people are generally happy with the current approach prior to enable other features. Thanks, Gianny
Re: TranQL EJBQL
Hi Andrus, Indeed, so far there is no plan to implement JPA on top of TranQL. Thanks for asking if your JPA QL work could somehow benefit to TranQL. Also, if you find some interesting pieces of code in TranQL that you would like to reuse, then please feel free to let me know. Thanks, Gianny On 19/08/2006, at 10:27 PM, Andrus Adamchik wrote: I am cc'ying to Gianny (hope I got the right address), but I'd still like to keep the thread public. Since the response from others (Matt) was essentially JPA QL support is not planned, and we need it now, I already started working on the parser on Cayenne side using JavaCC (I know TranQL uses antlr, but for Cayenne parser it made sense to stick with JavaCC if only to avoid extra runtime lib dependencies). I have the basic grammar in place, and hopefully should check it in soon. If there are any ideas or comments, or a desire to make it reusable outside Cayenne, let me know. Andrus On Aug 18, 2006, at 8:38 PM, Dain Sundstrom wrote: I don't think there are any plans, but you should send an email to Gianny as he is the only one working on the EJBQL code. If Cayenne is planing on using this code also, you two should talk about bringing TranQL to Apache (maybe the db project). -dain On Aug 17, 2006, at 8:57 PM, Andrus Adamchik wrote: Not sure if there is such thing as TranQL mailing list, so I figured, I'll ask here. Are there any plans to extend TranQL with EJB3 QL support? Thanks Andrus
Re: Disallow 1.5 on trunk (until its actually supported)?
+1 Gianny On 20/08/2006, at 5:44 PM, Jason Dillon wrote: I keep running into problems switching my local jdk (ala setjdk) from 1.4 to 1.5 and forgetting to switch it back again when making G builds. I though it would be nice if the build would fail early if I had the wrong JDK configured. So, I wroke a require-java-version goal in a new tools-maven-plugin (in Genesis), which allows the build to fail early. It uses Mac OS X-style version suffix tokens (+ and *) to allow selection. http://geronimo.apache.org/maven/genesis/plugins/tools-maven- plugin/usage.html I've set it up for GShell which needs 1.5, but I was wondering if we should configure this goal in trunk and set it to 1.4* so that if you are using 1.5 it will puke early with a meaningful error. Seems like folks who build with 1.5 run into errors... so maybe its a good thing to force 1.4? Thoughts? --jason
Re: svn commit: r432773 - /geronimo/trunk/modules/geronimo-testsupport/src/main/java/org/apache/geronimo/testsupport/TestSupport.java
This is cool that this also works in IDEA.
Regarding this proble, this is the script that I use to fix
the .classpath (from the geronimo dir):
ls */*/.classpath | while read file; do cat $file | grep -v classes/
META-INF ${file}_new; mv ${file}_new $file; done
BTW, in Eclipse System.getProperty(basedir, System.getProperty
(user.dir)) was working as by default Eclipse starts JUnit tests in
the project working directory, i.e. the module root.
Thanks,
Gianny
On 21/08/2006, at 2:25 PM, Jason Dillon wrote:
This was more what I was thinking:
snip
protected final File getBaseDir() {
File dir;
// If ${basedir} is set, then honor it
String tmp = System.getProperty(basedir);
if (tmp != null) {
dir = new File(tmp);
}
else {
// Find the directory which this class (or really the sub-
class of TestSupport) is defined in.
String path = getClass().getProtectionDomain().getCodeSource
().getLocation().getFile();
// We expect the file to be in target/test-classes, so go
up 2 dirs
dir = new File(path).getParentFile().getParentFile();
// Set ${basedir} which is needed by logging to initialize
System.setProperty(basedir, dir.getPath());
}
return dir;
}
/snip
Appears to work well too, in IDEA at least, probably works fine in
Eclipse too... but I've got a ton of Cannot nest output folder...
errors that prevent me from actually checking.
--jason
On Aug 19, 2006, at 8:11 AM, Dain Sundstrom wrote:
I don't think that trick will work for an IDE, as it will only
tell you which directory the IDE started in. In intellij you can
use something like this:
public static String baseDir() {
Class myClass = null; // TestClass.class
URL classUrl = myClass.getClassLoader().getResource
(myClass.getName().replace('.', '/') + .class);
if (classUrl == null) {
throw new RuntimeException(Could not find TestClass);
}
File targetDir = null;
try {
URLConnection urlConnection = classUrl.openConnection();
if (urlConnection instanceof JarURLConnection) {
JarURLConnection jarConnection =
(JarURLConnection) urlConnection;
classUrl = jarConnection.getJarFileURL();
targetDir = new File(new URI(classUrl.toString
())).getParentFile();
} else {
File classesDir = new File(new URI
(classUrl.toString())).getParentFile();
for (char c : myClass.getName().toCharArray()) {
if (c == '.') {
classesDir = classesDir.getParentFile();
}
}
}
} catch (Exception e) {
log.debug(Could not determine classes installation
directory, e);
}
if (targetDir != null) {
File moduleDir = targetDir.getParentFile();
return moduleDir.getAbsolutePath();
} else {
return System.getProperty(basedir, System.getProperty
(user.dir));
}
}
Make sure to test this code, because I didn't :)
-dain
On Aug 18, 2006, at 4:47 PM, Jason Dillon wrote:
Ya, I will add that as soon as I can verify that it works in IDEA
an Eclipse... probably sometime next week.
--jason
On Aug 18, 2006, at 4:31 PM, Gianny Damour wrote:
On 19/08/2006, at 9:15 AM, [EMAIL PROTECTED] wrote:
Author: jdillon
Date: Fri Aug 18 16:15:53 2006
New Revision: 432773
URL: http://svn.apache.org/viewvc?rev=432773view=rev
Log:
Comments about BASEDIR and IDE magic
Modified:
geronimo/trunk/modules/geronimo-testsupport/src/main/java/
org/apache/geronimo/testsupport/TestSupport.java
Modified: geronimo/trunk/modules/geronimo-testsupport/src/main/
java/org/apache/geronimo/testsupport/TestSupport.java
URL: http://svn.apache.org/viewvc/geronimo/trunk/modules/
geronimo-testsupport/src/main/java/org/apache/geronimo/
testsupport/TestSupport.java?
rev=432773r1=432772r2=432773view=diff
==
--- geronimo/trunk/modules/geronimo-testsupport/src/main/java/
org/apache/geronimo/testsupport/TestSupport.java (original)
+++ geronimo/trunk/modules/geronimo-testsupport/src/main/java/
org/apache/geronimo/testsupport/TestSupport.java Fri Aug 18
16:15:53 2006
@@ -37,6 +37,12 @@
private static final File BASEDIR;
static {
+//
+// TODO: Add some special magic here to figure this
out when we are running from
+// and IDE, like IDEA or Eclipse. user.dir/
target might work... but need
+// to validate what env each IDE has this set to.
+//
+
String tmp = System.getProperty(basedir);
Hi Jason,
This is the trick that Dain has suggested:
private static final tmp = System.getProperty(basedir,
System.getProperty(user.dir));
Thanks,
Gianny
if (tmp == null
Re: [RTC] WADI Integration for Jetty
Hi Matt, Thanks for having a look at it. As a matter of fact, I have been pretty useless with respect to reviewing patches; so, it is me who owes the apologies. Regarding the work in sandbox, I had a look to it when working on this patch. Even if I am not relying on it, I think that this work can be easily leveraged in the context of the proposed changes. Thanks, Gianny On 21/08/2006, at 11:58 PM, Matt Hogstrom wrote: Gianny, I will look at it this week. I had seen that it was out there for review but required more time than I had available in a single shot. Apologies for my tardiness. There is also some clustering work in sandbox that I think Jeff was working on. Are these complimentary efforts or completely separate? Gianny Damour wrote: Hi, I sent an email some time ago about some work being done to integrate WADI once again with Geronimo (subject was WADI Integration Preview). In the current stage, load-balancing is working reliably with two Geronimo instances behind an Apache server using mod_rewrite. I would like this piece of work to be reviewed and discussed. The JIRA is https://issues.apache.org/jira/browse/GERONIMO-2163. I have added some set-up comments such that it is easy to trial it. Note that you will need recent WADI dependencies (Jules, if you tell me how to deploy the WADI artefacts to the CodeHaus repo, then I am happy to do it). So far, what is provided is really basic (e.g. replication is not yet enabled), however I would like to see if people are generally happy with the current approach prior to enable other features. Thanks, Gianny
Re: svn commit: r394422 - in /geronimo/branches/1.1/modules: deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/ deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/ deploy-
Actually, my first pass was an ExtendedDeploymentManager defining a
distribute method taking such an additional parameter. I drop this idea
to implement this one because I wanted to stick to the JSR88 API.
Thanks,
Gianny
Aaron Mulder wrote:
OK. A little cheesy to set the flag, do the thing, and then unset the
flag, but I guess it works for 1.1. Maybe I'll put in a JIRA to make
this work better somehow (like call a Geronimo-specific method on the
DeploymentManager that implies or takes an argument for an in-place
deployment).
Thanks,
Aaron
On 4/15/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: gdamour
Date: Sat Apr 15 18:24:00 2006
New Revision: 394422
URL: http://svn.apache.org/viewcvs?rev=394422view=rev
Log:
Attempt to address Aaron's -1:
-1 to this change: the DeploymentManager can be used for many
operations in succession, and as written, the in-place flag is
persistent once set, whereas it my opinion in should only apply to a
single operation and if you do another deployment on the same
deployment manager you should need to specify the flag each time if
you want it each time
Modified:
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/CommandContext.java
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/CommandSupport.java
geronimo/branches/1.1/modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java
Modified:
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/CommandContext.java
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/CommandContext.java?rev=394422r1=394421r2=394422view=diff
==
---
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/CommandContext.java
(original)
+++
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/jmx/CommandContext.java
Sat Apr 15 18:24:00 2006
@@ -39,6 +39,14 @@
this.inPlace = inPlace;
}
+public CommandContext(CommandContext prototype) {
+this.logErrors = prototype.logErrors;
+this.verbose = prototype.verbose;
+this.username = prototype.username;
+this.password = prototype.password;
+this.inPlace = prototype.inPlace;
+}
+
public boolean isLogErrors() {
return logErrors;
}
Modified:
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/CommandSupport.java
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/CommandSupport.java?rev=394422r1=394421r2=394422view=diff
==
---
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/CommandSupport.java
(original)
+++
geronimo/branches/1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/CommandSupport.java
Sat Apr 15 18:24:00 2006
@@ -247,7 +247,7 @@
}
public void setCommandContext(CommandContext commandContext) {
-this.commandContext = commandContext;
+this.commandContext = new CommandContext(commandContext);
}
public static ModuleType convertModuleType(ConfigurationModuleType type) {
Modified:
geronimo/branches/1.1/modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java?rev=394422r1=394421r2=394422view=diff
==
---
geronimo/branches/1.1/modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java
(original)
+++
geronimo/branches/1.1/modules/deploy-tool/src/java/org/apache/geronimo/deployment/cli/CommandDistribute.java
Sat Apr 15 18:24:00 2006
@@ -63,9 +63,15 @@
Cannot perform in-place deployment.);
}
JMXDeploymentManager jmxMgr = (JMXDeploymentManager) mgr;
-jmxMgr.setInPlace(true);
+try {
+jmxMgr.setInPlace(true);
+return mgr.distribute(tlist, module, plan);
+} finally {
+jmxMgr.setInPlace(false);
+}
+} else {
+return mgr.distribute(tlist, module, plan);
}
-return mgr.distribute(tlist, module, plan);
}
protected String getAction() {
Re: svn commit: r394439 [1/3] - in /geronimo/branches/1.1: ./ applications/console-core/src/java/org/apache/geronimo/console/util/ applications/console-standard/src/java/org/apache/geronimo/console/ca
[EMAIL PROTECTED] wrote:
Author: ammulder
Date: Sat Apr 15 23:35:09 2006
New Revision: 394439
URL: http://svn.apache.org/viewcvs?rev=394439view=rev
Log:
Services can be deployed with a JAR and plan, or a plan in the JAR at
META-INF/geronimo-service.xml (GERONIMO-1859)
Improvements to configuration import/export, including more metadata
and no installations just to gather metadata
Improved handling for Artifacts that are missing parts (effectively
wildcards)
snip
Modified:
geronimo/branches/1.1/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java
URL:
http://svn.apache.org/viewcvs/geronimo/branches/1.1/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java?rev=394439r1=394438r2=394439view=diff
==
---
geronimo/branches/1.1/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java
(original)
+++
geronimo/branches/1.1/modules/service-builder/src/java/org/apache/geronimo/deployment/service/ServiceConfigBuilder.java
Sat Apr 15 23:35:09 2006
@@ -27,12 +27,15 @@
snip
DeploymentContext context = new DeploymentContext(outfile,
null,environment, ConfigurationModuleType.SERVICE, naming, repositories,
configurationStores);
+if(jar != null) {
+if(inPlaceDeployment) {
+//todo: add the JAR to the configuration Class Path and do
whatever else we need to (may need to set in-place directory on the
DeploymentContext just above?)
+throw new UnsupportedOperationException(In-place deployments are
not supported yet for services);
+} else {
+File file = new File(jar.getName());
+context.addIncludeAsPackedJar(URI.create(file.getName()), jar);
+}
+}
try {
ClassLoader cl = context.getClassLoader();
I have refactored DeploymentContext to easily add support for in-place
deployment of services (in a few words InPlaceEARContext has been
removed and DeploymentContext delegates to two distinct strategies).
Aaron, if you plan to work on in-place deployment of services, then I
think that I will get to that tomorrow during the day - so, if you can
wait until then...
Thanks,
Gianny
Re: svn commit: r394439 [1/3] - in /geronimo/branches/1.1: ./ applications/console-core/src/java/org/apache/geronimo/console/util/ applications/console-standard/src/java/org/apache/geronimo/console/ca
Actually, I hooked it in during my last commit; so, you can give it a shoot now. Thanks, Gianny Aaron Mulder wrote: On 4/16/06, Gianny Damour [EMAIL PROTECTED] wrote: I have refactored DeploymentContext to easily add support for in-place deployment of services (in a few words InPlaceEARContext has been removed and DeploymentContext delegates to two distinct strategies). Aaron, if you plan to work on in-place deployment of services, then I think that I will get to that tomorrow during the day - so, if you can wait until then... If you can hook this up for services too that would be great! Thanks, Aaron
in-place deployment - description
Hi, I think that in-place deployment is now complete and here is a short description of how it works: * a module is deployed in-place, via the distribute --inPlace usual parameters command; * only unpacked modules can be deployed in-place. If a packed module is deployed in-place, then the distribute command fails; * when a module is redeployed, the cli automatically retrieves if it was initially deployed in-place. If it was, then the module is redeployed in-place. Note that the redeploy command does not provide a switch to perform an in-place re-deployment; and * when an EAR module is deployed in-place, the WAR and RAR modules that it bundles are automatically unpacked, if need be. Basically, if we have: META-INF/application.xml myWeb.war After deployment, we have: META-INF/application.xml myWeb.war.saved -- myWeb.war has been renamed to this myWeb.war/ -- myWeb.war has been unzipped in this folder Regarding this automatic unpack, it seems that we may instead want to throw an exception in such a scenario. I am happy to remove this feature if it is too dangerous. At this stage, in-place deployment requires an explicit action from the user. It seems that we want to have by default in-place deployment for unpacked modules. Any objection to this change? Thanks, Gianny
Re: [jira] Closed: (GERONIMO-1871) Unable to deploy Tapestry app due to classloading issue
Actually, the fix is already in 1.1 (I just checked via the Subversion Commits tab that the commit has not disappeared into the ether). Thanks, Gianny Dain Sundstrom wrote: +1 absolutely Can you do it? -dain On Apr 22, 2006, at 7:36 PM, Jeff Genender wrote: Can we get this in 1.1? This is a pretty nasty bug. Jeff Gianny Damour (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1871?page=all ] Gianny Damour closed GERONIMO-1871: --- Resolution: Fixed The problem was that the TCCL was set to the Tomcat WebAppClassLoader and not the Geronimo TomcatClassLoader. WebAppClassLoader was defining all the jars in WEB-INF/lib, its parent was TomcatClassLoader, which was also defining these jars. Hence this duplication. Unable to deploy Tapestry app due to classloading issue --- Key: GERONIMO-1871 URL: http://issues.apache.org/jira/browse/GERONIMO-1871 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.2 Environment: Windows XP Reporter: Bryan Noll Assignee: Gianny Damour Priority: Critical
Re: [announce] Welcome Apache Geronimo's newest committer - Rick McGuire
Well done Rick and Welcome on board! Gianny Kevan Miller wrote: Congratulations Rick! --kevan On Apr 21, 2006, at 2:59 PM, Geir Magnusson Jr wrote: In recognition of his contributions and participation in the Apache Geronimo community, the Geronimo PMC is proud to announce the committership of Rick McGuire. Rick has contributed in many places, and is a pleasure to work with, and we look forward to his continued involvement as a committer. Please join us in congratulating Rick. The Apache Geronimo PMC
Re: 1.1 Build failure
Hi Rick, I also faced this problem and just checked in a fix for it. Thanks, Gianny Rick McGuire wrote: I'm getting a build failure that I don't seem to see anybody else getting. I'm doing fresh checkout and build, and the build fails with the following error: test:test: [echo] No tests to run. [touch] Creating C:\Geronimo\builds\1.1\applications\demo\target\test-report s\tstamp war:webapp: [echo] Assembling webapp geronimo-demo [mkdir] Created dir: C:\Geronimo\builds\1.1\applications\demo\target\geronim o-demo\WEB-INF\lib [mkdir] Created dir: C:\Geronimo\builds\1.1\applications\demo\target\geronim o-demo\WEB-INF\tld [mkdir] Created dir: C:\Geronimo\builds\1.1\applications\demo\target\geronim o-demo\WEB-INF\classes [echo] Use classes.jar ? true BUILD FAILED File.. C:\Geronimo\builds\1.1\maven.xml Element... maven:reactor Line.. 53 Column 110 Unable to obtain goal [multiproject:install-callback] -- C:\Geronimo\builds\1.1\ etc\maven.xml:241:93: ant:move C:\Geronimo\builds\1.1\applications\demo\target \geronimo-demo\WEB-INF\work not found. Total time: 11 minutes 28 seconds Finished at: Tue Apr 25 06:49:02 EDT 2006 This is easily fixed by delete 3 lines from etc/maven.xml that deals with moving files from the work directory. I'm not sure, however, if that's the correct fix. Are those lines obsolete and require deleting, or is something else failing here? Why don't others seem to be seeing this problem? Rick
Re: [announce] Apache Geronimo welcomes Guillaume Nodet as our newest committer
Congratulations Guillaume! Gianny Dain Sundstrom wrote: The Apache Geronimo PMC is proud to announce Guillaume Nodet as our newest Apache Geronimo committer, and look forward to his continued great work on XBean and the Geronimo integration with Service Mix. His work shows initiative, concern to get user feedback, empathy for problems faced by other committers and willingness to work on fixing these problems. Guillaume has consistently brought unique and very difficult use cases to the XBean project (along with patches), and it is these diverse requirements that will ultimately make XBean a success. We believe he will be an excellent addition to the project and will help foster these values in others. Please join us in congratulating Guillaume, The Apache Geronimo PMC
Re: [wadi-dev] Re: Tomcat version in G1.1 for clustering
Hi, Jeff, I do know that you are working hard on preparing the release of G1.1; however, when you get more time, could you please try to expand a little bit on this subject? I am curious to see how the Session API has been implemented and how it is leveraged to provide clustering capabilities. I recently had a look to the Session API and I am sure that WADI can easily provide an implementation. Also, I think that many users have been waiting for a more robust (clustering) solution and I believe that WADI can provide an enhanced implementation of the Session API for G1.2. Obviously, your work will help WADI developers to understand how to hook in WADI. Thanks, Gianny Jules Gosnell wrote: Jeff Genender wrote: Hi Matthew, Ultimately clustering should not be based on WADI directly, but for components that implement the session API interface. We want to make clustering components pluggable, so there is no hard coded clustering agent. With my WADI hat on: Agreed - this is the correct approach - however, for reasons stated in the related threads on this list, I believe that the proposed API has been positioned at the wrong level of abstraction. As such, I believe that it actually acts as a barrier to WADI's integration. I am unaware of WADI's status regarding its implementation of the session API. Jules or Greg would need to comment on this. I've given this a lot of consideration and come to the conclusion, that, whilst I have every intention of WADI and Geronimo being integrated, this integration is unlikely to occur via the proposed API in its current form. I think that WADI will continue to go down the route of integrating its front end directly with the tier in question, whilst exposing its backend to Geronimo management facilities. We (Geronimo) will have a session clustering component that will be offered as a part of Geronimo that will implement the session API interface shortly. Its been a side project for a couple of weeks ;-) With my Geronimo hat on: Sounds interesting. Is the design discussion going on in public somewhere or are you integrating an existing component? I am sure that there are many people on the list who would be interested in participating. Relative to the Tomcat clustering, yes this is an interim capability to allow for clustering the web tier. Although it will always be available, I believe we will have a more robust solution that works across all component in the near future. Stay tuned ;-) You bet :-) Jules Jeff Matthew Jording wrote: Jeff, Dave, I would like to implement a Geronimo Cluster Management Web Service and need some additional information on the advances of WADI integration. The current clustering examples seem to only be concerned with tomcat web tier clustering and doesn't seem to use WADI to facilitate the management of the sessions. Thanks Matt Jeff Genender wrote: Dave, Thanks for doing this. Jeff Dave Colasurdo wrote: I've validated that the Geronimo clustering example (http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example) still works for Geronimo 1.1 (with Tomcat 5.5.9). The application deployment plan (attached to email) required some changes. I'm now rebuilding G1.1 with Tomcat 5.5.15 to determine if the clustering Gbeans and plans still work.. -Dave- Jeff Genender wrote: IIRC, 5.5.15 went to backward compatibility... http://mail-archives.apache.org/mod_mbox/tomcat-users/200512.mbox/[EMAIL PROTECTED] Perhaps Filip can fill us in on this. If I remember right, the 5.5.9 clustering GBeans will work on forward versions. So I don't think there is a problem there. HEAD has been set to 5.5.15 for quite some time. Nevertheless, it doesn't hurt to try em out ;-) Jeff Dave Colasurdo wrote: Jeff (et al.), Will G1.1 definitely be upgraded to Tomcat 5.5.15? IIRC, the clustering deployment plans were quite different for 5.5.9 -vs- 5.5.12. If we upgrade to 5.5.15, we will likely need a new plan that accounts for both the webcontainer upgrade as well as the new G1.1 plan format.. Thanks -Dave- Jeff Genender wrote: Thanks Rainer. But I think 5.5.15 will be the one for 1.1. But possibly 5.5.17 for 1.2 ;-) Jeff Rainer Jung wrote: Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for
Re: 1.1 Package Upgrade List
Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). As a matter of fact, an upgrade to TranQL 1.3 requires some code changes to OpenEJB (repackaging). Also, it would be nice to port dynamic queries from trunk to 1.1. If there is no objection, I propose to do that this week-end and ensure that this does not break the tck. Thanks, Gianny I'll start testing these versions once we clean up a few problems. --kevan
Re: Remaining 1.1 Issues
Matt Hogstrom wrote: Based on the list below I think 1,2 and 3 are new function and 4 is a bug fix. Aaron Mulder wrote: Here are the things that I still want to squeeze into 1.1: - fix console JMS to accept new providers at runtime - fix console security realms to accept new providers at runtime - add a missing Geronimo security provider to console security realms - fix hot deploy dir so it notices files updated while the server was down and deletes files if they are undeployed some other way There are also AFAIK a number of not-yet-applied patches to review. Yes, there are several. I'm testing some performance related code. I'm waiting and hoping Codehaus comes up soon :) I think that I will give some heads up: I am also waiting for Codehaus to be back on line to apply an OpenEJB patch related to GERONIMO-1545 (infamous CASE WHEN ? THEN ? ELSE ). The patch does not break the tck. Thanks, Gianny Thanks, Aaron
Re: Moving on from 1.1
+1 Gianny Matt Hogstrom wrote: Jason replied on another thread that he prefers to stay with 1.2 for the release. Here is the proposed nomenclature trunk(stays 1.2 but is completely replaced with branches/1.1) branches/1.1unchanged branches/dead-1.2 (is a copy of the original trunk) I think that incorporates the thinking so far. I like it. Matt Matt Hogstrom wrote: I would like to make the following changes to the dev tree for Geronimo. Assuming there is concurrence and no objections I would like to: move geronimo/trunk to geronimo/branches/oldtrunk copy geronimo/branches/1.1 to geronimo/trunk Update trunk to version 1.3. I think 1.3 is a better choice to avoid any confusion over our old 1.2 I'll plan to do this on Wednesday morning at 0300 PT. Other thoughts welcome. Matt
Re: PATCH from GERONIMO-2006
+1 Gianny David Jencks wrote: I'd like to apply the patch http://issues.apache.org/jira/secure/ attachment/12334350/GERONIMO-2006.patch from http://issues.apache.org/jira/browse/GERONIMO-2006 It fixes a buffer overflow problem in tomcat (which presumably doesn't need a vote since it's a bug fix) and does some simple checks on the plan you supply to upgrade the plan if it is clearly a 1.0 plan. here's my +1. I'd like to know if it counts, see my separate post asking about this. here's the text of the patch: again I'd like to know if this is required or if the link to the jira issue is sufficient. Thanks david jencks
Re: [continuum] BUILD ERROR: Geronimo
Hi, I think that Continuum needs some help here. Can someone who has access to stan try to sort it out? (I think that deleting modules/console-web should do the trick). Thanks, Gianny continuum wrote: Online report : http://ci.gbuild.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/3625 Build statistics: State: Error Previous State: Error Started at: Mon, 29 May 2006 02:01:02 -0700 Finished at: Mon, 29 May 2006 02:01:27 -0700 Total time: 24s Build Trigger: Schedule Exit code: 0 Building machine hostname: stan.gbuild.org Operating system : Linux(unknown) Java version : 1.4.2_08(Sun Microsystems Inc.) Changes No files changed Build Error: Provider message: The svn command failed. Command output: --- svn: Failed to add directory 'modules/console-web': object of the same name already exists ---
Booth at OSCON Portland - IBM logistical and financial support
Hi, I believe that OSCON is offering free booth space to the ASF. The registration deadline for the next OSCON in Portland (end of July) is this Monday, June 5. IBM is offering the PRC logistical and financial support, e.g. t-shirts et cetera, for this upcoming event. IBM wants to help as they provide support offerings for Apache Geronimo and their WebSphere Application Server Community Edition is based on Geronimo; hence, their interest in promoting Geronimo at OSCON. If people are interested to staff the booth, then please respond as soon as possible as the registration needs to be submitted before Monday. If we have enough people, then we will register and contact IBM to determine how they can help. Thanks, Gianny
Re: Results of testing Gianny's TranQL Performance Improvements for CMP entity beans
Hi Matt, Thanks for posting these results :) Matt Hogstrom wrote: Gianny, I applied your changes to fix the double execution. It looks like the modifications you made overall improved performance by about 10% (from 1445 to 1591). However, I still see the double execution of the SQL for the Quote bean. So we can still eek out some extra performance. The best number on the servers I tested has been about 2000 so we're almost there :) When you say double execution, do you mean: 1. SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ?; followed by 2. SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? as reported under the *With TranQL Changes:* section? If yes, then I am not sure how this can be fixed without caching. The first query maps to the findByPrimaryKey method. After its execution, the transactional cache is being flushed as all the methods of QuoteEJB have a CMT set to Required and PingServlet2EntityLocal does not demarcate tx. As a consequence, the transactional cache is now empty. The second query maps to a row-fault event when getDataBean is invoked. There is a row-fault because the transactional cache is empty. With caching of CMP across transactions, the row-fault event does not happen: the cache is queried and a record is found. Here are the stats from the testing I did tonight. *Before TranQL Change:* 06/04/200622:02:25 IWL0060I Page throughput = *1445.272 /s* This data is already in the JIRA. *With TranQL Changes:* 06/04/200622:50:45 IWL0060I Page throughput = *1591.233 /s* snip *With TranQL CMP Caching Option:* 06/04/200623:01:09 IWL0060I Page throughput = *1988.110* /s These are the queries that are being executed while caching is enabled. Note the difference between the queries. I'm not sure why this is. The first query, 973 exec, is a row-fault query. The second query maps to findByPrimaryKey; it is the result of a transformation of SELECT Q.symbol FROM QuoteEJB Q WHERE Q.symbol = ? to fetch a group of fields at the same time than the primary key. In this case, the group to be prefetched is pretty simple: all the QuoteEJB CMP fields. However, the engine can fetch a graph of objects in a single pass. Thanks, Gianny Number of executions = 973 Number of compilations = 1 Total execution time (sec.ms) = 0.052875 Total user cpu time (sec.ms) = 0.015625 Total system cpu time (sec.ms) = 0.015625 Statement text = SELECT Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Number of executions = 221945 Number of compilations = 1 Total execution time (sec.ms) = 12.888160 Total user cpu time (sec.ms) = 9.843750 Total system cpu time (sec.ms) = 1.515625 Statement text = SELECT Q.symbol, Q.symbol, Q.low, Q.open1, Q.volume, Q.price, Q.high, Q.companyName, Q.change1 FROM QuoteEJB Q WHERE Q.symbol = ? Matt
Re: [jira] Commented: (GERONIMO-1638) Multiple servers sharing the same repo and config store
Hi Dave, Thanks for pointing this problem out. I simply forget to provide an AMQ patch to fix it; this is now done: http://issues.apache.org/activemq/browse/AMQ-746. Also, this feature is broken in 1.1. Basically, SharedLib and FileKeystoreManager do not properly resolve their resources and, as a consequence, the server simply shuts down. Thanks, Gianny Dave Colasurdo wrote: BTW, I think additional fixes are required in 1.1.1 before claiming support for multiple concurrent server instances from a single installation.. Awhile back I was able to start the server using an external var directory (via -Dorg.apache.geronimo.server.dir). After changing all the ports and trying to start a second instance from the default location, I encountered a startup exception regarding the activemq transaction journal. Suspect code changes are needed to relocate the journal to a location outside the installation directory. Thanks -Dave- John Sisson (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1638?page=comments#action_12415496 ] John Sisson commented on GERONIMO-1638: --- Currently working on scripts as discussed at http://www.mail-archive.com/dev@geronimo.apache.org/msg22807.html . Have made changes but they need to be tested on windows, cygwin and unix, so looks like this is going to be for 1.1.1 . Multiple servers sharing the same repo and config store --- Key: GERONIMO-1638 URL: http://issues.apache.org/jira/browse/GERONIMO-1638 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Gianny Damour Assignee: John Sisson Fix For: 1.1 David J. sent to the dev mailing list: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are located outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so they can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to relocate. I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like resolveVar and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the var trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now var. Several people have suggested putting an additional config-store into var for private use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks
Re: Key Generator Questions
Hi Neal,
Thanks for this feedabck. You are correct: it is pretty easy to write
some initialization code to create a sequence table and insert a value.
As a matter of fact, if you have a look to
org.tranql.pkgenerator.SequenceTablePrimaryKeyGenerator.initSequenceTable()
you can see that is is indeed super easy.
At some point, the sequence table was systematically initialized. As
reported by GERONIMO-682 - Automatic key generators too restrictive
(http://issues.apache.org/jira/browse/GERONIMO-682), this approach was
not considered as appropriate. I think that when the primary key
generators have been refactored this problem has been partially fixed.
Could you please open a JIRA to track the need of an optional element
enabling sequence table generation?
Thanks,
Gianny
Neal Sanche wrote:
Hi All,
Yesterday I had some fun with the sequence-table key generator. I had
this fragment at the end of my Entity deployment plan.
pkgen:key-generator
pkgen:sequence-table
pkgen:table-namesequence/pkgen:table-name
pkgen:sequence-namereminder/pkgen:sequence-name
pkgen:batch-size1/pkgen:batch-size
/pkgen:sequence-table
/pkgen:key-generator
I know, I should increase my batch-size, but really I am only doing
one at a time. But that's not my problem. Why doesn't the
key-generator create the table if it doesn't already exist? It took me
quite some time to figure out that it was looking for a table with two
columns, one called 'name' and one called 'value'. Yeah, I know, it's
pretty easy to guess it, but I couldn't find it documented. I'm sure I
didn't look everywhere, and could have looked in the source code to
find the columns.
Once I created my table, the application started throwing exceptions
like crazy! It turned out the misleading 'Transaction already rolled
back' errors were because the record in the table didn't exist. I'm
sure it would be super easy to create the record if it wasn't already
there, and start the numbering at 1. I'm just so surprised it doesn't
already have this ability. I'm sure I'm missing something, right?
So, as far as I know, in order to get the key generator to work, I
have to create the sequence table:
create table sequence (name varchar(240) not null primary key, value
integer);
And then add the sequence key:
insert into sequence values ('reminder',1);
And then it'll go. Before that it just complains loudly and rolls back
my transaction.
What am I missing?
Cheers.
-Neal
Re: RELEASE-NOTES-1.1
Hi Donald, There are very good points. How would you expect the server to behave in such scenarios? Currently the server will simply shut-down and, to some extent, I think that this is a safe behaviour. Thanks, Gianny Donald Woods wrote: What happens in the case that the files no longer exist on the next server startup? Two scenarios I'm worried about: 1) files were loaded from an NFS/Samba/SMB share which has become disconnected 2) Eclipse users who deploy the app into the server, test it, stop the server and then delete the project and files from Eclipse -Donald Aaron Mulder wrote: On 6/13/06, Lin Sun [EMAIL PROTECTED] wrote: I am trying to learn what the in-place deployment mean and how to use it. My understanding was that users can update the hot deploy files (for example, update one jsp file) in the Geronimo_home\deploy directory and server will redeploy the change automatically. This was not working in 1.0, as users need to replace the entire directory in the Geronimo_home\deploy directory. That should be true in both 1.0 and 1.1 (if not, I guess it's a bug). But in 1.1, there is a separate option, which is to not copy your files to the hot deploy directory at all, but instead use the deploy tool with a special option to enable an in-place deployment. This means that instead of copying your files into the server directory at all, it will deploy and access them from wherever they currently are. Thanks, Aaron But after reading your note below, I think I am lost. Please advise. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Mulder Sent: Thursday, June 08, 2006 7:23 PM To: dev@geronimo.apache.org Subject: Re: RELEASE-NOTES-1.1 - We should add a point about in-place deployment. Geronimo supports in-place deployment, which means an archive or directory can be deployed without being copied into the Geronimo directory tree.
Re: [VOTE] Matt Hogstrom as Release Manager (Re: Getting V1.0 out the door - first step ;-P)
+1 Gianny Davanum Srinivas wrote: +1 for Matt as the Release Manager. Let's do it :) Matt, Please familiarize yourself with how other projects do it and how prev releases were done. First step would be a release plan. thanks, dims On 10/19/05, Matt Hogstrom [EMAIL PROTECTED] wrote: All, We got a couple of +1's about getting G out the door by ApacheCon. I'd like to start formalizing our thinking about it and I think the first step is getting someone to step up and volunteer to lead the effort. I'll throw my hat in the ring as, at least for me, it will be a good learning experience in pulling everything together. And for everyone else as well so they can see how badly I suck at all things administrative :) For those more experienced and knowledgable ones out there that don't want to miss out on this great opportunity here is your opportunity to say, No, Matt, I would love to do it!!! In the unlikely event that I end up with the opportunity I'll start preparing by reviewing what we did last time when Jeff lead the team to Release victory. Don't be shy - Matt -- Davanum Srinivas : http://wso2.com/blogs/
Re: NEW - [VOTE] sponsor WADI to become sub-projects of Geronimo
+1 Gianny Jeff Genender wrote: The current PMCs of WADI have overwhelmingly voted to become a Geronimo sub-project. The incubator proposal is here... http://wiki.apache.org/incubator/WadiProposal Please vote if you'd like Geronimo to be the sponsor of the project during incubation [ ] +1 = I support the move to sponsor WADI during incubation as sub-projects of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ I'm obviously +1 :) Jeff
Re: [VOTE] Sponsor OpenEJB to become sub-project of Geronimo
+1 Gianny David Blevins wrote: The OpenEJB committers have discussed it and voted to be become a Geronimo sub-project. The incubator proposl is here: http://wiki.apache.org/incubator/OpenEjbProposal Please vote if you'd like Geronimo to be the sponsor of OpenEJB during incubation [ ] +1 = I support the move to sponsor OpenEJB during incubation as a sub-project of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ +1 from me
Re: [Vote] Alternate Proposal for Branch V1.0 for Geronimo at 23:59 PST 12/7
+1 Gianny Matt Hogstrom wrote: One more time. Based on wildly popular feedback. Here is an alternate branching proposal. [ ] +1 Branch V1.0 at 23:59 PST 12/7 [ ] -1 Defer branching provide proposed alternative Matt
Re: OpenEJB Question
Hi Manu,
This method is always supposed to get a String value.
When a custom primary key is used, its type must be declared in the
ejb-jar.xml DD via the prim-key-class element. Also, the primkey-field
elements in both the ejb-jar.xml DD and openejb-jar.xml DD must not be
set; these elements should be used only whne the CMP has a simple
primary key. Could you please confirm that none of these elements have
been set?
Thanks,
Gianny
Manu George wrote:
Hi,
I am facing a problem with some CMP EJBs with custom PrimaryKey
Classes. I am getting the EJBs deployed but during invoking of the
findbyprimarykey method I am getting a TransactionRolledBack
Exception. On investigating the cause of this I found that it was due
to a ClassCastException that was ocurring in TranQL. In the class
org.tranql.sql.jdbc.binding.StringBinding
there is a method setValue. Here during execution the value parameter
contains the custom primary key class cast as Object. In the setString
method it gives a ClassCastException. Shouldn't this be a
value.toString() here? or is this method always supposed to get just a
string value?
public void setValue(PreparedStatement ps, Object value) throws
SQLException {
ps.setString(index, (String) value);
}
Is there any specific property we need to put in openejb-jar.xml when
we use complex PrimaryKey classes over and above the entries in
ejb-jar.xml?
Also for the primkey-field value in the openejb-jar.xml what do we
put if we have a complex primary key consisting of 2 fields?
Thanks
Manu
Re: Fwd: OpenEJB Question
Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: Fwd: OpenEJB Question
Hi Manu, This was a simple TranQL fix. So, you simply need to build TranQL and drop it in your repo (you do not need a full rebuild of Geronimo). Thanks, Gianny Manu George wrote: Hi Gianny Great to know its fixed. Will try it out after building geronimo from source. Thanks Manu On 12/13/05, *Gianny Damour* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: Fwd: OpenEJB Question
Hi Aaron, I'm happy to cut a 1.2.2 TranQL release tomorrow night. However, and as pointed out by Manu, there was also an OpenEJB impact. So, it seems that we also need to re-cut an OpenEJB release. So far, I have checked in the fix to trunk and I will port the fix to the v2_0 branch if we decide to re-cut OpenEJB. Thanks, Gianny Aaron Mulder wrote: Gianny, Did the fix go into TranQL? Geronimo 1.0 is not using a TranQL snapshot right now, so someone would need to cut a new TranQL release for us to get the fix into Geronimo 1.0. Thanks, Aaron On 12/13/05, Gianny Damour [EMAIL PROTECTED] wrote: Hi Manu, Thanks for your debugging! This was a bug in IdentityDefinerBuilder, which was wrongly trying to identify a compound PK based on the number of primary key fields. This is now fixed. I will create a JIRA to track this issue tomorrow as it seems that JIRA is down tonight. Thanks, Gianny Manu George wrote: Hi Gianny, I have done all that you mentioned. I am still getting the error.I have replicated the issue in a simple EJB,the example CMP in Ed Roman's book Mastering EJB. I am attaching the stack trace and the plans below 17:02:05,211 WARN [SystemExceptionInterceptor] Product snip While i was debugging I saw a method public IdentityTransform getPrimaryKeyTransform(Entity entity) in the class IdentityDefinerBuilder. Here based on size of pkFields the SimplePKTransform or CompoundPKTransform class is selected. In the case of a custom class with 1 field also the SimplePKTransform is selected. Is this how it should behave? Could you give a general idea of how the primary key values are taken from the Custom classes in OpenEJB? Thanks Manu
Re: OpenEJB PK issue
You are right! And thanks for reviewing my commits :) Indeed, buildFaultHandler is still creating the wrong type of IdentityDefiner. I thought that all dependencies on the various IdentityDefiner implementations were removed from OpenEJB thanks to the introduction of IdentityDefinerBuilder; obviously, two references have been forgotten :( About createCMPFieldAccessors, the relatedEntity.getPrimaryKeyFields().size() test must also be replaced by an isCompoundPK test. However, it seems that we should add a special processing to handle a CMP field mapped to a FK column referencing the (single) PK column associated to a compound PK having a single field. Thanks, Gianny Manu George wrote: Hi Gianny, Was just seeing the fix you made. 1 question on that. In CMPContainerBuilder there are 2 methods private FaultHandler buildFaultHandler(SQLQueryBuilder queryBuilder, EJB definingEJB, CMRField field, int slot, boolean prefetch) throws QueryException and private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder queryBuilder, LinkedHashMap cmrFieldAccessor) I feel that in both of these methods instead of comparing based on relatedEntity.getPrimaryKeyFields().size() we need to change to ejb.isCompoundPK(). Am I right? Thanks Manu
Re: Another OpenEJB Question
Hi, I am surpised that OrderItem.setOrder_orderId gives an error. Could you please provide the stack trace (the TranQL part + the first OpenEJB element) along with the DDs? FWIW, there are a couple of integration tests for CMP and CMR overlap scenarios in the OpenEJB tree: sub-project: modules/itests test class: org.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean DDs: src/cmp2/cmrmapping Thanks, Gianny Manu George wrote: Hi, I have two CMPs with a 1:n relationship. CMP1 - Order - PK = OrderPK which has a single field orderId CMP2 - OrderItem = OrderItemPk which has 2 fields InventoryId and order_orderId OrderId and order_orderId are mapped When i do a setOrder_orderId in the ejbCreate of OrderItem geronimo gives an error during runtime saying cannot set read only field. When i don't set it geronimo says partial null key . In this case I set the cmr field in the ejbPostCreate method org.tranql.identity.UndefinedIdentityException: Partial null key at org.tranql.identity.DerivedIdentity.defineIdentity(DerivedIdentity.java:80) at org.openejb.entity.cmp.CMPCreateMethod.execute(CMPCreateMethod.java:175) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) Am I doing anything wrong here? Regards Manu
Re: OpenEJB PK issue
Hi Manu,
Once again, thanks for your debugging!
I had a look to the DD and I have identified why the itests showing this
specifc case are working for us and not for you: basically in our test,
we have a OTM relationship between a CMP with a simple PK on the
one-side and a CMP with a compound PK on the many-side. Your case is
slightly different: the CMP on the one-side has a compound PK and hence
another code path is used.
Basically, the problem that you are raising is exactly what I was trying
to describe in one of my previous email:
About createCMPFieldAccessors, the
relatedEntity.getPrimaryKeyFields().size() test must also be replaced
by an isCompoundPK test. However, it seems that we should add a special
processing to handle a CMP field mapped to a FK column referencing the
(single) PK column associated to a compound PK having a single field.
Hm; I realise that this was far to be understandable.
This special processing works as follow:
1. if the CMP field, CMPField, is mapped to a FK column;
2. if the PK column referenced by this FK column is associated to a
compound PK column;
3. if the compound PK uses more than one CMP field:
3.1 then the accessor of CMPField must be read-only. (this is what we
currently have)
4. otherwise:
4.1 the accessor of CMPField must be read-write.
This purpose of the if (null !=
ejb.getAssociationEndDefiningFKAttribute(name)) { block is to set the
CMR field at the same time than the CMP field when a CMP field is mapped
to a FK column. BTW, it seems that you are familiar with OpenEJB and
TranQL; so, do you want to work on a patch to fix this problem? FYI, we
have a large and very interesting piece of work ahead of us to support
the persistence part of the EJB3 specification :)
Thanks,
Gianny
Manu George wrote:
Hi Gianny,
I put in a dirty hack and got my app working. The
problem I was facing was in the
private LinkedHashMap createCMPFieldAccessors(SQLQueryBuilder
queryBuilder, LinkedHashMap cmrFieldAccessor) throws QueryException {
method in CMPContainerBuilder
Here there is a if (null !=
ejb.getAssociationEndDefiningFKAttribute(name)) {
check inside which the CMR foreign Key was set to a read only field
during deployment. In my app the CMR FK is a part of the primary key
also. So during ejbCreate it gives error saying that it is a readonly
field. I just added a check to not go into this loop if the FK is also
a part of the PK.
and the app seems to be working. Hope this gives you more info abt
the problem I am facing
Regards
Manu
Re: Regarding JIRA Geronimo-1374
Hi Manu,
I think that a new accessor for this specific case is a good idea. The
set method is exactly what it should be. Though, I think that we should
drop the pkClass.isIntance test: this set method is always invoked with
a CMP value, which is the unique field defined by the compound PK
pkClass. Also, it seems that the get method should do something very
similar. When we get the GlobalIdentity via cmrField, we want to
retrieve the unique value of its underlying identity. To do that, we can
use IdentityDefiner.extractIdentity, and then CMPFieldNestedRowAccessor.get.
Thanks for your work on this issue!
Gianny
Manu George wrote:
Hi Gianny,
Regarding JIRA Geronimo-1374
Modifying CompoundPKTransform was a very bad idea :-(. But it is
required to create an Instance of the compound primary key somewhere
and use it to get the GlobalIdentity as CompoundPKTransform is the
transform used. Is it a good idea to write another accessor
specifically for this case? Then the creation of the PK instance can
be moved to the accessor. But this requires the acessor to have access
to the PKClass. Also this accessor will only be used for the special
case that causes this error.
The set method of the accessor will be
public void set(InTxCache cache, CacheRow row, Object value) {
GlobalIdentity id;
Object pkObject;
if (!pkClass.isInstance(value)) {
try {
pkObject = pkClass.newInstance();
Field[] fields = pkClass.getFields();
fields[0].set(pkObject, value);
} catch (IllegalArgumentException e) {
throw new EJBException(Cannot extract global
identity, e);
} catch (IllegalAccessException e) {
throw new EJBException(Cannot extract global
identity, e);
} catch (InstantiationException e) {
throw new EJBException(Cannot extract global
identity, e);
}
}
try {
id = transform.getGlobalIdentity(pkObject);
} catch (IdentityTransformException e) {
throw new EJBException(Cannot extract global identity, e);
}
cmpField.set(cache, row, value);
cmrField.set(cache, row, id);
}
OR
Should the existing accessor be modified to take care of this scenario?
OR
Is there some other way to resolve this issue?
Thanks
Manu
Re: GBean for auto generation of primary key
Hello Rakesh, It is definitively useful. Dain has already created a JIRA for this issue: http://issues.apache.org/jira/browse/GERONIMO-1133. To contribute your custom PrimaryKeyGenerator, you need to attach to this JIRA your implementation and select the Grant license to ASF... radio button. Ideally, we want to support out-of-the-box an UUID pk generator. This means that we want an additional choice element to the key-generatorType type defined by openejb-pkgen-2.0.xsd and push the pk generator implementation to TranQL. If you want to add out-of-the-box support, I am happy to provide more directions. If you are too busy right now, simply attach your current impl. and we will take care of it. Thanks, Gianny Ranjan, Rakesh (Cognizant) wrote: Hi Dims, I didn’t got your reply to my mail. Today I checked this thread. If you think this would be useful for the community, I will upload the related files. But I don’t know how to upload and what should be the format. Can u please guide me? Regards Rakesh Ranjan This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: Fwd: [Fwd: [Vote] 1.0 Release - Do we ship it?]
+1 Release 1.0 Gianny Sachin Patel wrote: forwarding this on behalf of Matt... - sachin Begin forwarded message: *From: *Matt Hogstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Date: *January 3, 2006 9:47:28 AM EST *To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] *Subject: **[Fwd: [Vote] 1.0 Release - Do we ship it?]* Can you forward thsi for me? I'm still getting SPAM errors. I've sent a note to Ken to see if he can help me decipher what's going on. Original Message Subject: [Vote] 1.0 Release - Do we ship it? Date: Tue, 03 Jan 2006 09:21:30 -0500 From: Matt Hogstrom [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: dev@geronimo.apache.org mailto:dev@geronimo.apache.org All, We have had the last candidate out and available since 12/22. I personally have had a chance to put the 12/22 build under performance stress and I'm satisfied that the build is stable and runs in a variety of modes using DayTrader. Despite the Christmas Holidays I have seen some traffic related to htis release on the list so some folks have been kicking it around as well. At this time I'd like to call a vote to release 1.0. [ ] +1 Release 1.0 [ ] -1 Do not release 1.0 (Reasons included) Looks like we got through the last remaining significant bugs and thansk to all who worked up to the end to get this release out there. Matt
Re: Regd OpenEJB
Hi Manu, You are once again correct: let's remove this read-only decorator - this was a very bad idea - at least if the field is a PK one. This read only behavior was intended to prevent developers from changing a relationship to a CMP having a coumpond PK with multiple fields. Indeed, in this case, if the CMP field is updated, this implies that the relationship is (partially, as only one field is updated) updated and I am not sure that it is safe to let such a thing to happen. Thanks for your work on this, Gianny Manu George wrote: Hi Gianny, I have a question on CMR Consider a Bean A and a bean B in a one to many CMR relationship Here A has 2 fields in the PK say a1 and a2 B has b1 fka1 and fka2 as the pk where fka1 and fka2 are the foreign keys corressponding to the a1 and a2 of A. In the ejbCreate of B when we set fka1 and fka2 won't OpenEJB throw an error saying that they are readonly fields. This will happen even after implementing the logic for the special case where the CompoundPK has 1 field. Is this scenario a valid scenario? If so can we change the check in createCMPFieldAccessors to check for primary key and allow write access to CMR fields if they are parts of Primary Keys? What should be the correct behaviour? Thanks Manu
Re: Regd OpenEJB
Hi Manu, Manu George wrote: Hi , I am also not sure if this is a safe behaviour or even whether the ejb spec requires it. I have seen in a particular sun forum that the pk should not be part of any relation. I have put the link below http://archives.java.sun.com/cgi-bin/wa?A2=ind0203L=ejb-interestF=S=P=22402 http://archives.java.sun.com/cgi-bin/wa?A2=ind0203L=ejb-interestF=S=P=22402. If this is true then there is no issue at all with the existing code but I am not sure whether this is true as in some containers like Websphere this is allowed. I went through the parts of the specs mentioned in the posting quickly but it didn't resolve my doubts. We need to support the case where a pk column is also a fk column. For instance, SPECj is using such a mapping and our current implementation is able to run SPECj - we support the scenario where a compound pk field is mapped to a foreign key column referencing the pk column of a CMP having a simple pk class. Another Issue that pops up if we allow to set the foreign key field is in the ejbPostCreate if the bean provider tries to set the cmrField the container will set the fk automatically and thereby try to change the PK which should not be done once an ejb is created. So there also we need to add certain checks. We are implementing such checks - at least for the case that we support. They are implemented by CMRMappedToInversePKCMP and CMRMappedToOwningPKCMP. We have a set of OpenEJB itests, CMRMappingFacadeBean, which amongst other things verify that we cannot change the PK of a CMP by setting a CMR field - the four tests test*ResetPK. All these points together tend to confuse me on what the actual behaviour should be. Any suggestions? The case where we have: * a composite primary key having three columns (b, fka1, fka2); and * (fka1, fka2) also foreign key columns referencing the composite primary key (a1, a2). seems to be rare. However, it seems that we should be able to support it via the same mechanism that we used for CMRMappedToInversePKCMP and CMRMappedToOwningPKCMP. I think that the first thing to do is to add support for your very first scenario. I think that this is more or less that code snippet that you have submitted a couple of days ago. Thanks, Gianny Thanks Manu On 1/7/06, *Gianny Damour* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Manu, You are once again correct: let's remove this read-only decorator - this was a very bad idea - at least if the field is a PK one. This read only behavior was intended to prevent developers from changing a relationship to a CMP having a coumpond PK with multiple fields. Indeed, in this case, if the CMP field is updated, this implies that the relationship is (partially, as only one field is updated) updated and I am not sure that it is safe to let such a thing to happen. Thanks for your work on this, Gianny Manu George wrote: Hi Gianny, I have a question on CMR Consider a Bean A and a bean B in a one to many CMR relationship Here A has 2 fields in the PK say a1 and a2 B has b1 fka1 and fka2 as the pk where fka1 and fka2 are the foreign keys corressponding to the a1 and a2 of A. In the ejbCreate of B when we set fka1 and fka2 won't OpenEJB throw an error saying that they are readonly fields. This will happen even after implementing the logic for the special case where the CompoundPK has 1 field. Is this scenario a valid scenario? If so can we change the check in createCMPFieldAccessors to check for primary key and allow write access to CMR fields if they are parts of Primary Keys? What should be the correct behaviour? Thanks Manu
Re: WADI clustering
Rajith Attapattu wrote: More question if you don't mind. 2.) Assuming sombody wants to do session replication (All Active) instead of (one Active and n backups) is there provision within the WADI api to plug in this stratergy? I'm giving this some thought in terms of SFSB support, I'm not aware of similar constraints in the EJB world... I guess we could relax this constraint in the web world, but I am not sure that I think that this is a good idea. Can you see a way to do this and maintain spec compliance and performance ? Is WADI designed primarily for Web?? (bcos u talked about being servlet spec compliant) and u also mention about SFSB support. Can we abstract the Replication problem to a more higher level and have the two (or more if there is) stratergies as impls of the replication API that installs as a pluggin by the user. We can abstract things like a ReplicationManager that handles/controls no of replicas etc.. and a ReplicatedSession which decides wether it's active or passive (backup) based on the parameters passed to the ReplicatedSessionFactory at create time from the ReplicationManager. This is a very good idea. A ReplicationManager could provide the management of replicas: we feed it a primary object; it delegates to a BackingStrategy the selection of backing storages, i.e. location and type of back-ups; and feeds to the selected ReplicaStorage a copy of the object to be replicated. As previously stated by Jules, the BackingStrategy chooses the backing storages based on deployment characteristics, e.g. a storage hosted by a distinct physical box than the one hosting the primary object is preferred to a storage hosted on the same physical box than the primary. Also, the ReplicationManager could provide some ways to re-organize the backing storages, when a session has been migrated from one node to another. It notifies the other ReplicationManager hosted by each node of the cluster and instructs them that it is becoming the primary host of a replicated object (this object is uniquely identified by a key somehow). The ReplicationManager, which is currently the primary of this replicated object, releases the primary and replies back that the backing storages are hosted there, there and there. The new primary host requests to the BackingStrategy to re-assess the backing storages based on the new situation: I am now the primary host and the current backing storages are there. The ReplicationManager impl could be the stratergy that decides wether it maintains n of active replicas or 1 active and n backups or any other stratergy. Also the ReplicatedSession could impl stratergies like in MemoryReplication or PassiveReplication (based on active or passive) or anything else. And PassiveReplication can be extended to file based, database backed (not recomended) or anything else. In the above scheme, the ReplicaStorage implements these memory, file or database strategies. Does that sound reasonable? Thanks, Gianny If we open up the API and let the user choose the stratergy they want then we are delaying our concerns to the user level and allow them to make the decesion. I am sure we cannot address every situation, and the user is the best to judge about there env. But we can always provide some sensible stratergies and recomendations and use cases around them to make an informed decesion. Then We can leave the decesion to the user about spec-complient/performance. What do u think?? If a request arrives at a secondary, primary and secondary swap roles and processing happens locally. If a request arrives on a node with no copy of the relevant session, it may be relocated to the primary, or the primary to it. 1. Do u plan to have an abstraction around the above concerns as well?? So we can have impls of different stratergies, So people can decide wether they want to relocate the primary or the request. In case of a relocation of either request or session I assume u have hidden the impls behind an interface/API sort of thing so ppl can do different impls of the same stratergies or impl their own stratergy. 2. In the event of a primary and secondary swapping roles or having n of active replicas don't we need some sort of distributed locking mechanism. I heard that in memory locking should be optimistic and storage backed replicas should be pessimistic locking. I hope I haven't got the too mixed up :) Can u please touch on this problem as my knoweldge is limited on this area. Regards, Rajith. On 1/17/06, *Jules Gosnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Rajith Attapattu wrote: Hi, Some of these questions came up after reading the thread on totem. However I started the new thread so that searching is easy and also want distract the intense discussions on totem with out-of-topic questions. Jules Gosnel wrote This is not
Re: [VOTE] Documentation in Confluence, MoinMoin, or..
+1 Confluence Gianny Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anyone with an interest in working with the documentation, either directly or for some sort of postprocessing, please vote here. Unless there are problems, this vote will close in one week, at 14h00 UTC on 27 January 2006. At that point, a two-thirds majority will be a clear indicator of which way to go; any narrower majority will mean opinions are still too divided. Working documentation for Apache Geronimo should be kept in [ ] Confluence [ ] MoinMoin wiki [ ] Other (explain) This does not affect the need for 'solid' or released documentation to be under source control. This vote is only to decide a single collaborative environment for its development. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ9D1bprNPMCpn3XdAQIguAP/W4N8a5bp0F0kqhLnInPkBb1Hgacg7r0D eBHx/NiyQzZ/qjsStvCh/Ud3dDSzVbTCno5mgoaM6lmqEgOJ/EqMVzD/lYmtt/0y Jl2dI4DrPRe7Y5UvWNM76dSaGob3xuGyhYLm2mVJYxDnow9L6MO6btrWOCsb8Ww7 48uwYXnlh1c= =1Dmb -END PGP SIGNATURE-
Re: Compilation errors in module javamail-transport
Hi, In this situation, I think that you should try: maven -U clean install -U means that newer versions of plugins should be checked from the plugin repositories. Thanks, Gianny Vamsavardhana Reddy wrote: Got the following error trying to build geronimo-spec-javamail. Help C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamailc:\maven-2.0.2\bi \mvn clean install [INFO] Scanning for projects... [INFO] --- [INFO] Building Java Mail [INFO]task-segment: [clean, install] [INFO] --- [INFO] [clean:clean] [INFO] --- [ERROR] BUILD ERROR [INFO] --- [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not ex st or no valid version could be found [INFO] --- [INFO] For more information, run Maven with the -e switch [INFO] --- [INFO] Total time: 2 seconds [INFO] Finished at: Wed Feb 08 16:11:36 IST 2006 [INFO] Final Memory: 2M/4M [INFO] --- On 2/7/06, *Bruce Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo ( http://geronimo.apache.org/) Castor (http://castor.org/)
Re: NPE in HOWLLog in boot
Hi Jason, This has now been fixed. XidFactory is now being properly injected and G should start fine. Thanks, Gianny Jason Dillon wrote: I'm not sure how I got G into this state, but its barfing on boot with: snip Booting Geronimo Kernel (in Java 1.4.2_09)... Started configuration 1/16 0s geronimo/rmi-naming/1.0/car 18:57:25,971 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.NullPointerException at org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362) at org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$ac1e62eb.start(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:323) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:82) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404) ... /snip Most GBeans do not start successfully after that... G is hosed at this point, had to nuke the txlogs to get a usage G again. That line is: snip Xid masterXid = xidFactory.recover(formatId, globalId, branchId); /snip xidFactory not getting dependency injected? --jason
