[jira] Updated: (GERONIMO-4582) Add Edit action forJMS Resource Parameters after create it
[ https://issues.apache.org/jira/browse/GERONIMO-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4582: --- Summary: Add Edit action forJMS Resource Parameters after create it (was: Can Edit JMS Resource Parameters after create it) Add Edit action forJMS Resource Parameters after create it -- Key: GERONIMO-4582 URL: https://issues.apache.org/jira/browse/GERONIMO-4582 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.1.4, 2.2 Environment: Any platfrom Reporter: viola.lu Priority: Minor In current G server, if i create a JMS resource, i should set all paramets when create it, after creation, if i want to tune ActivMQ performance via set Queue or topic PoolSize, i should delete this JMS resource, and re-create one with different configuraiton.So improve edit action in JMS resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4583) Remove obsolete plugins from plugins group
Remove obsolete plugins from plugins group -- Key: GERONIMO-4583 URL: https://issues.apache.org/jira/browse/GERONIMO-4583 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.2 Environment: None Reporter: Chi Runhua Priority: Minor Plugin name:Geronimo Framework, Configs :: CLI Upgrade Module ID: org.apache.geronimo.framework/upgrade-cli//car Description:Provides repository registration of a plugin. Comments from David Jencks: This is pretty obsolete. It includes a way to offline upgrade a plan from the 1.0 to 1.1 formats. I don't think we've maintained it since. More details, please look into http://www.nabble.com/Description-of-plugins---td22451177s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 10:55 PM, Jason Dillon wrote: On Mar 12, 2009, at 1:26 AM, David Jencks wrote: I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. Why Scala? My knowledge of scala is limited to reading the scala book and not trying any code, but I got the impression you could do at least as powerful things in the way of builders as with groovy, plus have compile time type checking. As with groovy it's compatible with java code and compiles to java bytecode. thanks david jencks --jason
[jira] Commented: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681247#action_12681247 ] Rick McGuire commented on GERONIMO-4529: Ok, I understand how this fixes the issue now. This will work as a short-term fix, but you might want to open an enhancement request against yoko to allow the ORB property bundle used to instantiate the orb to be set on the service. Corba port 1050 is not released after stopping j2ee-corba-yoko configuration Key: GERONIMO-4529 URL: https://issues.apache.org/jira/browse/GERONIMO-4529 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1.4, 2.2 Environment: Windows XP JDK 1.5 Geronimo 2.2 SNAPSHOT 20090202 Reporter: Ivan Assignee: Gang Yin Fix For: 2.2 Attachments: fix-g4529-jeffyin.patch After stopping the corba component in the console, port 1050 is not released. Use command netstat or connect it with Eclipse Debug. Those two threads are still running. Yoko:Server:StartedThread. It seems it is still blocked on ServerSocket.accept method. And I could not start the Corba service in the admin console due to address already in use. Thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no
[jira] Created: (GERONIMO-4584) Opening an IMAP folder with *logs* of emails is very expensive in terms of memory and cpu
Opening an IMAP folder with *logs* of emails is very expensive in terms of
memory and cpu
-
Key: GERONIMO-4584
URL: https://issues.apache.org/jira/browse/GERONIMO-4584
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: mail
Reporter: Guillaume Nodet
Priority: Minor
{code}
// this is a real pain, but because we need to track updates
// to message sequence numbers while the folder is open, the
// messages list needs to be populated with Message objects
// to keep track of things. The IMAPMessage objects will not
// retrieve information from the server until required, so
they're
// relatively lightweight at this point.
populateMessageCache();
{code}
{code}
/**
* Populate the message cache with dummy messages, ensuring we're filled
* up to the server-reported number of messages.
*
* @exception MessagingException
*/
protected void populateMessageCache() {
// spin through the server-reported number of messages and add a dummy
one to
// the cache. The message number is assigned from the id counter, the
// sequence number is the cache position + 1.
for (int i = messages.size(); i maxSequenceNumber; i++) {
messages.add(new IMAPMessage(this, ((IMAPStore)store),
nextMessageID++, i+1));
}
}
{code}
The above code comes from
http://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/IMAPFolder.java.
When trying to open my gmail account using IMAP, this takes a long time and an
enormous amount of memory (500 Mb) just to open the folder.
It might be a good idea to revisit this code if possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On 12/03/2009, at 5:26 AM, David Jencks wrote: On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. This is the weakness but also the power of the approach whereby users can mix arbitrary code and declarations. Syntax validation is pretty much addressed by IDEs; however, only testing the script will prove that it does what it is supposed to do. I do understand your reticence thought and I will not insist. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. This is an interesting idea. I am keen to see something more streamlined and efficient than yet another XML approach to configure a bunch of services in the kernel! Thanks, Gianny thanks david jencks If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of from the bottom. Another approach to many of these issues is perhaps from the top, from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The init method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies.
[jira] Commented: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681242#action_12681242 ] Rick McGuire commented on GERONIMO-4529: Could you please comment on why the inner class solves the problem? It appears to be the identical operation as before. If there is some subtle problem in the Yoko TransientNameServer implementation that results in this problem, that's really where this should be fixed. Corba port 1050 is not released after stopping j2ee-corba-yoko configuration Key: GERONIMO-4529 URL: https://issues.apache.org/jira/browse/GERONIMO-4529 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 2.1.4, 2.2 Environment: Windows XP JDK 1.5 Geronimo 2.2 SNAPSHOT 20090202 Reporter: Ivan Assignee: Gang Yin Fix For: 2.2 Attachments: fix-g4529-jeffyin.patch After stopping the corba component in the console, port 1050 is not released. Use command netstat or connect it with Eclipse Debug. Those two threads are still running. Yoko:Server:StartedThread. It seems it is still blocked on ServerSocket.accept method. And I could not start the Corba service in the admin console due to address already in use. Thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
Hi Gianny, As a keen observer of the Geronimo dev List , I would like to ask question on this subject. Gianny, do you want to say that there is an UniversalClassLoader for all the server instance that contains the other class loaders. IOW, try to change hierarchical class loaders with the flat class loader repository? Do you mean that if jar is already loaded by the any class loader that is registered in the UniversalClassLoader, it will always load the same jar? Thanks; Gurkan From: Gianny Damour gianny.dam...@optusnet.com.au To: dev@geronimo.apache.org Sent: Thursday, March 12, 2009 12:25:34 PM Subject: Re: Whence the geronimo kernel? On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that
[jira] Commented: (DAYTRADER-63) OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed
[ https://issues.apache.org/jira/browse/DAYTRADER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681306#action_12681306 ] Donald Woods commented on DAYTRADER-63: --- Patch applied to Daytrader 2.1.3 as Rev752851 OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed --- Key: DAYTRADER-63 URL: https://issues.apache.org/jira/browse/DAYTRADER-63 Project: DayTrader Issue Type: Bug Components: EJB Tier Environment: JDK: 1.5 or later Geronimo: 2.2-snapshot DB: DB2 Reporter: Forrest Xia Assignee: Forrest Xia Priority: Minor Attachments: OrderDataBean.Daytrader-63.new.patch, OrderDataBean.Daytrader-63.patch If enable OpenJPA to create foreign key constraints on db2 database, in EJB3 runtime mode, the sell operation will fail by throwing exception like this: 2009-01-09 11:50:10,642 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.3-r420667:677674 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2108) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1955) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy68.sell(Unknown Source) at org.apache.geronimo.samples.daytrader.TradeAction.sell(TradeAction.java:237) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doSell(TradeServletAction.java:690) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:162) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at
[jira] Updated: (DAYTRADER-63) OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed
[ https://issues.apache.org/jira/browse/DAYTRADER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated DAYTRADER-63: -- Affects Version/s: 2.2 2.1.3 Fix Version/s: 2.2 2.1.3 Assignee: Donald Woods (was: Forrest Xia) OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed --- Key: DAYTRADER-63 URL: https://issues.apache.org/jira/browse/DAYTRADER-63 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.1.3, 2.2 Environment: JDK: 1.5 or later Geronimo: 2.2-snapshot DB: DB2 Reporter: Forrest Xia Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 Attachments: OrderDataBean.Daytrader-63.new.patch, OrderDataBean.Daytrader-63.patch If enable OpenJPA to create foreign key constraints on db2 database, in EJB3 runtime mode, the sell operation will fail by throwing exception like this: 2009-01-09 11:50:10,642 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.3-r420667:677674 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2108) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1955) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy68.sell(Unknown Source) at org.apache.geronimo.samples.daytrader.TradeAction.sell(TradeAction.java:237) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doSell(TradeServletAction.java:690) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:162) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
[jira] Updated: (DAYTRADER-64) OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
[
https://issues.apache.org/jira/browse/DAYTRADER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated DAYTRADER-64:
--
Affects Version/s: 2.2
2.1.3
Fix Version/s: 2.2
2.1.3
Assignee: Donald Woods (was: Forrest Xia)
OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
Key: DAYTRADER-64
URL: https://issues.apache.org/jira/browse/DAYTRADER-64
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 2.1.3, 2.2
Environment: JDK 1.6
OpenJPA 1.2.0
Reporter: Forrest Xia
Assignee: Donald Woods
Fix For: 2.1.3, 2.2
Attachments: daytraderejbmodule.pom.patch
Daytrader 2.2-snapshot EJB module build failure cause of missing some
dependency package.
The failure exception like:
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
[java] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
[java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
[java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[java] at java.lang.reflect.Method.invoke(Method.java:599)
[java] at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[java] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[java] at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[java] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[java] Caused by: java.lang.NoClassDefFoundError:
serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java] at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
[java] at java.lang.Class.forNameImpl(Native Method)
[java] at java.lang.Class.forName(Class.java:169)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:119)
[java] ... 26 more
[java] Caused by: java.lang.ClassNotFoundException:
serp.bytecode.Instruction
[java] at
org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1166)
[java] at
org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1107)
[java] at
org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:983)
[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
[java] ... 32 more
[java] --- Nested Exception ---
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java]
[jira] Commented: (GERONIMO-4543) EAR classloader not garbage collected
[ https://issues.apache.org/jira/browse/GERONIMO-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681311#action_12681311 ] Janko Heilgeist commented on GERONIMO-4543: --- Java6 says Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled in the future if it is started with -XX:+CMSPermGenSweepingEnabled so I stopped using this option recently. I'll admit that this report is not a major issue. I just discovered the leaks when I debugged an application. They haven't caused any real problems yet. EAR classloader not garbage collected - Key: GERONIMO-4543 URL: https://issues.apache.org/jira/browse/GERONIMO-4543 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Memory Leaks, transaction manager Affects Versions: 2.2 Reporter: Janko Heilgeist Priority: Blocker Fix For: 2.2 Attachments: ear-with-tx.tar.gz, privileged_currenttime.patch The TransactionTimer$CurrentTime thread inherits the AccessControlContext of the first EAR/WAR/EJB-jar that carries out a transaction. Thus, the particular EAR/WAR/EJB-jar's classloader is prevented from being GCed. See http://www.nabble.com/PermGen-space-issues-td22079768s134.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAYTRADER-64) OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
[
https://issues.apache.org/jira/browse/DAYTRADER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681312#action_12681312
]
Donald Woods commented on DAYTRADER-64:
---
Applied to Daytrader 2.1.3 as Rev752859.
OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
Key: DAYTRADER-64
URL: https://issues.apache.org/jira/browse/DAYTRADER-64
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 2.1.3, 2.2
Environment: JDK 1.6
OpenJPA 1.2.0
Reporter: Forrest Xia
Assignee: Donald Woods
Fix For: 2.1.3, 2.2
Attachments: daytraderejbmodule.pom.patch
Daytrader 2.2-snapshot EJB module build failure cause of missing some
dependency package.
The failure exception like:
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
[java] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
[java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
[java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[java] at java.lang.reflect.Method.invoke(Method.java:599)
[java] at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[java] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[java] at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[java] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[java] Caused by: java.lang.NoClassDefFoundError:
serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java] at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
[java] at java.lang.Class.forNameImpl(Native Method)
[java] at java.lang.Class.forName(Class.java:169)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:119)
[java] ... 26 more
[java] Caused by: java.lang.ClassNotFoundException:
serp.bytecode.Instruction
[java] at
org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1166)
[java] at
org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1107)
[java] at
org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:983)
[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
[java] ... 32 more
[java] --- Nested Exception ---
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java] at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
[jira] Closed: (DAYTRADER-63) OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed
[ https://issues.apache.org/jira/browse/DAYTRADER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-63. - Applied to trunk as Rev752864 OrderDataBean @OneToOne mapping to HoldingDataBean causes sell operation failed --- Key: DAYTRADER-63 URL: https://issues.apache.org/jira/browse/DAYTRADER-63 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.1.3, 2.2 Environment: JDK: 1.5 or later Geronimo: 2.2-snapshot DB: DB2 Reporter: Forrest Xia Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 Attachments: OrderDataBean.Daytrader-63.new.patch, OrderDataBean.Daytrader-63.patch If enable OpenJPA to create foreign key constraints on db2 database, in EJB3 runtime mode, the sell operation will fail by throwing exception like this: 2009-01-09 11:50:10,642 WARN [Transaction] Unexpected exception from beforeCompletion; transaction will roll back openjpa-1.0.3-r420667:677674 fatal general error org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2108) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1955) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.beforePrepare(TransactionImpl.java:400) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:257) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:245) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:138) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:76) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:212) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy68.sell(Unknown Source) at org.apache.geronimo.samples.daytrader.TradeAction.sell(TradeAction.java:237) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doSell(TradeServletAction.java:690) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:162) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at
[jira] Closed: (DAYTRADER-64) OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
[
https://issues.apache.org/jira/browse/DAYTRADER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods closed DAYTRADER-64.
-
Resolution: Fixed
Applied to trunk as Rev752869.
OpenJPA PCEnhancer ant task failure cause Full EJB3 runtime mode failure
Key: DAYTRADER-64
URL: https://issues.apache.org/jira/browse/DAYTRADER-64
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 2.1.3, 2.2
Environment: JDK 1.6
OpenJPA 1.2.0
Reporter: Forrest Xia
Assignee: Donald Woods
Fix For: 2.1.3, 2.2
Attachments: daytraderejbmodule.pom.patch
Daytrader 2.2-snapshot EJB module build failure cause of missing some
dependency package.
The failure exception like:
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:178)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:84)
[java] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
[java] at org.apache.tools.ant.Task.perform(Task.java:364)
[java] at org.apache.tools.ant.Target.execute(Target.java:341)
[java] at
org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:108)
[java] at
org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:83)
[java] at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
[java] at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
[java] at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
[java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
[java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
[java] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[java] at java.lang.reflect.Method.invoke(Method.java:599)
[java] at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[java] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[java] at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[java] at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[java] Caused by: java.lang.NoClassDefFoundError:
serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java] at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
[java] at java.lang.Class.forNameImpl(Native Method)
[java] at java.lang.Class.forName(Class.java:169)
[java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:119)
[java] ... 26 more
[java] Caused by: java.lang.ClassNotFoundException:
serp.bytecode.Instruction
[java] at
org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1166)
[java] at
org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1107)
[java] at
org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:983)
[java] at java.lang.ClassLoader.loadClass(ClassLoader.java:609)
[java] ... 32 more
[java] --- Nested Exception ---
[java] java.lang.NoClassDefFoundError: serp.bytecode.Instruction
[java] at java.lang.J9VMInternals.verifyImpl(Native Method)
[java] at java.lang.J9VMInternals.verify(J9VMInternals.java:72)
[java] at java.lang.J9VMInternals.initialize(J9VMInternals.java:134)
[java] at java.lang.Class.forNameImpl(Native
[jira] Commented: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681326#action_12681326 ] Donald Woods commented on DAYTRADER-65: --- Applied to daytrader 2.1.3 as Rev752865. Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Reporter: Forrest Xia Assignee: Forrest Xia Attachments: Jboss5Enablement.DAYTRADER-65.patch Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated DAYTRADER-65: -- Affects Version/s: 2.2 2.1.3 Fix Version/s: 2.2 2.1.3 Assignee: Donald Woods (was: Forrest Xia) Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: Jboss5Enablement.DAYTRADER-65.patch Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Done. All three patches have been applied to branches/2.1.3 and trunk. -Donald Forrest_Xia wrote: Hi folks, Is there anyone has time to help look at JIRA daytrader-63, 64, 65? Please help review and commit them if it's ok for us. If anything unclear, please comment on them. I will have more commits about daytrader for tomcat, for jboss4. Thanks! Forrest
[jira] Closed: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-65. - Resolution: Fixed Applied to trunk as Rev752871 Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: Jboss5Enablement.DAYTRADER-65.patch Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Thanks Donald!
[jira] Updated: (DAYTRADER-66) Non-transactional datasource deployment descriptor use transactional definition in db2 and oracle deployment plan
[ https://issues.apache.org/jira/browse/DAYTRADER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated DAYTRADER-66: -- Fix Version/s: 2.2 2.1.3 Assignee: Donald Woods (was: Forrest Xia) Non-transactional datasource deployment descriptor use transactional definition in db2 and oracle deployment plan - Key: DAYTRADER-66 URL: https://issues.apache.org/jira/browse/DAYTRADER-66 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Environment: daytrader trunk Reporter: Forrest Xia Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 Attachments: daytrader-66.patch In DB2 and Oracle deployment plan, there are deployment descriptor like this: DB2: connectiondefinition-instance namejdbc/NoTxTradeDataSource/name config-property-setting name=UserNametrade/config-property-setting config-property-setting name=Passwordtrade/config-property-setting config-property-setting name=PortNumber50001/config-property-setting config-property-setting name=ServerNamelocalhost/config-property-setting config-property-setting name=DatabaseNametradedb/config-property-setting config-property-setting name=DriverType4/config-property-setting connectionmanager xa-transaction transaction-caching/ /xa-transaction single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds5000/blocking-timeout-milliseconds idle-timeout-minutes30/idle-timeout-minutes match-one/ /single-pool /connectionmanager /connectiondefinition-instance Oracle: connectiondefinition-instance namejdbc/NoTxTradeDataSource/name config-property-setting name=UserNametrade/config-property-setting config-property-setting name=Passwordtrade/config-property-setting config-property-setting name=DatabaseNametradedb/config-property-setting config-property-setting name=DataSourceNameTradeDataSource/config-property-setting config-property-setting name=ServerNamelocalhost/config-property-setting config-property-setting name=PortNumber1160/config-property-setting config-property-setting name=DriverTypethin/config-property-setting connectionmanager xa-transaction transaction-caching/ /xa-transaction single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds5000/blocking-timeout-milliseconds idle-timeout-minutes30/idle-timeout-minutes match-one/ /single-pool /connectionmanager /connectiondefinition-instance Obviously, the snippet xa-transactiontransaction-caching//xa-transaction is not correct for a non-transactional datasource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Also applied your patch for DAYTRADER-66. -Donald Donald Woods wrote: Done. All three patches have been applied to branches/2.1.3 and trunk. -Donald Forrest_Xia wrote: Hi folks, Is there anyone has time to help look at JIRA daytrader-63, 64, 65? Please help review and commit them if it's ok for us. If anything unclear, please comment on them. I will have more commits about daytrader for tomcat, for jboss4. Thanks! Forrest
[jira] Closed: (DAYTRADER-66) Non-transactional datasource deployment descriptor use transactional definition in db2 and oracle deployment plan
[ https://issues.apache.org/jira/browse/DAYTRADER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed DAYTRADER-66. - Resolution: Fixed Applied to 2.1.3 as Rev752875. Applied to trunk as Rev752876. Non-transactional datasource deployment descriptor use transactional definition in db2 and oracle deployment plan - Key: DAYTRADER-66 URL: https://issues.apache.org/jira/browse/DAYTRADER-66 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Environment: daytrader trunk Reporter: Forrest Xia Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 Attachments: daytrader-66.patch In DB2 and Oracle deployment plan, there are deployment descriptor like this: DB2: connectiondefinition-instance namejdbc/NoTxTradeDataSource/name config-property-setting name=UserNametrade/config-property-setting config-property-setting name=Passwordtrade/config-property-setting config-property-setting name=PortNumber50001/config-property-setting config-property-setting name=ServerNamelocalhost/config-property-setting config-property-setting name=DatabaseNametradedb/config-property-setting config-property-setting name=DriverType4/config-property-setting connectionmanager xa-transaction transaction-caching/ /xa-transaction single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds5000/blocking-timeout-milliseconds idle-timeout-minutes30/idle-timeout-minutes match-one/ /single-pool /connectionmanager /connectiondefinition-instance Oracle: connectiondefinition-instance namejdbc/NoTxTradeDataSource/name config-property-setting name=UserNametrade/config-property-setting config-property-setting name=Passwordtrade/config-property-setting config-property-setting name=DatabaseNametradedb/config-property-setting config-property-setting name=DataSourceNameTradeDataSource/config-property-setting config-property-setting name=ServerNamelocalhost/config-property-setting config-property-setting name=PortNumber1160/config-property-setting config-property-setting name=DriverTypethin/config-property-setting connectionmanager xa-transaction transaction-caching/ /xa-transaction single-pool max-size10/max-size min-size0/min-size blocking-timeout-milliseconds5000/blocking-timeout-milliseconds idle-timeout-minutes30/idle-timeout-minutes match-one/ /single-pool /connectionmanager /connectiondefinition-instance Obviously, the snippet xa-transactiontransaction-caching//xa-transaction is not correct for a non-transactional datasource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681337#action_12681337 ] Donald Woods commented on GERONIMODEVTOOLS-560: --- Applied patch to 2.1.4 as Rev752878. Can't Add or Remove AppClient Project via GEP - Key: GERONIMODEVTOOLS-560 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3, 2.2.0 Environment: OS:windows 2003 JDK:1.5 Reporter: viola.lu Assignee: Donald Woods Fix For: 2.2.0, 2.1.4 Attachments: 560_214branch.patch, 560_214branch_new.patch, 560_trunk.patch, 560_trunk_new.patch 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo server runtime 2.Create a JEE application client attached, and then right-click G server runtime-add and remove project, but it indicates no project to add 3.If i imported other war or ear, ejb jar, then add and remove project, then all are listed to add and remove, if i choose app client, it will reminde me that: The server does not support version 1.4 or 5 of the J2EE Application Client module specification. So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-560: -- Patch Info: [Patch Available] Fix Version/s: 2.1.4 2.2.0 Assignee: Donald Woods (was: Delos Dai) Can't Add or Remove AppClient Project via GEP - Key: GERONIMODEVTOOLS-560 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3, 2.2.0 Environment: OS:windows 2003 JDK:1.5 Reporter: viola.lu Assignee: Donald Woods Fix For: 2.2.0, 2.1.4 Attachments: 560_214branch.patch, 560_214branch_new.patch, 560_trunk.patch, 560_trunk_new.patch 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo server runtime 2.Create a JEE application client attached, and then right-click G server runtime-add and remove project, but it indicates no project to add 3.If i imported other war or ear, ejb jar, then add and remove project, then all are listed to add and remove, if i choose app client, it will reminde me that: The server does not support version 1.4 or 5 of the J2EE Application Client module specification. So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-67) Add a new deployment plan for Informix database
[ https://issues.apache.org/jira/browse/DAYTRADER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated DAYTRADER-67: -- Fix Version/s: (was: 2.0) 2.2 2.1.3 Add a new deployment plan for Informix database --- Key: DAYTRADER-67 URL: https://issues.apache.org/jira/browse/DAYTRADER-67 Project: DayTrader Issue Type: New Feature Components: buildsystem Affects Versions: 2.0 Environment: Daytrader trunk Reporter: Forrest Xia Assignee: Forrest Xia Priority: Minor Fix For: 2.1.3, 2.2 Add a new deployment plan for informix database -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-553) add list of plugins to the Geronimo Server Plugin Page
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-553: -- Fix Version/s: (was: 2.1.4) (was: 2.2.0) add list of plugins to the Geronimo Server Plugin Page -- Key: GERONIMODEVTOOLS-553 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-553 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Reporter: B.J. Reed Assignee: B.J. Reed Priority: Minor On the Geronimo Server Plugin Page (double click on the Geronimo Server), it would be nice to have the list of plugins that are installed on the server. This list would need to be updated if plugins are added/removed. Would probably also be nice to have an Edit button (but no Add or Delete) so that the plugin info could be updated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-529) Investigate removing older versions of the GEP plugins/features from our Eclipse update site on Apache
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-529: -- Affects Version/s: (was: 2.1.4) (was: 2.2.0) Fix Version/s: (was: 2.1.4) (was: 2.2.0) Investigate removing older versions of the GEP plugins/features from our Eclipse update site on Apache -- Key: GERONIMODEVTOOLS-529 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-529 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-527) Upgrade GEP to support Eclipse 3.4 SR1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-527: -- Fix Version/s: (was: 2.1.4) Upgrade GEP to support Eclipse 3.4 SR1 -- Key: GERONIMODEVTOOLS-527 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMODEVTOOLS-560. --- Resolution: Fixed Applied patch to trunk as Rev752879. Can't Add or Remove AppClient Project via GEP - Key: GERONIMODEVTOOLS-560 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3, 2.2.0 Environment: OS:windows 2003 JDK:1.5 Reporter: viola.lu Assignee: Donald Woods Fix For: 2.2.0, 2.1.4 Attachments: 560_214branch.patch, 560_214branch_new.patch, 560_trunk.patch, 560_trunk_new.patch 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo server runtime 2.Create a JEE application client attached, and then right-click G server runtime-add and remove project, but it indicates no project to add 3.If i imported other war or ear, ejb jar, then add and remove project, then all are listed to add and remove, if i choose app client, it will reminde me that: The server does not support version 1.4 or 5 of the J2EE Application Client module specification. So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMODEVTOOLS-560: - Assignee: Delos Dai (was: Donald Woods) Delos, please verify the fixes and then close the JIRA. Thanks. Can't Add or Remove AppClient Project via GEP - Key: GERONIMODEVTOOLS-560 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3, 2.2.0 Environment: OS:windows 2003 JDK:1.5 Reporter: viola.lu Assignee: Delos Dai Fix For: 2.2.0, 2.1.4 Attachments: 560_214branch.patch, 560_214branch_new.patch, 560_trunk.patch, 560_trunk_new.patch 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo server runtime 2.Create a JEE application client attached, and then right-click G server runtime-add and remove project, but it indicates no project to add 3.If i imported other war or ear, ejb jar, then add and remove project, then all are listed to add and remove, if i choose app client, it will reminde me that: The server does not support version 1.4 or 5 of the J2EE Application Client module specification. So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMODEVTOOLS-535: - Assignee: Donald Woods (was: Tim McConnell) Add support for installing from update site for IBM RAD v7.5 Key: GERONIMODEVTOOLS-535 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: IBM RAD v7.5 Reporter: Delos Dai Assignee: Donald Woods Fix For: 2.2.0, 2.1.4 Attachments: GERONIMODEVTOOLS-535.patch Now, in feature.xml of GEP, we have this snippet: requires import feature=org.eclipse.jst version=2.0.0 match=greaterOrEqual/ /requires Since no org.eclipse.jst feature exist in RAD , we have to replace org.eclipse.jst feature with the sub-features of org.eclipse.jst. The section above can be replaced with this snippet: requires import feature=org.eclipse.jst.common_core.feature version=2.0.0.v200706041905-1007w311817231426 match=greaterOrEqual/ import feature=org.eclipse.jst.server_ui.feature version=2.0.2.v200802150100-77-CT9yJXEkuiKVeQrclqTHQ3648 match=greaterOrEqual/ import feature=org.eclipse.jst.server_adapters.feature version=2.0.2.v200802150100-787KE8iDUUEF6GwKwpHEQ match=greaterOrEqual/ import feature=org.eclipse.jst.web_ui.feature version=2.0.2.v200802150100-7B1DzCkuNa_RPevwkwB1iJ6z-0RH match=greaterOrEqual/ import feature=org.eclipse.jst.enterprise_ui.feature version=2.0.2.v200802150100-7b7_Es8EU6AXOV9QLJSees1SQoYQ match=greaterOrEqual/ /requires The sole plugin of org.eclipse.jst feature and optional sub-feature org.eclipse.jst.webpageeditor.feature can't be found in the plugin list of RAD. GEP doesn't require these two items, then don't need to add them into the required section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681348#action_12681348 ] Donald Woods commented on GERONIMODEVTOOLS-535: --- Applied patch to 2.1.4 as Rev752887. Verified that the 2.1.4 plugin could still be installed in Ganymede (3.4.1), could create a 2.1.4 server instance and then start/stop the instance. If RAD 7.5.1 does not work, then please open a new JIRA. Add support for installing from update site for IBM RAD v7.5 Key: GERONIMODEVTOOLS-535 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: IBM RAD v7.5 Reporter: Delos Dai Assignee: Tim McConnell Fix For: 2.2.0, 2.1.4 Attachments: GERONIMODEVTOOLS-535.patch Now, in feature.xml of GEP, we have this snippet: requires import feature=org.eclipse.jst version=2.0.0 match=greaterOrEqual/ /requires Since no org.eclipse.jst feature exist in RAD , we have to replace org.eclipse.jst feature with the sub-features of org.eclipse.jst. The section above can be replaced with this snippet: requires import feature=org.eclipse.jst.common_core.feature version=2.0.0.v200706041905-1007w311817231426 match=greaterOrEqual/ import feature=org.eclipse.jst.server_ui.feature version=2.0.2.v200802150100-77-CT9yJXEkuiKVeQrclqTHQ3648 match=greaterOrEqual/ import feature=org.eclipse.jst.server_adapters.feature version=2.0.2.v200802150100-787KE8iDUUEF6GwKwpHEQ match=greaterOrEqual/ import feature=org.eclipse.jst.web_ui.feature version=2.0.2.v200802150100-7B1DzCkuNa_RPevwkwB1iJ6z-0RH match=greaterOrEqual/ import feature=org.eclipse.jst.enterprise_ui.feature version=2.0.2.v200802150100-7b7_Es8EU6AXOV9QLJSees1SQoYQ match=greaterOrEqual/ /requires The sole plugin of org.eclipse.jst feature and optional sub-feature org.eclipse.jst.webpageeditor.feature can't be found in the plugin list of RAD. GEP doesn't require these two items, then don't need to add them into the required section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-535) Add support for installing from update site for IBM RAD v7.5
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMODEVTOOLS-535. --- Resolution: Fixed Assignee: Delos Dai (was: Donald Woods) Applied patch to trunk as Rev752888. Delos, please verify the fixes and then close the JIRA. Add support for installing from update site for IBM RAD v7.5 Key: GERONIMODEVTOOLS-535 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-535 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3 Environment: IBM RAD v7.5 Reporter: Delos Dai Assignee: Delos Dai Fix For: 2.2.0, 2.1.4 Attachments: GERONIMODEVTOOLS-535.patch Now, in feature.xml of GEP, we have this snippet: requires import feature=org.eclipse.jst version=2.0.0 match=greaterOrEqual/ /requires Since no org.eclipse.jst feature exist in RAD , we have to replace org.eclipse.jst feature with the sub-features of org.eclipse.jst. The section above can be replaced with this snippet: requires import feature=org.eclipse.jst.common_core.feature version=2.0.0.v200706041905-1007w311817231426 match=greaterOrEqual/ import feature=org.eclipse.jst.server_ui.feature version=2.0.2.v200802150100-77-CT9yJXEkuiKVeQrclqTHQ3648 match=greaterOrEqual/ import feature=org.eclipse.jst.server_adapters.feature version=2.0.2.v200802150100-787KE8iDUUEF6GwKwpHEQ match=greaterOrEqual/ import feature=org.eclipse.jst.web_ui.feature version=2.0.2.v200802150100-7B1DzCkuNa_RPevwkwB1iJ6z-0RH match=greaterOrEqual/ import feature=org.eclipse.jst.enterprise_ui.feature version=2.0.2.v200802150100-7b7_Es8EU6AXOV9QLJSees1SQoYQ match=greaterOrEqual/ /requires The sole plugin of org.eclipse.jst feature and optional sub-feature org.eclipse.jst.webpageeditor.feature can't be found in the plugin list of RAD. GEP doesn't require these two items, then don't need to add them into the required section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-555: -- Patch Info: [Patch Available] Fix Version/s: 2.1.4 2.2.0 Assignee: Donald Woods (was: Delos Dai) Generated geronimo-plugin.xml file is empy after converting application to plugin -- Key: GERONIMODEVTOOLS-555 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Environment: SunJDk 1.6 Reporter: viola.lu Assignee: Donald Woods Fix For: 2.2.0, 2.1.4 Attachments: 555.patch 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it. 2.Open defined server, and launch convert apps to plugins 3.Choose deployed app cviewer and conver it to plugin, successfully saved ,but check geronimo-plugin.xml, it's empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Xia updated DAYTRADER-65: - Attachment: oldjbossconfigfiles.zip daytrader-jboss-missingfiles.patch Donald, some files for jboss5 configuration are missing, please check this patch and apply it. A modules/ejb/src/main/resources/META-INF/jboss.xml M modules/ear/src/main/resources/META-INF/persistence.xml.jboss5 A modules/web/src/main/webapp/WEB-INF/jboss-web.xml To keep backward compatibility, I would keep the old jboss configuration files, they are: A + modules/ejb/src/main/resources/META-INF/jboss.xml.old A + modules/ejb/src/main/resources/META-INF/jbosscmp-jdbc.xml.old A + modules/web/src/main/webapp/WEB-INF/jboss-web.xml.old These are packaged in oldjbossconfigfiles.zip, please add them as well. These files are for both 2.1.3 and trunk. thanks! Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: daytrader-jboss-missingfiles.patch, Jboss5Enablement.DAYTRADER-65.patch, oldjbossconfigfiles.zip Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Noticed that. After sync my work copy with server, I found some jboss configuration files are missing, so I add those missing files via daytrader-65 jira, please help check and commit them. thanks again! Next, I plan to provide some additional patches for these aspects: 1. extend the support databases: informix, mysql, sqlserver 2. add a version for tomcat 6 3. add a patch to indicate how to make daytrader work with JBoss 4.2.3 Those things are what I did recently, want to contribute back to community :-) Please kindly let me know if they are desired. Forrest
[jira] Commented: (GERONIMODEVTOOLS-527) Upgrade GEP to support Eclipse 3.4 SR1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681357#action_12681357 ] Jürgen Weber commented on GERONIMODEVTOOLS-527: --- Please notice that Eclipse is at 3.4 SR2 now (http://www.eclipse.org/downloads/) Upgrade GEP to support Eclipse 3.4 SR1 -- Key: GERONIMODEVTOOLS-527 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-555) Generated geronimo-plugin.xml file is empy after converting application to plugin
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved GERONIMODEVTOOLS-555. --- Resolution: Fixed Assignee: Delos Dai (was: Donald Woods) Applied to 2.1.4 as Rev752896. Applied to trunk as Rev752898. Verified that the 2.1.4 plugin can still start/stop sever in Ganymede (3..4.1) with default Sun 1.5 JVM on MacOSX. Delos, please verify the fix on other JVMs and then close the JIRA. Generated geronimo-plugin.xml file is empy after converting application to plugin -- Key: GERONIMODEVTOOLS-555 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-555 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Environment: SunJDk 1.6 Reporter: viola.lu Assignee: Delos Dai Fix For: 2.2.0, 2.1.4 Attachments: 555.patch 1.Install GEP 2.2 snapshot on eclispe, start G2.2snapshot in it. 2.Open defined server, and launch convert apps to plugins 3.Choose deployed app cviewer and conver it to plugin, successfully saved ,but check geronimo-plugin.xml, it's empty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Can you be more specific? You patch included the deletion of 3 files. Was that a mistake in the patch creation? -Donald Forrest Xia wrote: Noticed that. After sync my work copy with server, I found some jboss configuration files are missing, so I add those missing files via daytrader-65 jira, please help check and commit them. thanks again! Next, I plan to provide some additional patches for these aspects: 1. extend the support databases: informix, mysql, sqlserver 2. add a version for tomcat 6 3. add a patch to indicate how to make daytrader work with JBoss 4.2.3 Those things are what I did recently, want to contribute back to community :-) Please kindly let me know if they are desired. Forrest
Re: About daytrader patches
Any additional improvements (whether listed below or otherwise) would be greatly appreciated. Keep the patches coming! -Donald Forrest Xia wrote: Noticed that. After sync my work copy with server, I found some jboss configuration files are missing, so I add those missing files via daytrader-65 jira, please help check and commit them. thanks again! Next, I plan to provide some additional patches for these aspects: 1. extend the support databases: informix, mysql, sqlserver 2. add a version for tomcat 6 3. add a patch to indicate how to make daytrader work with JBoss 4.2.3 Those things are what I did recently, want to contribute back to community :-) Please kindly let me know if they are desired. Forrest
[jira] Commented: (GERONIMODEVTOOLS-527) Upgrade GEP to support Eclipse 3.4 SR1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681360#action_12681360 ] Forrest Xia commented on GERONIMODEVTOOLS-527: -- I tried released GEP 2.1.3 with Ganymede SR2 JEE edition, it just works fine. Upgrade GEP to support Eclipse 3.4 SR1 -- Key: GERONIMODEVTOOLS-527 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-527) Additional GEP tests to verify support for Eclipse 3.4 SR1 and SR2
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-527: -- Description: Include additional tests for reported SR1 user problems. (was: Yep, this issue was more from an automated test perspective, if you look back at Tim's comments. I'll update the title.) Yep, this issue was more from an automated test perspective, if you look back at Tim's comments. I'll update the title. Additional GEP tests to verify support for Eclipse 3.4 SR1 and SR2 -- Key: GERONIMODEVTOOLS-527 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell Include additional tests for reported SR1 user problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-527) Additional GEP tests to verify support for Eclipse 3.4 SR1 and SR2
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMODEVTOOLS-527: -- Description: Yep, this issue was more from an automated test perspective, if you look back at Tim's comments. I'll update the title. Summary: Additional GEP tests to verify support for Eclipse 3.4 SR1 and SR2 (was: Upgrade GEP to support Eclipse 3.4 SR1) Additional GEP tests to verify support for Eclipse 3.4 SR1 and SR2 -- Key: GERONIMODEVTOOLS-527 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-527 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Reporter: Tim McConnell Assignee: Tim McConnell Yep, this issue was more from an automated test perspective, if you look back at Tim's comments. I'll update the title. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: About daytrader patches
Having some files missing in the initial patch is my mistake, sorry for that. I will do be careful for patch inspection before submission. Thank you for your patience. Forrest
[jira] Reopened: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened DAYTRADER-65: --- updates from Forrest Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: daytrader-jboss-missingfiles.patch, Jboss5Enablement.DAYTRADER-65.patch, oldjbossconfigfiles.zip Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods resolved DAYTRADER-65. --- Resolution: Fixed Applied updates to 2.1.3 as Rev752907. Applied updates to trunk as Rev752908. Forrest, please verify all files have been added. Also, please update your .subversion/config file to include the additional ASF recommended values, so your patches will not include Windows EOL chars. Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: 65.patch, daytrader-jboss-missingfiles.patch, Jboss5Enablement.DAYTRADER-65.patch, oldjbossconfigfiles.zip Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-65) Enable daytrader works with JBoss 5
[ https://issues.apache.org/jira/browse/DAYTRADER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated DAYTRADER-65: -- Attachment: 65.patch Patch combining updated patch to add missing files and copies of old files form the zipfile as a single patch. Also removes Windows EOL chars. Enable daytrader works with JBoss 5 --- Key: DAYTRADER-65 URL: https://issues.apache.org/jira/browse/DAYTRADER-65 Project: DayTrader Issue Type: Improvement Components: buildsystem Affects Versions: 2.1.3, 2.2 Reporter: Forrest Xia Assignee: Donald Woods Fix For: 2.1.3, 2.2 Attachments: 65.patch, daytrader-jboss-missingfiles.patch, Jboss5Enablement.DAYTRADER-65.patch, oldjbossconfigfiles.zip Current README.jboss is far out of date. Need a new document about how to enable daytrader work with JBoss 5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: mail Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 3:25 AM, Gianny Damour wrote: On 12/03/2009, at 4:29 AM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per-jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Hi, Thinking more about this, I believe we can expedite the implementation of a classloader-per-jar model. Under the hood of a MultiParentClassLoader we can replace the current implementation of find class and resources contracts by an implementation which delegates to a bunch of URLClassLoaders (one per jar). These bunch of URLClassLoaders are global classloaders, i.e. shared across all the configs/MultiParentClassLoaders. The core challenge is to create them in a hierarchy respecting the maven dependency declarations. So, we could install the pom of the dependencies in the repo and lazily parse them when MultiParentClassLoader are created to build this global and share tree of URLClassLoaders. IMO the danger here is that the maven pom may not exist or may be wrong. OSGI has the same problem in that the vast majority of released jars don't have osgi manifests. I think I saw a rumor that spring spent a lot of effort osgi-ifying a lot of commonly used jars to try to solve this problem. I also don't know if there are situations in which a small number of closely related jars need to be loaded in a single classloader, perhaps because one of the jars is optional but if present the main jar needs access to its classes. I think there was an osgi feature that looked sort of like this. I just started to work on it and I will post back my findings (i should be able to complete this over the week-end). Even if we switch to an OSGi kernel, part of this work may hopefully still be useful. Unless you are pretty sure we won't have the kind of problems with bad community metadata suggested above it might be a good idea to do this in a sandbox branch? thanks david jencks Thanks, Gianny One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour gianny.dam...@optusnet.com.au wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a
[jira] Created: (GERONIMO-4586) Error when deploy war to multiple targets in a wadi cluster
Error when deploy war to multiple targets in a wadi cluster --- Key: GERONIMO-4586 URL: https://issues.apache.org/jira/browse/GERONIMO-4586 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.3, 2.1.4, 2.2 Environment: os:Xp SUn jdk 1.5 Reporter: viola.lu 1.Create one instances name instance2 in the same pc, and it has its own repository under $g_dir/instance2/repository and run command: set REPO2=org.example.configs/myrepo/2.1.3/car?ServiceModule=org.example.configs/myrepo/2.1.3/car,j2eeType=ConfigurationStore,name=Local2 set repo1=org.apache.geronimo.framework/j2ee-system/2.1.3/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/2.1.3/car,j2eeType=ConfigurationStore,name=Local deploy.bat --port 1100 --user system --password manager deploy --targets %repo1%;%repo2% [servlet-examples-cluster-server1-war] [wadi_plan] But errors in instance2 admin console http://localhost:8081/console/portal/Applications/Web App WARs page and can't start deployed module.Access http://localhost:8081/console/portal/Applications/Web App WARs, deployed module servlet-examples-cluster-server1 can start and run Error rendering portlet. java.lang.IllegalStateException: Bad config ID: No matches for referencePatterns: [?#org.apache.geronimo.management.geronimo.WebModule] at org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:526) at org.apache.geronimo.console.util.PortletManager.getModule(PortletManager.java:368) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:230) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at
[jira] Updated: (GERONIMO-4586) Error when deploy war to multiple targets in a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4586: --- Attachment: repo2.xml servlet-examples-cluster-plan-wadi.xml servlet-examples-cluster-server1.war Error when deploy war to multiple targets in a wadi cluster --- Key: GERONIMO-4586 URL: https://issues.apache.org/jira/browse/GERONIMO-4586 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.3, 2.1.4, 2.2 Environment: os:Xp SUn jdk 1.5 Reporter: viola.lu Attachments: repo2.xml, servlet-examples-cluster-plan-wadi.xml, servlet-examples-cluster-server1.war 1.Create one instances name instance2 in the same pc, and it has its own repository under $g_dir/instance2/repository and run command: set REPO2=org.example.configs/myrepo/2.1.3/car?ServiceModule=org.example.configs/myrepo/2.1.3/car,j2eeType=ConfigurationStore,name=Local2 set repo1=org.apache.geronimo.framework/j2ee-system/2.1.3/car?ServiceModule=org.apache.geronimo.framework/j2ee-system/2.1.3/car,j2eeType=ConfigurationStore,name=Local deploy.bat --port 1100 --user system --password manager deploy --targets %repo1%;%repo2% [servlet-examples-cluster-server1-war] [wadi_plan] But errors in instance2 admin console http://localhost:8081/console/portal/Applications/Web App WARs page and can't start deployed module.Access http://localhost:8081/console/portal/Applications/Web App WARs, deployed module servlet-examples-cluster-server1 can start and run Error rendering portlet. java.lang.IllegalStateException: Bad config ID: No matches for referencePatterns: [?#org.apache.geronimo.management.geronimo.WebModule] at org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:526) at org.apache.geronimo.console.util.PortletManager.getModule(PortletManager.java:368) at org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:230) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:208) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:139) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.pluto.core.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:167) at org.apache.pluto.core.DefaultPortletInvokerService.render(DefaultPortletInvokerService.java:101) at org.apache.pluto.core.PortletContainerImpl.doRender(PortletContainerImpl.java:173) at org.apache.pluto.driver.tags.PortletTag.doStartTag(PortletTag.java:152) at jsp.WEB_002dINF.themes.portlet_002dskin_jsp._jspService(portlet_002dskin_jsp.java:87) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:535) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:472) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:968) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspx_meth_c_005fforEach_005f0(default_002dtheme_jsp.java:196) at jsp.WEB_002dINF.themes.default_002dtheme_jsp._jspService(default_002dtheme_jsp.java:101) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at
[jira] Assigned: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned GERONIMO-4585: - Assignee: Guillaume Nodet Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated GERONIMO-4585: -- Attachment: GERONIMO-4585.patch This patch seems to fix the problem and passes the tests. I'd like a second look however before committing the patch. Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: GERONIMO-4585.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681411#action_12681411 ] Rick McGuire commented on GERONIMO-4585: This fix looks pretty good to me. Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: GERONIMO-4585.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4573) OpenEJB tries to parse sun-ejb-jar.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Jonson resolved GERONIMO-4573. -- Resolution: Fixed Fix Version/s: 2.1.4 I can confirm that the solution in OPENEJB-1006 has resolved this issue too. When I replace the openejb-core snapshot jar with the latest release candidate in the repository of a geronimo 2.1.4-SNAPSHOT, and use the following environment setting: JAVA_OPTS=-Dopenejb.vendor.config=GERONIMO I no longer see the deployment failure caused by the existence of a sun-ejb-jar.xml in my ejb module. OpenEJB tries to parse sun-ejb-jar.xml -- Key: GERONIMO-4573 URL: https://issues.apache.org/jira/browse/GERONIMO-4573 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.3 Environment: Deiban 5.0, sun jdk1.6u12, geronimo-jetty6 2.1.3. Reporter: Fredrik Jonson Fix For: 2.1.4 I'm trying to create an application with a inbound rar connector implementation, and have the ear deploy properly on both Geronimo and Glassfish 2.1. To solve that I declare my resource adapter reference both in a openejb-jar.xml for the geronimo specific configuration and a sun-ejb-jar.xml for the glassfish specific configuration. This solution works on glassfish, it ignores openejb-jar.xml as intended. In geronimo, openejb seems to pick up and try to parse the sun-ejb-jar.xml even though the ejb module also contains both a ejb-jar.xml and openejb-jar.xml. Since sun-ejb-jar.xml is application server specific for Sun/Glassfish I expect Geronimo to stay away from it entirely. This issue has been raised before, but I could not find anything relevant in jira. Check the following mail note: http://marc.info/?l=geronimo-devm=118857105323864 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4573) OpenEJB tries to parse sun-ejb-jar.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredrik Jonson closed GERONIMO-4573. OpenEJB tries to parse sun-ejb-jar.xml -- Key: GERONIMO-4573 URL: https://issues.apache.org/jira/browse/GERONIMO-4573 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.1.3 Environment: Deiban 5.0, sun jdk1.6u12, geronimo-jetty6 2.1.3. Reporter: Fredrik Jonson Fix For: 2.1.4 I'm trying to create an application with a inbound rar connector implementation, and have the ear deploy properly on both Geronimo and Glassfish 2.1. To solve that I declare my resource adapter reference both in a openejb-jar.xml for the geronimo specific configuration and a sun-ejb-jar.xml for the glassfish specific configuration. This solution works on glassfish, it ignores openejb-jar.xml as intended. In geronimo, openejb seems to pick up and try to parse the sun-ejb-jar.xml even though the ejb module also contains both a ejb-jar.xml and openejb-jar.xml. Since sun-ejb-jar.xml is application server specific for Sun/Glassfish I expect Geronimo to stay away from it entirely. This issue has been raised before, but I could not find anything relevant in jira. Check the following mail note: http://marc.info/?l=geronimo-devm=118857105323864 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4585) Disposition is incorrectly parsed on multiparts imap messages
[ https://issues.apache.org/jira/browse/GERONIMO-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed GERONIMO-4585. - Resolution: Fixed Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPBodyStructure.java Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPResponseTokenizer.java Sending geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/main/java/org/apache/geronimo/javamail/store/imap/connection/IMAPStatusResponse.java Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/java/org/apache/geronimo/javamail/store/imap/connection Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/java/org/apache/geronimo/javamail/store/imap/connection/IMAPBodyStructureTest.java Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/resources/imap Adding geronimo-javamail_1.4/geronimo-javamail_1.4_provider/src/test/resources/imap/multipart.bodystructure Transmitting file data . Committed revision 753004. Not sure which version of geronimo this fix will be included in, so feel free to change the fix version as required. Disposition is incorrectly parsed on multiparts imap messages - Key: GERONIMO-4585 URL: https://issues.apache.org/jira/browse/GERONIMO-4585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Reporter: Guillaume Nodet Assignee: Guillaume Nodet Attachments: GERONIMO-4585.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 753070
Geronimo Revision: 753070 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090312/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090312
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 35 minutes 54 seconds
[INFO] Finished at: Thu Mar 12 21:39:46 EDT 2009
[INFO] Final Memory: 672M/982M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090312/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:41.401
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:00:59.532)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.174)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.689)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:15.852)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:24.367)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.674)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:43.441)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:49.473)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:48.012)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:42.574)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:31.166)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:31.126)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:33.049)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:48.252)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.536)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:01:00.021)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.263)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.320)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.519) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.704)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Commented: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12681588#action_12681588 ] viola.lu commented on GERONIMODEVTOOLS-560: --- Hi, Eclipse binary build on this URL has not been updated (2009-1-22): http://people.apache.org/dist/geronimo/eclipse/unstable/2.1.4/ Can't Add or Remove AppClient Project via GEP - Key: GERONIMODEVTOOLS-560 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.3, 2.2.0 Environment: OS:windows 2003 JDK:1.5 Reporter: viola.lu Assignee: Delos Dai Fix For: 2.2.0, 2.1.4 Attachments: 560_214branch.patch, 560_214branch_new.patch, 560_trunk.patch, 560_trunk_new.patch 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo server runtime 2.Create a JEE application client attached, and then right-click G server runtime-add and remove project, but it indicates no project to add 3.If i imported other war or ear, ejb jar, then add and remove project, then all are listed to add and remove, if i choose app client, it will reminde me that: The server does not support version 1.4 or 5 of the J2EE Application Client module specification. So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
See comments below. Lin On Thu, Mar 12, 2009 at 1:51 AM, Jarek Gawor jga...@gmail.com wrote: The point I was trying to make is that with Geronimo the classloader hierarchy is pretty much created/setup at build time while in osgi if you are using Import-Package is at runtime. Here's an example. Say, we have configuration A that has dependency on configuration B and C. Both B and C have dependency on commons-logging.jar. In Geronimo it would be very likely that you would run into ClassCastExceptions with such configuration. And the only way to fix it, it would be to create a new configuration D that would have the dependency on commons-logging.jar and B and C configurations would have to be updated to have dependency on D. In osgi world, bundle B and C would define a Import-Package on the commons-logging package and the osgi system at runtime would figure out that B and C must be wired to the same bundle that provides the commons-logging library. So classloader-per-jar is important and so is the runtime dependency resolution to make sure that the same library is not loaded from two different classloaders within the hierarchy. Here is my understanding on this scenario. First, you don't really need to develop a bundle for commons-logging package(s). Bundle B and C can just have the commons-logging packages on their Import-Package attribute, with the specific versions they need, for example: Import-Package = \ org.apache.commons...;version=1.1, \ * When bundle A have Bundle B and C's APIs listed on Bundle A's Import-Package attribute, it won't see the commons-logging package at all. It would only see the package if Bundle B/C exports the commons-logging package on its Export-Package attribute, and Bundle A has commons-logging package explicitly on its Import-Package attribute. random thoughts Hmm... I'm not sure what would happen if B and C used Require-Bundle and specify two different bundle names for libraries that provide the commons-logging library. Would we would see ClassCastExceptions (same as in Geronimo right now) or would osgi just pick one of these bundles as the default? Not sure about Require-Bundle. I personally has never used it and I never see it is being used in the OSGi repo. Require-Bundle may not offer the level of control that the Import-Package provides but it is probably a lot harder to come up with the right Import-Package lists. I think this scenario should work just fine if using Import-Package.
Re: Whence the geronimo kernel?
I think this is a valid concern. My understanding is that the OSGi community is working hard on this as they are working on specifications for a Web Container in OSGi with requirements like Java EE compliant web container in OSGi. They are also working on specifications for JNDI in OSGi, transaction in OSGi, JPA in OSGi, etc. Lin Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ...
