Re: [DISCUSS] Default server log level
I very much favor and endorse changing the file logging level to INFO. Ted Kirby On 9/11/07, Donald Woods <[EMAIL PROTECTED]> wrote: > I agree, that changing the file logging level to INFO is more usable for the > majority of our users. > > -Donald > > > Kevan Miller wrote: > > The intent of this thread is to discuss the default log level for the > > Geronimo server. I'd like to limit the discussion to the near-term (e.g. > > Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd > > like to see more structure and consistency in our logging. However, > > that's not a 2.0.x issue. > > > > The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, > > this is too restrictive. I think we should set the default to INFO. This > > will make our server logging more verbose. However, I'd rather have too > > much information, rather than too little. > > > > I think our default target audience should be application developers and > > new users evaluating Geronimo. Currently, these users are forced to > > configure log levels to INFO, so that they can obtain necessary > > information for building and deploying applications on Geronimo. This > > information should be available by default, not requiring configuration... > > > > Users who want to limit the logging output can reconfigure the default > > logging levels, once they are more comfortable with Geronimo. > > > > Comments? > > > > --kevan > > > > > >
Re: [VOTE] Release Geronimo Eclipse Plugin 2.0.0
Can you update this thread with a notice that this vote has been canceled and another will be started, given there has been several JIRAs fixed in the 2.0.0 branch since this vote started? -Donald Tim McConnell wrote: Hi, Please review and vote on the release of the Geronimo Eclipse Plugin 2.0.0 (to correspond with the Geronimo 2.0.1 Server release): The deployable zip file is here: > http://people.apache.org/~mcconne/releases/g-eclipse-plugin-2.0.0-deployable.zip The current svn location is here: > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.0.0 The future svn location will be here: > https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.0.0 The vote will conclude at 2:00 PM EST on Thursday, September 6th. smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Release Geronimo Eclipse Plugin 2.0.0
Tim, how is the 2.0.0 plugin updates coming? Do you have an outlook for when we'll be ready for another RC vote? -Donald Kevan Miller wrote: Hey Tim, Apologies for my slow review of the Eclipse plugin. Reviewing the binary distribution, it looks like we are missing license and notice information for xpp3. There may be a few more notices missing, also. With your permission, I'll make updates to the license and notice files in branches/2.0.0... --kevan smime.p7s Description: S/MIME Cryptographic Signature
[jira] Commented: (GERONIMO-2964) Cannot specify the Tomcat work directory for a web application
[ https://issues.apache.org/jira/browse/GERONIMO-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526661 ] Donald Woods commented on GERONIMO-2964: The way I verified that the original patch broke backwards compatibility with Geronimo 2.0.1, was I - 1) integrated the patch into a local 2.0.2-SNAPSHOT build 2) started the Tomcat JEE5 assembly and tried to install the existing geronimo-jsp-examples and geronimo-servlet-examples plugins from the 2.0.1 release. When the plugin was being installed, it threw an exception due to the mismatch in the new and CAR expected TomcatWebAppContext constructor > Cannot specify the Tomcat work directory for a web application > -- > > Key: GERONIMO-2964 > URL: https://issues.apache.org/jira/browse/GERONIMO-2964 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 1.2, 2.0-M5 >Reporter: Aman Nanner >Priority: Minor > Fix For: 1.2, 2.1 > > Attachments: g2964.war, GERONIMO-2964-combined.patch, > GERONIMO-2964.patch, tomcat-config-workdir.patch, tomcat-workdir.patch > > > In Tomcat, a work directory can be specified for a web application in a > WEB-INF/context.xml file. The GeronimoStandardContext does not permit the > user to specify a work directory, and so the work directory defaults to > var/catalina/work/. > I've submitted a patch file that modifies the geronimo-tomcat-1.2 schema to > permit the user to optionally specify a work directory. This work directory > is then propagated into the TomcatContext. I've tested this and it seems to > work well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Default server log level
I agree, that changing the file logging level to INFO is more usable for the majority of our users. -Donald Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
Thanks Filip for your continuing support of the Geronimo project, and of course for the important contributions you make to the Tomcat project. It must be frustrating to take a step back when so much progress has been made. But you did the right thing for the community and I'm confident things will get back on track quickly. Best wishes, Paul On Sep 11, 2007, at 8:19 PM, Filip Hanik - Dev Lists wrote: The whole debate was a huge fiasco, and unfortunately the one that screams the most and makes up the best stories win, not necessarily what is best for the community or the product. I had no choice but to follow what was going on. I'm not sure what is going to happen to this code base at this point, there is a lot more bs to be resolved before anything happens. I'm waiting to see if the board will say anything about the issue, if they stay dormant, then most likely that codebase will to. There is no way an API change like that will make it's way into a stable branch like 6.0.x. sorry about the hassle, but I had little support keeping it in trunk, the decision to move it to sandbox had nothing to do with comet, or anything else, simply egos that got in the way of rational decisions. Once again, my apologies, but you can't say I didn't try :| Filip Paul McMahan wrote: FYI, the Tomcat team decided to move tomcat/trunk to sandbox while details over RTC vs. CTR and their comet implementation are being resolved. The Geronimo 2.x Tomcat assemblies use a patched version of what was in tomcat/trunk for the enhanced annotation support. See https://issues.apache.org/jira/browse/GERONIMO-3206 for details on how Geronimo's patched version of Tomcat is built. I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a "patchset" with this annotation support. See http:// tinyurl.com/2enw25 Best wishes, Paul Begin forwarded message: From: [EMAIL PROTECTED] Date: September 7, 2007 10:35:34 PM EDT To: [EMAIL PROTECTED] Subject: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/ Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]> Author: fhanik Date: Fri Sep 7 19:35:33 2007 New Revision: 573772 URL: http://svn.apache.org/viewvc?rev=573772&view=rev Log: (empty) Added: tomcat/sandbox/gdev6x/ - copied from r573771, tomcat/trunk/ Removed: tomcat/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (GERONIMO-3265) Spring stale version in 2.0-M6-rc1
[ https://issues.apache.org/jira/browse/GERONIMO-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller resolved GERONIMO-3265. Resolution: Fixed Fix Version/s: (was: 2.0.x) 2.1 2.0.2 This has been fixed in branches/2.0 (574686) and trunk (574694). So, should be fixed in Geronimo 2.0.2 and 2.1 > Spring stale version in 2.0-M6-rc1 > -- > > Key: GERONIMO-3265 > URL: https://issues.apache.org/jira/browse/GERONIMO-3265 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M6, 2.0 > Environment: Windows XP SP2, Sun JSDK 1.5.07, Geronimo (2.0-M6-rc1) > obtained from: > http://people.apache.org/~hogstrom/2.0-M6-rc1/geronimo-tomcat6-jee5-2.0-M6-rc1-bin.zip > (2.0-M6-rc1) >Reporter: Alexei Kozich > Fix For: 2.0.2, 2.1 > > > 1. This Geronimo build includes spring-beans.jar, spring-context.jar and > spring-core.jar of version 2.0. > So as far as we know, version 2.0 does not fully support integration with JPA > implementations. > 2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 > and OpenJPA. > OpenJPA comes with Geronimo. > Deployment and start of this application fails, because of different versions > of Spring (our application expects spring-beans.jar, spring-context.jar and > spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of > version 2.0 (the lack of some methods in version 2.0 is the problem here). > 3. If we try to use inverse-classloading or hidden classes > (org.springframework) in geronimo-web.xml and include all necesary libs in > WEB-INF/lib following Exception is thrown during deployment and start of the > application (see below). > 4. We found temporary workaround: to replace spring-beans.jar, > spring-context.jar and spring-core.jar of version 2.0 with jars of version > 2.0.2 in Geronimo repository without using of inverse-classloading and hidden > classes and everything looks fine. > 5. So as far as I understand this out-of-the-box Geronimo build could not be > used as Server for Spring-OpenJPA appications. At least Spring libs upgrade > could solve this problem. > 6. Another problem is following Exception when using hidden classes or > inverse-classloading to load application jars first. > ERROR [ContextLoader] Context initialization failed > org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected > exception parsing XML document from ServletContext resource > [/WEB-INF/springAppContext.xml]; nested exception is > java.lang.IllegalArgumentException: Class > [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the > NamespaceHandler interface > Caused by: > java.lang.IllegalArgumentException: Class > [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the > NamespaceHandler interface > at > org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119) > at > org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.(DefaultNamespaceHandlerResolver.java:96) > at > org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.(DefaultNamespaceHandlerResolver.java:82) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) > at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317) > at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125) > at > org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141) > at > org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:123) > at > org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:91) > at > org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:94) >
Re: removal of spring dependencies from cxf module
On Sep 11, 2007, at 5:37 PM, Jarek Gawor wrote: I think we have an acceptable solution for this whole CXF/Spring issue. First, CXF will continue to be configured with Spring as before. Second, all web applications will now get an automatic filtering for Spring classes and resources. That should enable applications to have their own versions of Spring and reduce conflicts with Geronimo's version. The key to this solution was ensuring that CXF was initialized/configured with the CXF module classloader and not the application classloader. If the application classloader was used, and it had Spring filtering enabled, the Spring configuration files were filtered away. That caused incomplete configuration of CXF and failures later on. When CXF module classloader is used, the right Spring configuration files are discovered and things work nicely. Of course, now if the application has its own CXF configuration files they will be ignored. So this solution is not perfect but hopefully should be good enough for 2.0.2. I committed the changes to trunk and branches/2.0 if people want to review. Cool. Thanks Jarek! I think this will fix the Spring problems, we've seen to date with Jetty/CXF. There are still some things we can do, in addition to this: 1) Create a separate Spring module. The CXF module would be dependent upon this module. Other system modules could also be dependent upon this Spring module. Optionally, client applications could have a dependency on this module. 2) Currently, our ClassLoaders can only filter classes from their parents. Would be cleaner if we allowed the CXF module to filter Spring classes from its children. 3) Would be good to upgrade our Spring version. There used to be a problem with 2.0.5+ versions of Spring and XBean. I think I've fixed that in XBean. Possible that CXF has an issue with newer versions of Spring. --kevan
Re: Fwd: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/
The whole debate was a huge fiasco, and unfortunately the one that screams the most and makes up the best stories win, not necessarily what is best for the community or the product. I had no choice but to follow what was going on. I'm not sure what is going to happen to this code base at this point, there is a lot more bs to be resolved before anything happens. I'm waiting to see if the board will say anything about the issue, if they stay dormant, then most likely that codebase will to. There is no way an API change like that will make it's way into a stable branch like 6.0.x. sorry about the hassle, but I had little support keeping it in trunk, the decision to move it to sandbox had nothing to do with comet, or anything else, simply egos that got in the way of rational decisions. Once again, my apologies, but you can't say I didn't try :| Filip Paul McMahan wrote: FYI, the Tomcat team decided to move tomcat/trunk to sandbox while details over RTC vs. CTR and their comet implementation are being resolved. The Geronimo 2.x Tomcat assemblies use a patched version of what was in tomcat/trunk for the enhanced annotation support. See https://issues.apache.org/jira/browse/GERONIMO-3206 for details on how Geronimo's patched version of Tomcat is built. I raised a concern about moving trunk to sandbox since it's the only branch that contains the annotation support needed by Geronimo. A committer responded that he will think about maintaining a "patchset" with this annotation support. See http://tinyurl.com/2enw25 Best wishes, Paul Begin forwarded message: From: [EMAIL PROTECTED] Date: September 7, 2007 10:35:34 PM EDT To: [EMAIL PROTECTED] Subject: svn commit: r573772 - in /tomcat: sandbox/gdev6x/ trunk/ Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]> Author: fhanik Date: Fri Sep 7 19:35:33 2007 New Revision: 573772 URL: http://svn.apache.org/viewvc?rev=573772&view=rev Log: (empty) Added: tomcat/sandbox/gdev6x/ - copied from r573771, tomcat/trunk/ Removed: tomcat/trunk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: update on the pluggable admin console
This is kick ass awesome... :-) --jason On Sep 10, 2007, at 5:03 PM, Paul McMahan wrote: Recent work on GERONIMO-3413 provides a new admin console with two main improvements: - New system modules and 3rd party plugins can dynamically add and remove their portlets in the admin console - It has a smaller footrpint and minimal requirements on what's running in the server. You can, for example, use this new console in the minimal assemblies where Dojo and many jee5 components are not present. As you customize your server the corresponding admin portlets are dynamically added/removed from the admin console. To try it out, build yourself a 2.1-SNAPSHOT minimal assembly or you can use a jee5 assembly if you undeploy the old admin console first. Then: - svn co https://svn.apache.org/repos/asf/geronimo/plugins/ console/trunk - cd trunk - mvn install - /bin/deploy.sh install-plugin console-tomcat/target/console- tomcat-1.0-SNAPSHOT.car (for tomcat) or - /bin/deploy.sh install-plugin console-jetty/target/console- jetty-1.0-SNAPSHOT.car (for jetty) Then at: http://localhost:8080/console you will see the "base" console that only has the portlets for deployment, plugin management, security, etc. The other admin portlets you might recall from the old admin console can be selectively installed from the plugins available at: https://svn.apache.org/repos/asf/geronimo/plugins using steps similar to above. Note, the directory, roller, spring, and tuscany plugins in that area of svn don't provide admin console portlets yet. Actually I don't know if those plugins are compatible with Geronimo 2.1-SNAPSHOT since David has implemented a lot of improvements to the plugin system lately. Like I mentioned above, in 2.1-SNAPSHOT the old admin console is still pre-deployed in the jee5 assemblies while we figure out how to restructure svn and the build process around the plugin concepts. The new admin console is implemented as a plugin outside of server/trunk, so it should be easy to swap out the console bits out once we have everything else in place. If we want to support the new console in an upcoming 2.0.x release of Geronimo then David's recent changes to the car-maven-plugin, plugin schema, and plugin installer would need to be backported to the 2.0 branch, if that's appropriate. Also, I have some of the artifacts staged in my personal ASF area so that it's easier for you to build and test things out. After a few days for collecting feedback I will deploy those artifacts to the ASF snapshot repo if no major issues are identified. Various todos: - drive out the remaining bugs and rough spots. Like the JMX viewer has some problems. - fix weird http session problem in jetty, don't know if its a bug in jetty, pluto, or the console code - try to simplify the security model - update the doc on wiki - clean up poms Best wishes, Paul
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 5:05 PM, Kevan Miller wrote: On Sep 11, 2007, at 5:05 PM, Jason Dillon wrote: Are you refering to console output or what is captured in the log file? Heh. Come on, read my mind... :-P Um, ya... :-P I'm referring to the log FILE. I'm fine with our current CONSOLE behavior... Aighty, thats what I figured, but just wanted to be clear. I think changing the file appender to INFO is perfectly fine and reasonable... desirable even. --jason
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 5:05 PM, Jason Dillon wrote: Are you refering to console output or what is captured in the log file? Heh. Come on, read my mind... :-P I'm referring to the log FILE. I'm fine with our current CONSOLE behavior... --kevan
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 1:43 PM, Paul McMahan wrote: On Sep 11, 2007, at 1:27 PM, Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near- term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Right now users can add "-v" or "-vv" to the command line to control the logging level. How would this proposal affect those command line flags? -v and -vv only impact CONSOLE logging, not log FILE logging. That could be changed, I guess... IMO, a threshold setting of ERROR for CONSOLE is good. I'd prefer to see the FILE threshold set to INFO. --kevan
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526626
]
Tomasz Mazan commented on GERONIMO-3462:
Jarek
Thanks for your instruction. I'll try to implement your advices and reply with
test's result.
> Problem with throwing SOAPFaultException within WebService based on
> SessionBean
>
>
> Key: GERONIMO-3462
> URL: https://issues.apache.org/jira/browse/GERONIMO-3462
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: webservices
>Affects Versions: 2.0.1
> Environment: ApacheCXF as service provider
>Reporter: Tomasz Mazan
>Assignee: Jarek Gawor
>
> I create SOAPFaultException using code below:
> {noformat}
> public SOAPFaultException createFault(String errorCode, String
> errorString) {
> SOAPFault fault = null;
> try {
> fault = SOAPFactory.newInstance().createFault();
> fault.setFaultCode(new QName("foo", "bar", "abc"));
> fault.setFaultString(errorString);
> fault.setFaultActor("ACTOR");
> } catch (SOAPException ex) {
> return new SOAPFaultException(null);
> }
> return new SOAPFaultException(fault);
> }
> {noformat}
> and my WebMethod returns this exception in case internal exception:
> {noformat}
> @WebService(serviceName = "MyService", portName = "CustomerServices")
> @Stateless(name = "MyCustomerService")
> public class MyCustomerService {
>
> @EJB
> private CoreManager coreManager = null;
> public MyCustomerService() {
> }
> @WebMethod(operationName = "createCustomer")
> public Customer createCustomer(@WebParam(name = "identifier") String
> identifier) throws SOAPFaultException {
> try {
> return this.coreManager.createCustomer(identifier);
> } catch (ServiceException e) {
> throw this.faultService.createFault("FAULT CODE",
> "FAULT STRING");
> }
>
> }
> }
> {noformat}
> and client catches fault with attributes:
> {noformat}
> ["faultstring"]=> string(298) "java.rmi.RemoteException: The bean
> encountered a non-application exception.; nested exception is:
> javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
> non-application exception.; nested exception i
> s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING"
> ["faultcode"]=> string(11) "soap:Server"
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: removal of spring dependencies from cxf module
I think we have an acceptable solution for this whole CXF/Spring issue. First, CXF will continue to be configured with Spring as before. Second, all web applications will now get an automatic filtering for Spring classes and resources. That should enable applications to have their own versions of Spring and reduce conflicts with Geronimo's version. The key to this solution was ensuring that CXF was initialized/configured with the CXF module classloader and not the application classloader. If the application classloader was used, and it had Spring filtering enabled, the Spring configuration files were filtered away. That caused incomplete configuration of CXF and failures later on. When CXF module classloader is used, the right Spring configuration files are discovered and things work nicely. Of course, now if the application has its own CXF configuration files they will be ignored. So this solution is not perfect but hopefully should be good enough for 2.0.2. I committed the changes to trunk and branches/2.0 if people want to review. Jarek On 8/27/07, David Jencks <[EMAIL PROTECTED]> wrote: > > On Aug 27, 2007, at 11:26 AM, Jeff Genender wrote: > > > David, > > > > So perhaps I am missing something and you could help clarify this. > > You > > say "It's by no means obvious to me that treating this as a problem > > with > > the coding of our classloaders is appropriate." Yet in your 1, 2, > > and 3 > > options, you seem to be saying its basically a problem with > > classloading. Is it our classloaders, or is it Spring's (or other)? > > Sorry I'm not being clear. > 1>> problem with cxf that no amount of changing our classloader code > or configuration will fix. The same problem would occur in tomcat if > you tried to use a spring version incompatible with cxf. > > 2>> our classloader works as long as you provide spring in the web > app for use by the web app. We could optionally enhance our > classloader so a user would not need spring added to hidden-classes > for the web app. > > 3>> For ease in making sure the classes from our copy of spring are > normally loaded in the same classloader no matter who is using them, > we might consider have a spring configuration with just the spring > classes in it. This would be more useful if the optional enhancement > suggested in (2) was made. > > So I don't see any way the code in our classloaders is wrong. We > might be able to make some things more convenient, and one of those > things would involve a new feature in our classloaders. > > I know there's a good chance I'm still writing incomprehensibly, so > don't be shy if this still doesn't make sense :-) > > thanks > david jencks > > > > > Jeff > > > > David Jencks wrote: > > > >> Cool down a minute and think about this. What happens in tomcat > >> if you > >> want to use cxf + an incompatible version of spring in your app? You > >> bundle cxf + springA + springB into your web-app and then what > >> happens? > >> > >> IMO we are talking about trying to get geronimo to generically > >> solve a > >> problem that tomcat forces its users to deal with on an per-app > >> basis. > >> > >> It's by no means obvious to me that treating this as a problem > >> with the > >> coding of our classloaders is appropriate. Here are some > >> possibilities > >> I can think of off the top of my head: > >> > >> 1. cxf generates some code for each web service client/service that > >> directly use spring classes. In this case there is AFAIK no way > >> for an > >> app to use a different spring version since these generated > >> classes are > >> going to be loaded in the application classloader and they need > >> access > >> to cxf's copy of spring classes. If this is what is going on I hope > >> it's possible for cxf to stop doing this. > >> > >> 2. If putting spring in the apps hidden-classes works and allows > >> the app > >> to use a different spring version, then evidently (1) isn't a > >> problem. > >> In this case if we automatically add spring to hidden-classes of > >> every > >> app we would be preventing all apps from using our copy of spring > >> which > >> seems undesirable to me. hidden-classes currently means "don't > >> import > >> these classes from parents". We could look into also having a "don't > >> export these classes to children" filter in our classloader. > >> > >> 3. With just the "don't export" filter proposed in (2), people adding > >> the spring jars to their dependency list would be getting spring > >> loaded > >> in a different classloader for their app and for cxf. This might > >> not be > >> desirable. We could make a spring configuration to provide a single > >> classloader to load spring in that cxf and apps could depend on. > >> > >> thanks > >> david jencks > >> > >>> > >>> > > I believe it's the latter. In which case, you're not giving me an > apples-to-apples comparison, IMO. > > >>> > >>> Well...lets agree to disagree. The bottom line is we are castrating > >>
Re: [DISCUSS] Default server log level
Are you refering to console output or what is captured in the log file? --jason -Original Message- From: Kevan Miller <[EMAIL PROTECTED]> Date: Tue, 11 Sep 2007 13:27:20 To:Geronimo Dev Subject: [DISCUSS] Default server log level The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan
Re: [DISCUSS] Default server log level
I don't mind if INFO is the default log level. It would be nice if we can also change it 1. during Geronimo startup. 2. during runtime. Possible ? Cheers Prasad On 9/11/07, Kevan Miller <[EMAIL PROTECTED]> wrote: > The intent of this thread is to discuss the default log level for the > Geronimo server. I'd like to limit the discussion to the near-term > (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging > code. I'd like to see more structure and consistency in our logging. > However, that's not a 2.0.x issue. > > The current default log level for a Geronimo 2.0.1 server is ERROR. > IMO, this is too restrictive. I think we should set the default to > INFO. This will make our server logging more verbose. However, I'd > rather have too much information, rather than too little. > > I think our default target audience should be application developers > and new users evaluating Geronimo. Currently, these users are forced > to configure log levels to INFO, so that they can obtain necessary > information for building and deploying applications on Geronimo. This > information should be available by default, not requiring > configuration... > > Users who want to limit the logging output can reconfigure the > default logging levels, once they are more comfortable with Geronimo. > > Comments? > > --kevan >
[jira] Resolved: (GERONIMO-3401) Stop of module from "System Modules" in console should warn user of destructive action
[
https://issues.apache.org/jira/browse/GERONIMO-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Bohn resolved GERONIMO-3401.
Resolution: Fixed
Fix Version/s: 2.1
This issue has been resolved by disabling potentially distruptive actions on
Geronimo provided components with a checkbox override to enable the actions for
expert users. In addition to this there are new, detailed challenges when you
attempt a potentially distructive action on a Geronimo provided component.
> Stop of module from "System Modules" in console should warn user of
> destructive action
> --
>
> Key: GERONIMO-3401
> URL: https://issues.apache.org/jira/browse/GERONIMO-3401
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
>Affects Versions: 2.0, 2.0.x
> Environment: Geronimo 2.0.1-SNAPSHOT using Tomcat JEE assembly. Most
> likely affects others as well
>Reporter: Matt Hogstrom
>Assignee: Joe Bohn
> Fix For: 2.0.x, 2.1
>
>
> When using the Geronimo Console to stop of a module a 404 is received in the
> console. In this case an attempt to stop OpenEJB. The console then becomes
> unusable and also does not survive a restart. It appears the console needs
> to be re-installed.
> {panel:title=Error reported to Browser| borderStyle=dashed| borderColor=#ccc|
> titleBGColor=#F7D6C1| bgColor=#CE}
> HTTP Status 404 -
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> type Status report
> message
> /console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view
> description The requested resource
> (/console/portal/apps/apps_system/_st_apps_system_row1_col1_p1/normal/_rp_apps_system_row1_col1_p1_message/1_/_pid/apps_system_row1_col1_p1/_md_apps_system_row1_col1_p1/view)
> is not available.
> {panel}
> {panel:title=Exception LoggedMy Title| borderStyle=dashed| borderColor=#ccc|
> titleBGColor=#F7D6C1| bgColor=#CE}
> [] received stop signal
> 00:59:03,833 ERROR [Servlet] Exception caught:
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid
> to gbean:
> org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/transaction/2.0.1-SNAPSHOT/car,j2eeType=JCAConnectionTracker,name=ConnectionTracker
> at
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at
> org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$4301e6fc.exit()
> at
> org.apache.geronimo.tomcat.interceptor.InstanceContextBeforeAfter.after(InstanceContextBeforeAfter.java:73)
> at
> org.apache.geronimo.tomcat.interceptor.ComponentContextBeforeAfter.after(ComponentContextBeforeAfter.java:46)
> at
> org.apache.geronimo.tomcat.interceptor.PolicyContextBeforeAfter.after(PolicyContextBeforeAfter.java:70)
> at
> org.apache.geronimo.tomcat.interceptor.UserTransactionBeforeAfter.after(UserTransactionBeforeAfter.java:47)
> at
> org.apache.geronimo.tomcat.listener.DispatchListener.afterDispatch(DispatchListener.java:86)
> at
> org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(DispatchListener.java:59)
> at
> org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:275)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:682)
> at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:557)
> at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:481)
> at
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
> at
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java: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
> o
Re: [DISCUSS] Default server log level
Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? I agree with your proposal for a default of INFO and your assertion about our target users and what they most likely want. I also personally prefer to have too much info rather than too little ... so I'm all in favor of the change. Joe
[jira] Commented: (GERONIMO-3462) Problem with throwing SOAPFaultException within WebService based on SessionBean
[
https://issues.apache.org/jira/browse/GERONIMO-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526566
]
Jarek Gawor commented on GERONIMO-3462:
---
Tomek,
I'm still unable to reproduce your result. I created a test case in Geronimo
for this issue. Can you maybe test your php client against the test service in
Geronimo?
To get/build the test service:
1) check out Geronimo from trunk and build it
2) start Geronimo (either your version or the one you just built)
3) cd testsuite/webservices-testsuite/jaxws-tests/jaxws-ejb and run "mvn -P
child".
The last step will build the test service, deploy it, run some tests (they all
should pass), and undeploy it. Once that is done, you can deploy by hand the
generated .jar file in the target directory. Then update your php script to
talk to this service and see how the fault looks like.
> Problem with throwing SOAPFaultException within WebService based on
> SessionBean
>
>
> Key: GERONIMO-3462
> URL: https://issues.apache.org/jira/browse/GERONIMO-3462
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: webservices
>Affects Versions: 2.0.1
> Environment: ApacheCXF as service provider
>Reporter: Tomasz Mazan
>Assignee: Jarek Gawor
>
> I create SOAPFaultException using code below:
> {noformat}
> public SOAPFaultException createFault(String errorCode, String
> errorString) {
> SOAPFault fault = null;
> try {
> fault = SOAPFactory.newInstance().createFault();
> fault.setFaultCode(new QName("foo", "bar", "abc"));
> fault.setFaultString(errorString);
> fault.setFaultActor("ACTOR");
> } catch (SOAPException ex) {
> return new SOAPFaultException(null);
> }
> return new SOAPFaultException(fault);
> }
> {noformat}
> and my WebMethod returns this exception in case internal exception:
> {noformat}
> @WebService(serviceName = "MyService", portName = "CustomerServices")
> @Stateless(name = "MyCustomerService")
> public class MyCustomerService {
>
> @EJB
> private CoreManager coreManager = null;
> public MyCustomerService() {
> }
> @WebMethod(operationName = "createCustomer")
> public Customer createCustomer(@WebParam(name = "identifier") String
> identifier) throws SOAPFaultException {
> try {
> return this.coreManager.createCustomer(identifier);
> } catch (ServiceException e) {
> throw this.faultService.createFault("FAULT CODE",
> "FAULT STRING");
> }
>
> }
> }
> {noformat}
> and client catches fault with attributes:
> {noformat}
> ["faultstring"]=> string(298) "java.rmi.RemoteException: The bean
> encountered a non-application exception.; nested exception is:
> javax.xml.ws.soap.SOAPFaultException: FAULT STRING: The bean encountered a
> non-application exception.; nested exception i
> s: javax.xml.ws.soap.SOAPFaultException: FAULT STRING"
> ["faultcode"]=> string(11) "soap:Server"
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: update on the pluggable admin console
Folks, here is some additional docs for the pluggable console. User's and Developer's guide: http://cwiki.apache.org/GMOxDEV/pluggable-administration-console.html Online presentation: http://cwiki.apache.org/geronimo/pluggable-administration-console.html Cheers! Hernan Matt Hogstrom wrote: This is excellent...I'll give it a spin today . On Sep 10, 2007, at 5:03 PM, Paul McMahan wrote: Recent work on GERONIMO-3413 provides a new admin console with two main improvements: - New system modules and 3rd party plugins can dynamically add and remove their portlets in the admin console - It has a smaller footrpint and minimal requirements on what's running in the server. You can, for example, use this new console in the minimal assemblies where Dojo and many jee5 components are not present. As you customize your server the corresponding admin portlets are dynamically added/removed from the admin console. To try it out, build yourself a 2.1-SNAPSHOT minimal assembly or you can use a jee5 assembly if you undeploy the old admin console first. Then: - svn co https://svn.apache.org/repos/asf/geronimo/plugins/console/trunk - cd trunk - mvn install - /bin/deploy.sh install-plugin console-tomcat/target/console-tomcat-1.0-SNAPSHOT.car (for tomcat) or - /bin/deploy.sh install-plugin console-jetty/target/console-jetty-1.0-SNAPSHOT.car (for jetty) Then at: http://localhost:8080/console you will see the "base" console that only has the portlets for deployment, plugin management, security, etc. The other admin portlets you might recall from the old admin console can be selectively installed from the plugins available at: https://svn.apache.org/repos/asf/geronimo/plugins using steps similar to above. Note, the directory, roller, spring, and tuscany plugins in that area of svn don't provide admin console portlets yet. Actually I don't know if those plugins are compatible with Geronimo 2.1-SNAPSHOT since David has implemented a lot of improvements to the plugin system lately. Like I mentioned above, in 2.1-SNAPSHOT the old admin console is still pre-deployed in the jee5 assemblies while we figure out how to restructure svn and the build process around the plugin concepts. The new admin console is implemented as a plugin outside of server/trunk, so it should be easy to swap out the console bits out once we have everything else in place. If we want to support the new console in an upcoming 2.0.x release of Geronimo then David's recent changes to the car-maven-plugin, plugin schema, and plugin installer would need to be backported to the 2.0 branch, if that's appropriate. Also, I have some of the artifacts staged in my personal ASF area so that it's easier for you to build and test things out. After a few days for collecting feedback I will deploy those artifacts to the ASF snapshot repo if no major issues are identified. Various todos: - drive out the remaining bugs and rough spots. Like the JMX viewer has some problems. - fix weird http session problem in jetty, don't know if its a bug in jetty, pluto, or the console code - try to simplify the security model - update the doc on wiki - clean up poms Best wishes, Paul
Re: [DISCUSS] Default server log level
On Sep 11, 2007, at 1:27 PM, Kevan Miller wrote: The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near- term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Right now users can add "-v" or "-vv" to the command line to control the logging level. How would this proposal affect those command line flags? Best wishes, Paul
[DISCUSS] Default server log level
The intent of this thread is to discuss the default log level for the Geronimo server. I'd like to limit the discussion to the near-term (e.g. Geronimo 2.0.x). IMO, we need a good overhaul of our logging code. I'd like to see more structure and consistency in our logging. However, that's not a 2.0.x issue. The current default log level for a Geronimo 2.0.1 server is ERROR. IMO, this is too restrictive. I think we should set the default to INFO. This will make our server logging more verbose. However, I'd rather have too much information, rather than too little. I think our default target audience should be application developers and new users evaluating Geronimo. Currently, these users are forced to configure log levels to INFO, so that they can obtain necessary information for building and deploying applications on Geronimo. This information should be available by default, not requiring configuration... Users who want to limit the logging output can reconfigure the default logging levels, once they are more comfortable with Geronimo. Comments? --kevan
[jira] Commented: (GERONIMO-3465) Default log level needs to be tweaked to provide more useful information to users
[ https://issues.apache.org/jira/browse/GERONIMO-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526526 ] Kevan Miller commented on GERONIMO-3465: Um, how about we "discuss" it first? :-P I see no need to start voting, ATM... I'll start a thread. > Default log level needs to be tweaked to provide more useful information to > users > - > > Key: GERONIMO-3465 > URL: https://issues.apache.org/jira/browse/GERONIMO-3465 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1 >Reporter: Kevan Miller >Priority: Critical > Fix For: 2.0.2, 2.1 > > > default log level is currently ERROR. This is too strict for many users. We > should default to being more verbose and provide useful information to new > Geronimo users/developers. Users who want less verbose output can tune their > server-log4j properties accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Schema conversion
--- David Jencks <[EMAIL PROTECTED]> wrote: > Hi Anita! > > When I removed the remote login stuff I wrote some schema conversion > > code but left it incomplete when I realized it would have to remove a > > reference to a gbean I was removing (JaasLoginService?? I can't quite > > remember). My thinking was that if someone was using remote login we > > would be drastically changing the behavior of their configuration > without telling them, so it was better not to try to automatically > convert the configuration. However, I left the partial conversion > code in place. > > At this point I'm not sure whether it would be better to move > forwards towards a "convert it so it deploys" conversion or back > towards "make the user do the entire conversion". What do you think? I think ""make the user do the entire conversion" is ok :). The xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-1.2"; was very short lived. It was not used in any released versions. We need to update the samples on the wiki soon. Thanks for the explanation! Anita > > thanks > david jencks > > On Sep 11, 2007, at 6:16 AM, Anita Kulshreshtha wrote: > > > The following schema is converted to > > xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0";, but > the > > server-side="true" is not removed from the converted schema. This > > results in a failed deployment (error pasted below). Is this > expected > > behavior? > > > >> xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-1.2";> > > server-side="true" > > wrap-principals="false"> > > > > Thanks > > Anita > > > > cvc-complex-type.3.2.1: Attribute not allowed (no wildcards > allowed): > > server-side in element > > [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/loginconfig-2.0 > > > > > > > > > > > __ > > > __ > > Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get > > > listings, and more! > > http://tv.yahoo.com/collections/3658 > > Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
[jira] Commented: (GERONIMO-3465) Default log level needs to be tweaked to provide more useful information to users
[ https://issues.apache.org/jira/browse/GERONIMO-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526496 ] Matt Hogstrom commented on GERONIMO-3465: - Donald, personally I don't like lots of gorp coming out so I expect whatever we choose someone will be unhappy. I'd suggest a vote to gather community consensus and let's make that the default going forward. Would you like to do this ? > Default log level needs to be tweaked to provide more useful information to > users > - > > Key: GERONIMO-3465 > URL: https://issues.apache.org/jira/browse/GERONIMO-3465 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0.1 >Reporter: Kevan Miller >Priority: Critical > Fix For: 2.0.2, 2.1 > > > default log level is currently ERROR. This is too strict for many users. We > should default to being more verbose and provide useful information to new > Geronimo users/developers. Users who want less verbose output can tune their > server-log4j properties accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: update on the pluggable admin console
This is excellent...I'll give it a spin today . On Sep 10, 2007, at 5:03 PM, Paul McMahan wrote: Recent work on GERONIMO-3413 provides a new admin console with two main improvements: - New system modules and 3rd party plugins can dynamically add and remove their portlets in the admin console - It has a smaller footrpint and minimal requirements on what's running in the server. You can, for example, use this new console in the minimal assemblies where Dojo and many jee5 components are not present. As you customize your server the corresponding admin portlets are dynamically added/removed from the admin console. To try it out, build yourself a 2.1-SNAPSHOT minimal assembly or you can use a jee5 assembly if you undeploy the old admin console first. Then: - svn co https://svn.apache.org/repos/asf/geronimo/plugins/console/ trunk - cd trunk - mvn install - /bin/deploy.sh install-plugin console-tomcat/target/console- tomcat-1.0-SNAPSHOT.car (for tomcat) or - /bin/deploy.sh install-plugin console-jetty/target/console- jetty-1.0-SNAPSHOT.car (for jetty) Then at: http://localhost:8080/console you will see the "base" console that only has the portlets for deployment, plugin management, security, etc. The other admin portlets you might recall from the old admin console can be selectively installed from the plugins available at: https://svn.apache.org/repos/asf/geronimo/plugins using steps similar to above. Note, the directory, roller, spring, and tuscany plugins in that area of svn don't provide admin console portlets yet. Actually I don't know if those plugins are compatible with Geronimo 2.1-SNAPSHOT since David has implemented a lot of improvements to the plugin system lately. Like I mentioned above, in 2.1-SNAPSHOT the old admin console is still pre-deployed in the jee5 assemblies while we figure out how to restructure svn and the build process around the plugin concepts. The new admin console is implemented as a plugin outside of server/trunk, so it should be easy to swap out the console bits out once we have everything else in place. If we want to support the new console in an upcoming 2.0.x release of Geronimo then David's recent changes to the car-maven-plugin, plugin schema, and plugin installer would need to be backported to the 2.0 branch, if that's appropriate. Also, I have some of the artifacts staged in my personal ASF area so that it's easier for you to build and test things out. After a few days for collecting feedback I will deploy those artifacts to the ASF snapshot repo if no major issues are identified. Various todos: - drive out the remaining bugs and rough spots. Like the JMX viewer has some problems. - fix weird http session problem in jetty, don't know if its a bug in jetty, pluto, or the console code - try to simplify the security model - update the doc on wiki - clean up poms Best wishes, Paul
Re: Schema conversion
Hi Anita! When I removed the remote login stuff I wrote some schema conversion code but left it incomplete when I realized it would have to remove a reference to a gbean I was removing (JaasLoginService?? I can't quite remember). My thinking was that if someone was using remote login we would be drastically changing the behavior of their configuration without telling them, so it was better not to try to automatically convert the configuration. However, I left the partial conversion code in place. At this point I'm not sure whether it would be better to move forwards towards a "convert it so it deploys" conversion or back towards "make the user do the entire conversion". What do you think? thanks david jencks On Sep 11, 2007, at 6:16 AM, Anita Kulshreshtha wrote: The following schema is converted to xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0";, but the server-side="true" is not removed from the converted schema. This results in a failed deployment (error pasted below). Is this expected behavior? http://geronimo.apache.org/xml/ns/loginconfig-1.2";> Thanks Anita cvc-complex-type.3.2.1: Attribute not allowed (no wildcards allowed): server-side in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/loginconfig-2.0 __ __ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658
[jira] Assigned: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell reassigned GERONIMODEVTOOLS-202: -- Assignee: Shiva Kumar H R (was: Tim McConnell) > "A geronimo installation was detected, however the version could not be > verified" warning while adding Geronimo 2.0.1 > - > > Key: GERONIMODEVTOOLS-202 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Shiva Kumar H R >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-202-temp.patch > > > Initial debugging shows that this is due to: > org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method > returning null, which in turn is due to missing "geronimo-system-*.jar" file > in \lib directory of Geronimo 2.0.1 installation. > geronimo-system-2.0.1.jar can however be found > "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" > directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526477 ] Tim McConnell commented on GERONIMODEVTOOLS-202: Hi Shiva, I share your concern as well, but I'm not sure you have too much of a choice at this point. One thing though that you should consider is to just give it the top-level directory of the path and let the plugin search and find the jarfile. That's how I tried to mitigate the similar situations in GeronimoServerRuntimeTargetHandler. One advantage of this approach is that your code shouldn't have to be changed again when a new version of the Server is introduced, assuming of course that the main geroimo-server path remains the same, which is probably a good assumption. Plus, of course you don't have to hardcode the name of the jarfile. Thanks. > "A geronimo installation was detected, however the version could not be > verified" warning while adding Geronimo 2.0.1 > - > > Key: GERONIMODEVTOOLS-202 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Tim McConnell >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-202-temp.patch > > > Initial debugging shows that this is due to: > org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method > returning null, which in turn is due to missing "geronimo-system-*.jar" file > in \lib directory of Geronimo 2.0.1 installation. > geronimo-system-2.0.1.jar can however be found > "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" > directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-199) javax.xml.bind is not included in server runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526465 ] Tim McConnell commented on GERONIMODEVTOOLS-199: Hi Jacek, sorry if I was unclear in my previous comment. I did add a new plugin version to the unstable build site for that very reason. It is named: http://people.apache.org/dist/geronimo/eclipse/unstable/g-eclipse-plugin-2.0.0-deployable.zip It doesn't have a version in the form of a date/timestamp since it is being built from branches and not trunk. Thanks. > javax.xml.bind is not included in server runtime library > > > Key: GERONIMODEVTOOLS-199 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Tomasz Mazan >Assignee: Tim McConnell > Fix For: 2.0 > > > JAX-B classes/annotation are not included in default Geronimo's server > runtime so user must include single jar to use i.e. XmlElement to annotate > classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3457) Drools BRMS issue using geronimo 2.0.1-jetty6
[ https://issues.apache.org/jira/browse/GERONIMO-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526459 ] Bhagwath Vadyala commented on GERONIMO-3457: we are using jdk1.6.0_01. > Drools BRMS issue using geronimo 2.0.1-jetty6 > - > > Key: GERONIMO-3457 > URL: https://issues.apache.org/jira/browse/GERONIMO-3457 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Jetty >Affects Versions: 2.0.1 > Environment: geronimo 2.0.1-jetty6 > windows > drools-jbrms 4.0.1 >Reporter: Bhagwath Vadyala > Attachments: drools-error-screenshot.doc, > geronimo-jetty-server-log.txt > > > We are having an issuing testing drools BRMS 4.0.1 on geronimo 2.0.1 jetty 6 > version. > It deploys fine but when we open the url http://localhost:8080/drools-jbrms, > its not redirecting to correct page. > We use the same drools-jbrms war file and deploy on jboss-tomcat it works > fine and redirects to the correct page. > We posted the issue to JBOSS and here is the response from them. > Michael Neale commented on JBRULES-1150: > > ok the URL in the browser it wrong. > Ideally you will put in: > http://localhost:8080/drools-jbrms > and it *should* redirect to : > http://localhost:8080/drools-jbrms/org.drools.brms.JBRMS/JBRMS.html > if it doesn't - then it is a bug with how geronimo is redirecting. > The index.jsp, which is default, has: ><% >String redirectURL = "org.drools.brms.JBRMS/JBRMS.html"; >response.sendRedirect(redirectURL); >%> > which should work as it does on every other app server tried so far. > unfortunately we don't have resources to support every purmutation of app > servers/web containers so this will require some experimentation. please let > me know how you go. > .. > Please let me know how to fix this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Schema conversion
The following schema is converted to xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0";, but the server-side="true" is not removed from the converted schema. This results in a failed deployment (error pasted below). Is this expected behavior? http://geronimo.apache.org/xml/ns/loginconfig-1.2";> Thanks Anita cvc-complex-type.3.2.1: Attribute not allowed (no wildcards allowed): server-side in element [EMAIL PROTECTED]://geronimo.apache.org/xml/ns/loginconfig-2.0 Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658
[jira] Commented: (GERONIMODEVTOOLS-199) javax.xml.bind is not included in server runtime library
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526433 ] Jacek Laskowski commented on GERONIMODEVTOOLS-199: -- I'd ask you to put a new plugin version to the unstable build site as it gives people who've been struggling with the issue a way to work with a fixed plugin and don't see a problem anymore. > javax.xml.bind is not included in server runtime library > > > Key: GERONIMODEVTOOLS-199 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-199 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Tomasz Mazan >Assignee: Tim McConnell > Fix For: 2.0 > > > JAX-B classes/annotation are not included in default Geronimo's server > runtime so user must include single jar to use i.e. XmlElement to annotate > classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-202: Assignee: Tim McConnell > "A geronimo installation was detected, however the version could not be > verified" warning while adding Geronimo 2.0.1 > - > > Key: GERONIMODEVTOOLS-202 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Tim McConnell >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-202-temp.patch > > > Initial debugging shows that this is due to: > org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method > returning null, which in turn is due to missing "geronimo-system-*.jar" file > in \lib directory of Geronimo 2.0.1 installation. > geronimo-system-2.0.1.jar can however be found > "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" > directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-202: - Attachment: GERONIMODEVTOOLS-202-temp.patch Tim, I am not happy with hard-coding paths as done in this patch. Do you see a better way of solving this? > "A geronimo installation was detected, however the version could not be > verified" warning while adding Geronimo 2.0.1 > - > > Key: GERONIMODEVTOOLS-202 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-202-temp.patch > > > Initial debugging shows that this is due to: > org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method > returning null, which in turn is due to missing "geronimo-system-*.jar" file > in \lib directory of Geronimo 2.0.1 installation. > geronimo-system-2.0.1.jar can however be found > "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" > directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526399 ] Vamsavardhana Reddy commented on GERONIMODEVTOOLS-202: -- What happens if there is another geronimo-system-*.jar \repository\org\apache\geronimo\modules\geronimo-system\ in my repo for some reason?. There should be some other (proper?) way of detecting the version. > "A geronimo installation was detected, however the version could not be > verified" warning while adding Geronimo 2.0.1 > - > > Key: GERONIMODEVTOOLS-202 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Priority: Minor > Fix For: 2.0 > > > Initial debugging shows that this is due to: > org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method > returning null, which in turn is due to missing "geronimo-system-*.jar" file > in \lib directory of Geronimo 2.0.1 installation. > geronimo-system-2.0.1.jar can however be found > "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" > directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-202) "A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1
"A geronimo installation was detected, however the version could not be verified" warning while adding Geronimo 2.0.1 - Key: GERONIMODEVTOOLS-202 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-202 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Shiva Kumar H R Priority: Minor Fix For: 2.0 Initial debugging shows that this is due to: org.apache.geronimo.st.core.GeronimoRuntimeDelegate.detectVersion() method returning null, which in turn is due to missing "geronimo-system-*.jar" file in \lib directory of Geronimo 2.0.1 installation. geronimo-system-2.0.1.jar can however be found "\repository\org\apache\geronimo\modules\geronimo-system\2.0.1" directory of AG 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-6) Refactor output and verbosity filters
[
https://issues.apache.org/jira/browse/GSHELL-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GSHELL-6.
-
Resolution: Fixed
> Refactor output and verbosity filters
> -
>
> Key: GSHELL-6
> URL: https://issues.apache.org/jira/browse/GSHELL-6
> Project: GShell
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-1
>
>
> {noformat}
> IO.trace() -vvv
> IO.debug() -vv
> Add IO.info() -v
> IO.warn() unless -q
> IO.error()
> {noformat}
> This means that IO will need to know the verbosity setting... :-(
> Need methods to handle exceptions too, for remoteness can not use logging for
> error reporting
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SM-1044) Routing based on message property and set new property on the message in EIP content based router
Sorry for long response time. I will look into your patch as soon as possible. Cheers, Thomas Termin Vinod Chhabria (JIRA) wrote: > [ > https://issues.apache.org/activemq/browse/SM-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40120 > ] > > Vinod Chhabria commented on SM-1044: > > > We think this is a good enhancement to the existing predicate classes. Can > you please approve so we can go ahead and add this to our servicemix > installation. We do not want to apply any patch that will not be available in > future releases. > > If you think this is too specific and not good enough to be added as a patch > to the servicemix-eip distribution, then please provide us documentation as > to how to include our custom predicate class to our service unit. We tried > doing it but it is requiring all other eip classes to be included in the > service unit. > > Please advise so we can resolve either way. > > >>Routing based on message property and set new property on the message in EIP >>content based router >>- >> >>Key: SM-1044 >>URL: https://issues.apache.org/activemq/browse/SM-1044 >>Project: ServiceMix >> Issue Type: New Feature >> Components: servicemix-eip >> Affects Versions: 3.1 >>Environment: Windows, JBoss-4.0.4-GA using Servicemix deployer >> Reporter: Srivatsan Sridharan >> Priority: Minor >>Attachments: SwitchPredicate.java, XPathPredicate.java >> >> >>SwitchPredicate.java (available in Servicemix trunk) routes based on the >>(boolean) value of the property set on the message exchange. It would be good >>to have it >>1) route based on the value (not particularly boolean) of a property set on >>the message. >>2) set additional property on the message when the evaluation of property >>value is true. >>SwitchPredicate.java attached herewith has the changes to address the above. >> >>XPathPredicate.java attached herewith has the changes to set additional >>property in the ContentBasedRouter. >>Please let me know if this is the right approach. > > -- Thomas Termin ___ blue elephant systems GmbH Wollgrasweg 49 D-70599 Stuttgart Tel: (+49) 0711 - 45 10 17 676 Fax: (+49) 0711 - 45 10 17 573 WWW: http://www.blue-elephant-systems.com Email : [EMAIL PROTECTED] blue elephant systems GmbH Firmensitz : Wollgrasweg 49, D-70599 Stuttgart Registergericht : Amtsgericht Stuttgart, HRB 24106 Geschäftsführer : Holger Dietrich, Thomas Gentsch, Joachim Hoernle
Plugin progress
I've now updated enough of the configs so we can see if we can assemble them into a server. It would be great if some one else could take a look at some of the remaining ones, list at the end of this email. To get your own list of un-cleaned-up configs build g, fire it up, and run search-plugins from the command line deployer: the ones aren't done yet. To provide a more reasonable sized testbed for assembling servers out of plugins I also shrank geronimo-framework to the minimum possible size: rmi-naming plus enough security to enable the command line deployer to connect to it. So, while some parts of plugin installation work, overall it doesn't. I keep seeing plugin installation pull in the wrong version of jars and cars and sometimes not find jars that are present in the local maven repo. Here are the problems I've noted so far, in order of discovery: 1. While reviewing config poms I saw some suspicious dependencies. Axis and Axis2 depend on openejb which subverts any attempt to run axis web services on a minimal server. The openejb-deployer requires openejb to be running which subverts any attempt to deploy offline while another server is running on the same machine (port conflicts). 2. Figuring out which repository to look in doesn't work yet. While what is specified in the geronimo-plugin.xml and geronimo-plugins.xml does appear to be honored, using these isn't compatible with developing and testing plugins, since while a plugin is being worked on you want to use only your local repo but after its published you don't (unless perhaps its is hooked up to some kind of maven proxy) I wonder if having a "default" repo configured in the plugin installer system would work, or perhaps merging the repos at the end of geronimo-plugins.xml with those in each geronimo-plugin.xml. 3. version resolution appears to have some serious problems. I think pretty much all of the geronimo-plugin.xmls contain versions for every jar (something I'm hoping to change) but I ran into a lot of problems. First most of the artifacts got resolved to the 2.0.1 released artifacts which didn't work because the car files didn't have valid geronimo-plugin.xmls in them. After I removed all my 2.0.1 artifacts things were slightly better until I got to something that wouldn't resolve at all, xbean-reflect 3.2-SNAPSHOT. The jar is in my local repo but for some reason it wasn't found. 4. I am doubting more and more that the current "requires" and "obsoletes" data are appropriate. For instance, most of the web apps "require" jetty (or tomcat, pick your flavor). IMO this is the wrong idea. If I want to install one of these web apps, it should install the web server if it's not already present. What I think is more appropriate would be if I'm trying to install a jetty web app and tomcat is installed it should complain: if no other web server is installed then it should install jetty for me. 5. Trying to extract information about what went wrong is really hard and unpleasant. 6. With the CTS configs that happen to be on my machine, there are 93. This is a lot to wade through. We need a better way of organizing them, at least on the command line. Perhaps providing a list of categories to pick from, then the plugins from that category, would be more manageable. Also a "deploy this from this maven repo" command would be good: this might exist but I haven't found it yet. thanks david jencks Geronimo Configs :: Welcome app Jetty 8 : (2.1-SNAPSHOT) Geronimo Configs :: Unavailable Client Deployer 9 : (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer 11: (2.1-SNAPSHOT) Geronimo Configs :: Shared Library 12: (2.1-SNAPSHOT) Geronimo Configs :: System Database 13: (2.1-SNAPSHOT) Geronimo Configs :: Application Client Deployments 14: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client transaction 15: (2.1-SNAPSHOT) Geronimo Configs :: CLI Upgrade 16: (2.1-SNAPSHOT) Geronimo Configs :: Unavailable EJB Deployer 17: (2.1-SNAPSHOT) Geronimo Configs :: Plan Upgrade 20: (2.1-SNAPSHOT) Geronimo Configs :: Shutdown 21: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 JAR Configurer 23: (2.1-SNAPSHOT) Geronimo Configs :: Welcome app Tomcat 24: (2.1-SNAPSHOT) Geronimo Configs :: Corba J2EE Client 25: (2.1-SNAPSHOT) Geronimo Configs :: Client System 26: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 EAR Configurer 27: (2.1-SNAPSHOT) Geronimo Configs :: GBean Deployer Boostrap version 28: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 DeploymentFactory 29: (2.1-SNAPSHOT) Geronimo Configs :: Servlet Examples for Tomcat 33: (2.1-SNAPSHOT) Geronimo Configs :: JSR88 CLI 34: (2.1-SNAPSHOT) Geronimo Configs :: J2EE Client 35: (2.1-SNAPSHOT
