GUI Tool For Restricted Environment
Hello, We intend to run activemq 4.1 on a shared hosting (linux) environment that does not support a servlet engine. Jserv is disabled on apache, however the environment does support Java JDK 1.5. Is there any JMS tool like (web console and hermes jms) that we can run in such an environment to manage activemq? Thanks -- View this message in context: http://www.nabble.com/GUI-Tool-For-Restricted-Environment-tf2762266.html#a7701189 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Resolved: (SM-769) Authorization entries should be defined per operation
[ https://issues.apache.org/activemq/browse/SM-769?page=all ] Guillaume Nodet resolved SM-769. Resolution: Fixed Author: gnodet Date: Tue Dec 5 16:25:31 2006 New Revision: 482842 URL: http://svn.apache.org/viewvc?view=revrev=482842 Log: SM-769: Authorization entries should be defined per operation Modified: incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/SecuredBroker.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/acl/AuthorizationMap.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/acl/impl/AuthorizationEntry.java incubator/servicemix/trunk/core/servicemix-core/src/main/java/org/apache/servicemix/jbi/security/acl/impl/DefaultAuthorizationMap.java Authorization entries should be defined per operation - Key: SM-769 URL: https://issues.apache.org/activemq/browse/SM-769 Project: ServiceMix Issue Type: Improvement Components: servicemix-core Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Problem compiling javamail code?
Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? Jason
Re: Problem compiling javamail code?
On Dec 5, 2006, at 12:07 AM, Jason Warner wrote: Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/ trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? cat file you think you modifed will tell you pretty quickly if eclipse actually saved your changes where you think it did. It sounds to me as if eclipse is working on different files than maven, or is not saving anything. thanks david jencks Jason
[jira] Commented: (GERONIMO-2624) Offline deployer busted
[ http://issues.apache.org/jira/browse/GERONIMO-2624?page=comments#action_1244 ] David Jencks commented on GERONIMO-2624: I believe this is fixed in trunk rev 482553 and branches/1.2 rev 482554. The offline deployer actually deploys daytrader in 1.2, but there is an additional problem in trunk. Anyone want to write a funcational test for this? Offline deployer busted --- Key: GERONIMO-2624 URL: http://issues.apache.org/jira/browse/GERONIMO-2624 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 2.0 There seems to be at least 2 problems: 1. geronimo-deployment jar should not be in lib 2. list of offline-deployers is really out of date. 3. we don't have any functional tests to detect when it breaks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=all ] David Jencks reassigned GERONIMO-2583: -- Assignee: David Jencks java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Assigned To: David Jencks Priority: Blocker Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-188) Entity instance caching
[ http://issues.apache.org/jira/browse/GERONIMO-188?page=comments#action_12455562 ] Vamsavardhana Reddy commented on GERONIMO-188: -- Anything happening on this JIRA? It is one year to date since anyone had any comments!! Entity instance caching --- Key: GERONIMO-188 URL: http://issues.apache.org/jira/browse/GERONIMO-188 Project: Geronimo Issue Type: Task Components: OpenEJB Affects Versions: 1.0-M1 Reporter: Dain Sundstrom Assigned To: Gianny Damour Fix For: 1.x OpenEJB 2.0M1 does not cache entity instances between method calls. This was useful to test entity life-cycle, but needs to be added for server efficiency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Unable to find jetty 5.1.12
I'm getting an unresolved dependency on the current 1.2 branch for Jetty 5.1.12. I haven't had any luck locating this artifact. Is there someplace I can download it manually? Rick
[jira] Closed: (GERONIMO-282) servlet calls ejb: class not found at deployment and run time
[ http://issues.apache.org/jira/browse/GERONIMO-282?page=all ] Vamsavardhana Reddy closed GERONIMO-282. Resolution: Fixed From the comments, it looks like this issue is resolved. Reopen if it is still a problem. servlet calls ejb: class not found at deployment and run time --- Key: GERONIMO-282 URL: http://issues.apache.org/jira/browse/GERONIMO-282 Project: Geronimo Issue Type: Bug Components: web Affects Versions: 1.0-M2 Environment: fedora core 2 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05) Reporter: toby cabot Fix For: 1.x I'm trying to deploy a servlet that calls an EJB. I can deploy the EJB and call if from a command-line Java client, so I think that part works, thanks to the dev list for help with JNDI. I did the usual stuff in the servlet, but when I add ejb-ref ejb-ref-nameg6o/SSEJB/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homeg6o.ejbclient.StatelessSessionHome/home remoteg6o.ejbclient.StatelessSession/remote /ejb-ref to web.xml I get a stack trace when I run the deploy tool. org.apache.geronimo.deployment.DeploymentException: Remote interface class not found: g6o.ejbclient.StatelessSession at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureInterface(JettyModuleBuilder.java:593) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.assureEJBObjectInterface(JettyModuleBuilder.java:573) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addEJBRefs(JettyModuleBuilder.java:491) etc... I've got the EJB interfaces in a jar in the war file's WEB-INF/lib directory, but I also tried putting the jar with the EJB interfaces in geronimo's lib directory with the same result. Copying my ejb client jar to geronimo's repository and adding an element to geronimo-jetty.xml: dependency urig6o-ejb-client.jar/uri /dependency ...allows the deployment to get farther, but then I get a message about how references that aren't ejb-link are not implemented, so I cut the ejb-ref element out of web.xml to make the deployment work, and when my servlet tries to look up the EJB I get: 13:19:22,715 ERROR [Daemon] Exception caught during kernel configuration, starting kernel shutdown org.apache.geronimo.kernel.config.InvalidConfigException: Invalid GBean configuration for geronimo.config:name=g6o/web at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:274) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:146) Caused by: javax.servlet.ServletException: Naming exception in servlet init: Cannot lookup /g6o/SSEJB: Received error: Error while communicating with server: ; nested exception is: java.rmi.RemoteException: Cannot read the response from the server. The class for an object being returned is not located in this system:; nested exception is: java.lang.ClassNotFoundException: g6o.ejbclient.StatelessSessionHome at g6o.servlet.Servlet.init(Servlet.java:64) at org.mortbay.jetty.servlet.ServletHolder.start(ServletHolder.java:226) at org.mortbay.jetty.servlet.ServletHandler.initializeServlets(ServletHandler.java:390) at org.mortbay.jetty.servlet.WebApplicationHandler.initializeServlets(WebApplicationHandler.java:287) at org.mortbay.jetty.servlet.WebApplicationContext.start(WebApplicationContext.java:421) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:198) at org.apache.geronimo.gbean.jmx.GBeanMBean.doStart(GBeanMBean.java:593) at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:479) at
Re: Unable to find jetty 5.1.12
I have a successful build of branches\1.2. Build completed a few minutes ago. I can send you the jetty jar if you want me to. --vamsi On 12/5/06, Rick McGuire [EMAIL PROTECTED] wrote: I'm getting an unresolved dependency on the current 1.2 branch for Jetty 5.1.12. I haven't had any luck locating this artifact. Is there someplace I can download it manually? Rick
[jira] Closed: (GERONIMO-188) Entity instance caching
[ http://issues.apache.org/jira/browse/GERONIMO-188?page=all ] Gianny Damour closed GERONIMO-188. -- Fix Version/s: 1.1.1 (was: 1.x) Resolution: Fixed Thanks for this reminder Vamsi. This feature has been added some while back. Entity instance caching --- Key: GERONIMO-188 URL: http://issues.apache.org/jira/browse/GERONIMO-188 Project: Geronimo Issue Type: Task Components: OpenEJB Affects Versions: 1.0-M1 Reporter: Dain Sundstrom Assigned To: Gianny Damour Fix For: 1.1.1 OpenEJB 2.0M1 does not cache entity instances between method calls. This was useful to test entity life-cycle, but needs to be added for server efficiency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-411) Add Hash Password Rewrite to File Realm
[
http://issues.apache.org/jira/browse/GERONIMO-411?page=comments#action_12455584
]
Vamsavardhana Reddy commented on GERONIMO-411:
--
Now that PropertiesFileLoginModule and SQLLoginModule support a digest option
(See GERONIMO-1880), is this Hash Password Rewrite feature required?
Add Hash Password Rewrite to File Realm
---
Key: GERONIMO-411
URL: http://issues.apache.org/jira/browse/GERONIMO-411
Project: Geronimo
Issue Type: Improvement
Components: security
Affects Versions: 1.0-M2
Reporter: Aaron Mulder
Priority: Minor
Fix For: Wish List
It would be nice if the properties file realm could rewrite your properties
file with hashed passwords when it reads it. We would need to be able to
recognize hashed vs. unhashed entries and perhaps even different algorithms.
Perhaps it could go like this:
user1=plaintext
user2=MD5{...}
user3=SHA1{...}
Anyway, the idea is that this could be a reasonably secure alternative, but
you still wouldn't need to manually hash things to add or update entries --
just put a plain text entry in and the next time the server reads the file it
would hash it for you.
I guess we'd need to synchronize on the hash operation to avoid threading
problems if multiple apps or whatever use the same properties file, but it
shouldn't be bad if we only rewrite the file if we find any plain text
entries.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1367) Shutdown JAR should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1367?page=all ] Vamsavardhana Reddy updated GERONIMO-1367: -- Priority: Minor (was: Critical) Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown, usability Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: Wish List Attachments: GERONIMO-1367.patch It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1389) About and Logout icons on top of console not visible without lots of scrolling to the right on server logs page
[ http://issues.apache.org/jira/browse/GERONIMO-1389?page=all ] Vamsavardhana Reddy closed GERONIMO-1389. - Resolution: Duplicate GERONIMO-2613 includes this and more. About and Logout icons on top of console not visible without lots of scrolling to the right on server logs page --- Key: GERONIMO-1389 URL: http://issues.apache.org/jira/browse/GERONIMO-1389 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, usability Affects Versions: 1.0 Reporter: John Sisson Priority: Minor Fix For: Wish List I viewed the server logs in the console and found that due to the long entries in the Web Access Log Viewer the About and Logout icons were not visible without me scrolling pages to the right. Would it be possible to have the top of the screen where the Geronimo logo and the About and Logout icons are fixed and the screen below it scrollable so the About and Logout icons are always visible? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQCPP-22) Use common name for ActiveMQ C++ library on Windows and Linux
Use common name for ActiveMQ C++ library on Windows and Linux - Key: AMQCPP-22 URL: https://issues.apache.org/activemq/browse/AMQCPP-22 Project: ActiveMQ C++ Client Issue Type: Bug Affects Versions: 1.1 Reporter: Albert Strasheim Assigned To: Nathan Mittler We're using SCons to build our application that links against the ActiveMQ-CPP library on Windows and Linux. The Visual Studio files included with ActiveMQ-CPP builds a library called activemq.lib whereas the Linux Autotools build builds a library called libactivemq-cpp.a. SCons takes care of the platform-specific prefix (lib or nothing) and the suffix (.a or .lib), but the base names of the library still differs, i.e. activemq vs activemq-cpp. I think it would make sense to standardise on one library name across all platforms. Personally, I'd go for activemq, but activemq-cpp is fine, as long as it's the same everywhere. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1398) ConnectorGBean is creating an attribute 'address' with value /0.0.0.0
[ http://issues.apache.org/jira/browse/GERONIMO-1398?page=all ] Vamsavardhana Reddy closed GERONIMO-1398. - Resolution: Fixed Examined the return value from connector.getAttribute(address) in ConnectorGBean.getHost(). Do not notice this problem in server built from branches\1.2 rev 482525. Please reopen the issue if the problem still exists. ConnectorGBean is creating an attribute 'address' with value /0.0.0.0 --- Key: GERONIMO-1398 URL: http://issues.apache.org/jira/browse/GERONIMO-1398 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Priority: Minor ConnectorGBean is creating an attribute 'address' with value /0.0.0.0 . This creates bad objectNames for catalina MBeans. This explains the following results viewed via the war attached to G-1293. Note that this happens only for HTTP and HTPPS connector and not for AJP. OK - Number of results: 3 Name: Geronimo:type=Connector,port=8009,address=0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean address: 0.0.0.0 allowTrace: false bufferSize: 2048 emptySessionPath: false enableLookups: false maxPostSize: 2097152 port: 8009 protocol: AJP/1.3 protocolHandlerClassName: org.apache.jk.server.JkCoyoteHandler proxyPort: 0 redirectPort: 443 scheme: http secure: false useBodyEncodingForURI: false xpoweredBy: false Name: Geronimo:type=Connector,port=8443,address=%2F0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean acceptCount: 100 address: /0.0.0.0 algorithm: SunX509 allowTrace: false bufferSize: 2048 clientAuth: false compression: off connectionLinger: -1 connectionTimeout: 6 connectionUploadTimeout: 30 disableUploadTimeout: true emptySessionPath: false enableLookups: false keystoreFile: D:\anita\geronimo\geronimom6\geronimo-1.0\var\security\keystore keystorePass: secret maxHttpHeaderSize: 8192 maxKeepAliveRequests: 100 maxPostSize: 2097152 maxSpareThreads: 75 maxThreads: 150 minSpareThreads: 25 port: 8443 protocol: HTTP/1.1 protocolHandlerClassName: org.apache.coyote.http11.Http11Protocol proxyPort: 0 redirectPort: 443 scheme: https secure: true sslProtocol: TLS strategy: lf tcpNoDelay: true threadPriority: 5 useBodyEncodingForURI: false xpoweredBy: false Name: Geronimo:type=Connector,port=8080,address=%2F0.0.0.0 modelerType: org.apache.catalina.mbeans.ConnectorMBean acceptCount: 100 address: /0.0.0.0 allowTrace: false bufferSize: 2048 compression: off connectionLinger: -1 connectionTimeout: 2 connectionUploadTimeout: 30 disableUploadTimeout: true emptySessionPath: false enableLookups: false maxHttpHeaderSize: 8192 maxKeepAliveRequests: 100 maxPostSize: 2097152 maxSpareThreads: 75 maxThreads: 150 minSpareThreads: 25 port: 8080 protocol: HTTP/1.1 protocolHandlerClassName: org.apache.coyote.http11.Http11Protocol proxyPort: 0 redirectPort: 443 scheme: http secure: false strategy: lf tcpNoDelay: true threadPriority: 5 useBodyEncodingForURI: false xpoweredBy: false -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1427) Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction
[ http://issues.apache.org/jira/browse/GERONIMO-1427?page=comments#action_12455627 ] Vamsavardhana Reddy commented on GERONIMO-1427: --- Now that we have minimal assemblies, can this issue be closed? Create a stripped down assembly that includes ActiveMQ, Derby, Jetty/Tomcat and transaction --- Key: GERONIMO-1427 URL: http://issues.apache.org/jira/browse/GERONIMO-1427 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: general Affects Versions: 1.2 Reporter: Bruce Snyder Attachments: separate-openejb-2.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2221) java.lang.ClassCastException while installing Servlet Examples because of Checksum file not found
[
http://issues.apache.org/jira/browse/GERONIMO-2221?page=comments#action_12455636
]
Gianny Damour commented on GERONIMO-2221:
-
I am worried that backward compatibility of configuration serialization is
still not properly working: the CAR is a 1.0 one and the server is a
1.2-SNAPSHOT one. I will build the 1.1.1 branch and install one of its
configuration into a 1.2-SNAPSHOT server to try to reproduce.
java.lang.ClassCastException while installing Servlet Examples because of
Checksum file not found
-
Key: GERONIMO-2221
URL: http://issues.apache.org/jira/browse/GERONIMO-2221
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: sample apps, web
Affects Versions: 1.2
Environment: cygwin, java 1.4, Revision: 424964
Reporter: Jacek Laskowski
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.ConfigurationStore$$EnhancerByCGLIB$$a45644d1.loadConfiguration(generated)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.system.plugin.PluginInstaller$$EnhancerByCGLIB$$72bbc85c.install(generated)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doInstall(AbsentSampleServlet.java:72)
at
org.apache.geronimo.welcome.AbsentSampleServlet.doGet(AbsentSampleServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
[jira] Created: (GERONIMO-2625) Geronimo Console: login page prevents using username, password longer than 25 characters for login
Geronimo Console: login page prevents using username, password longer than 25 characters for login -- Key: GERONIMO-2625 URL: http://issues.apache.org/jira/browse/GERONIMO-2625 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.0, 1.1.2, 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Console login.jsp prevents using username, password longer than 25 characters for login. This is due to the maxlength attribute in the input tags for username and passwords. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1088) TransactionContext class cast exception
TransactionContext class cast exception
---
Key: AMQ-1088
URL: https://issues.apache.org/activemq/browse/AMQ-1088
Project: ActiveMQ
Issue Type: Bug
Components: Connector
Affects Versions: 4.0.1
Environment: XP - jre 1.4
Reporter: Mary Nicholas
Priority: Minor
The class org.apache.activemq.TransactionContext throws a class cast exception
on the recover(int flag) method on the line (or at least it does with jdk1.4)
return (XATransactionId[]) receipt.getData();
It cannot cast the list of DataStructure[] to XATransactionId[]. I just
unpacked it locally as a fix (as seen below) and it worked fine. Have not
checked it in though in case others with more experience on this one disagree.
DataStructure[] x = receipt.getData();
if (x.length 0)
{
XATransactionId xaId[] = new XATransactionId[x.length];
int count = 0;
for (count =0; count x.length; count++)
xaId[count] = (XATransactionId)x[count];
return xaId;
}
else
return null;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2625) Geronimo Console: login page prevents using username, password longer than 25 characters for login
[ http://issues.apache.org/jira/browse/GERONIMO-2625?page=all ] Vamsavardhana Reddy closed GERONIMO-2625. - Resolution: Fixed Removed the maxlength attribute in the username and password form input tags in login.jsp. Fixed in rev 482669 (branches\1.1), rev 482672 (branches\1.2) and rev 482673 (trunk). Geronimo Console: login page prevents using username, password longer than 25 characters for login -- Key: GERONIMO-2625 URL: http://issues.apache.org/jira/browse/GERONIMO-2625 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.0, 1.1.2, 1.2, 2.0 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Console login.jsp prevents using username, password longer than 25 characters for login. This is due to the maxlength attribute in the input tags for username and passwords. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SNAPSHOT - Revision #
Once again Kevan beat me on the reply ( man, don't you stop for dinner !? ;-) ) Jason, I don't get why you think this is so bad. I'm talking about tweaking my local copy so I can make the doc look closer to the final Geronimo release. If some areas change later on, that's fine, I'm expecting so. But that would be just a very few areas, or you think the whole console and commands will change from now on until the final cut is released? In addition, there are some already reported bugs in the console and I will have to revisit those areas either way. I'm just trying to keep the revisiting to a minimum and save some time. This is what I originally asked help for. snip is there a way I could locally get rid of the SNAPSHOT or the revision number? It will really save me a lot of time with the Geronimo v1.2 documentation. /snip If there is no way to do it locally due to external dependencies, then fine, I can't, end of story. I'll need to find another way to get a similar result. With that said, I'm about try Kevan's suggestion on tweaking the pom.xml and see how it goes. Cheers! Hernan Kevan Miller wrote: On Dec 4, 2006, at 4:56 PM, Jason Dillon wrote: is this all for web console shots? If so, then update the console to make that configurable. But if its for build shorts, like capturing what mvn spits out, then I think that its be a very bad idea to change the project version just for a screen shot. Actually I think its a waste of time to even bother with the property thing, but if its low impact, and does not add any more burden/overhead for the normal build/release, then I think its fine. Jason, Hernan wants to create 1.2 documentation. He wants that documentation to be as close to the the actual user experience as he can. I think that is *fantastic*. And I think we could give him a bit of support in his efforts. Here's how it could work: 1) Hernan could make a private update to his pom.xml and build a preview of 1.2. There may be a few stumbling blocks, here. Hard-coded versions, OpenEJB dependencies, etc. 2) Hernan uses this preview build to generate reasonably accurate screenshots. No code is checked into svn. No artifacts are deployed to maven repos. I assume that Hernan's m2 repo/build environment will not build 1.2-SNAPSHOT properly after that. So, when Hernan is done, he wipes out his build tree and maven repo (or geronimo sections of his repo) and reverts back to 1.2-SNAPSHOT. What's so bad about all that? I'm certainly willing to lend Hernan a hand to get his environment up and running. I would hope that others involved with the 1.2 release might actually want to help him out too... --kevan
Re: Problem compiling javamail code?
That is a thought I had and I just checked again to confirm that I was editing the right files and that they were getting saved. I probably should have mentioned that it did work for a while, which I thought was odd. It reached a certain point though when the changes stopped taking effect after compiling. On 12/5/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 12:07 AM, Jason Warner wrote: Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/ trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? cat file you think you modifed will tell you pretty quickly if eclipse actually saved your changes where you think it did. It sounds to me as if eclipse is working on different files than maven, or is not saving anything. thanks david jencks Jason
Re: publishing snapshots
On 12/4/06, Jason Dillon [EMAIL PROTECTED] wrote: Seem fairly obvious to me if you are creating a new module, copied from another or not, that you should always change the version, name, artifactId of the module. thanks for the peer review. Anyways... if these were only published as snaps, then I would remove the artifacts from the m2-snapshot-repository, update the poms with 1.0-SNAPSHOT, update deps, and then redeploy. done. glad you caught this in time for an easy redeploy. I still recommend using one version for all specs though... then all this version muck basically goes away. This may be more and more important as I get more stuff automated, as its not really easy to ensure that code put into specs will actually be used by a dependency project. So its hard to say if specs/trunk is compatible with server/ trunk with any degree of certainty... I would normally expect that they would be compatible... but Maven's remote repo/dependency muck (plague in disguise) really does more to promote build instability than to allow codeline consistency. I definitely see your point. I think we'll have a new opportunity to address these issues in geronimo 2.0. As I recall don't we already have the votes in hand to reversion the specs tree as you prefer?. (I hope I'm not accidentally whacking a hornet's nest) Best wishes, Paul
Re: SVK
Good info--Thanks Jason Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: [jira] Commented: (SM-751) Flow tracing with correlation id
Guillaume Nodet (JIRA) wrote: [ https://issues.apache.org/activemq/browse/SM-751?page=comments#action_37501 ] Guillaume Nodet commented on SM-751: Btw, looking at the patch, I was wondering if it would be interesting to have a multi-level correlationId, so that we could trace the exchange to its parent exchange and from the parent to the grand-parent and so forth... Hi, Sorry to drag out an old email, but I was wondering if the proposition above made it into the code ? It would be quite useful to have ... (as I see it when a new correlationid is added into the properties of an exchange which already has one, another property records the parentcorrelationid ... ) ? thanks, Roger Flow tracing with correlation id Key: SM-751 URL: https://issues.apache.org/activemq/browse/SM-751 Project: ServiceMix Issue Type: Improvement Reporter: Gianfranco Boccalon Attachments: servicemix-components.zip Add the possibility to trace the flow of the messages inside a Service Assembly. For example, if we have a Service Assembly composed of three components, two binding components (call them BC1 and BC2) and a service engine (SE) organized in this sequence BC1-SE-BC2, we need to recognize that the output messages produced by the SE component are related to some messages provided by BC1. To do this, we need to add a process correlation id to the message exchanges and to modify the used components, to propagate this correlation id in all Message Exchanges sent. Enclosed there is the modified code for the following components: - HTTP binding component: here I added the code to generate the correlation Id and set it in the Message Exchange - Splitter - Router (the lightweight component)
Re: Problem compiling javamail code?
May be there are some jars in the repo that are being used at assembly time instead of the jars created when you build javamail. Why don't you remove the corresponding jars from the repo and build javamail afresh and then G. --vamsi On 12/5/06, Jason Warner [EMAIL PROTECTED] wrote: That is a thought I had and I just checked again to confirm that I was editing the right files and that they were getting saved. I probably should have mentioned that it did work for a while, which I thought was odd. It reached a certain point though when the changes stopped taking effect after compiling. On 12/5/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 12:07 AM, Jason Warner wrote: Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/ trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? cat file you think you modifed will tell you pretty quickly if eclipse actually saved your changes where you think it did. It sounds to me as if eclipse is working on different files than maven, or is not saving anything. thanks david jencks Jason
[jira] Created: (GERONIMO-2626) Building geronimo-kernel leaves 46 files in java.io.tmpdir
Building geronimo-kernel leaves 46 files in java.io.tmpdir -- Key: GERONIMO-2626 URL: http://issues.apache.org/jira/browse/GERONIMO-2626 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2, 2.0 Environment: win xp Reporter: Anita Kulshreshtha Priority: Minor Building of geronimo-kernel leaves behind 47 files named test-n-n.jar in java.io.tmpdir. This problem might be specific to windows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1496) purge the dependency of cookie for admin console login
[ http://issues.apache.org/jira/browse/GERONIMO-1496?page=comments#action_12455674 ] Vamsavardhana Reddy commented on GERONIMO-1496: --- I really don't understand what this JIRA is about. Can someone please explain? Thanks. purge the dependency of cookie for admin console login -- Key: GERONIMO-1496 URL: http://issues.apache.org/jira/browse/GERONIMO-1496 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Gao Yong Pan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in cxf module
I am having same problem outside the netbeans. To me it looks like there
there is some problem with CXF module's pom file. I expext to see all the
dependecies that you have listed below in it, if it referencing. don' t you
think?
Thanks
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Seems more like netbeans settings to me.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED] wrote:
I agree, there must be something wrong in my settings. I got the code
from
trunk and using maven to compile (from netbeans). Could it be maven
settings?? thanks for all your help.
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Even though you manually installed the 2 cxf artifacts, you are
missing a lot of transitive dependencies that these artifacts should
have brought. I suspect something is wrong with your settings that it
is failing to download snapshots and their transitive deps.
Here are the other artifacts in the repo under the groupId
org.apache.cxf
cxf
cxf-api
cxf-common
cxf-common-metacode
cxf-common-schemas
cxf-common-utilities
cxf-metacode
cxf-rt
cxf-rt-bindings
cxf-rt-bindings-soap
cxf-rt-bindings-xml
cxf-rt-core
cxf-rt-databinding-jaxb
cxf-rt-frontend-jaxws
cxf-rt-frontend-simple
cxf-rt-transports-http
cxf-tools
cxf-tools-common
I believe you will be missing quite a few of these.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED] wrote:
Got latest code from trunk and tried to compile and getting
compilation
errors in CXF module.
I had to install following dependencies manually:
cxf-rt-frontend-jaxws-2.0-incubator-M1-20061110.143844-5.jar
cxf-rt-transports-http-2.0-incubator-M1-20061110.143844-5.jar
Any help is appreciated.
-Apparao Kalimireddy
Here is a partial trace of the errors:
[INFO]
[ERROR]BUILD FAILURE
[INFO]
[INFO]Compilation failure
C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[23,22]
package org.apache.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[24,30]
package org.apache.cxf.bus.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[37,18]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.CXFWebServiceContainerFactoryGBean
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[5,36]
package org.apache.cxf.configuration does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[6,36]
package org.apache.cxf.service.model does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[7,32]
package org.apache.cxf.transport does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[9,22]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: package org.apache.cxf
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[11,7]
cannot access org.apache.cxf.transport.ConduitInitiator
[INFO]file
org\apache\cxf\transport\ConduitInitiator.class
not found
[INFO]public class GeronimoDestinationFactory extends
HTTPTransportFactory {
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[13,38]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[18,38]
cannot find symbol
[INFO]symbol : class EndpointInfo
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[18,11]
cannot find symbol
[INFO]symbol : class Destination
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainer.java:[4,34]
package org.apache.cxf.binding.xml does not exist
[INFO]
Re: [jira] Commented: (SM-751) Flow tracing with correlation id
On 12/5/06, Roger Menday [EMAIL PROTECTED] wrote: Guillaume Nodet (JIRA) wrote: [ https://issues.apache.org/activemq/browse/SM-751?page=comments#action_37501 ] Guillaume Nodet commented on SM-751: Btw, looking at the patch, I was wondering if it would be interesting to have a multi-level correlationId, so that we could trace the exchange to its parent exchange and from the parent to the grand-parent and so forth... Hi, Sorry to drag out an old email, but I was wondering if the proposition above made it into the code ? It would be quite useful to have ... (as I see it when a new correlationid is added into the properties of an exchange which already has one, another property records the parentcorrelationid ... ) Not yet. Would you mind raising another issue for that ? If you have any time to write a patch ... ;) ? thanks, Roger Flow tracing with correlation id Key: SM-751 URL: https://issues.apache.org/activemq/browse/SM-751 Project: ServiceMix Issue Type: Improvement Reporter: Gianfranco Boccalon Attachments: servicemix-components.zip Add the possibility to trace the flow of the messages inside a Service Assembly. For example, if we have a Service Assembly composed of three components, two binding components (call them BC1 and BC2) and a service engine (SE) organized in this sequence BC1-SE-BC2, we need to recognize that the output messages produced by the SE component are related to some messages provided by BC1. To do this, we need to add a process correlation id to the message exchanges and to modify the used components, to propagate this correlation id in all Message Exchanges sent. Enclosed there is the modified code for the following components: - HTTP binding component: here I added the code to generate the correlation Id and set it in the Message Exchange - Splitter - Router (the lightweight component) -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-1501) Daytrader: remove hardcoded dependency versions in project.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1501?page=comments#action_12455678 ] Vamsavardhana Reddy commented on GERONIMO-1501: --- I think this JIRA should actually belong to http://issues.apache.org/jira/browse/DAYTRADER. Daytrader: remove hardcoded dependency versions in project.xml --- Key: GERONIMO-1501 URL: http://issues.apache.org/jira/browse/GERONIMO-1501 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Environment: winxp Reporter: Lin Sun Priority: Minor Attachments: G1501-ejb.patch, G1501-streamer.patch, G1501-web.patch, G1501-wsappclient.patch In daytrader, there are quite a few places that have hardcoded dependency projects' version number in project.xml. They can be replaced with the versions specified in etc/project.properties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1499) Daytrader: uncomment the drop table statements in daytrader.sql
[ http://issues.apache.org/jira/browse/GERONIMO-1499?page=comments#action_12455680 ] Vamsavardhana Reddy commented on GERONIMO-1499: --- I think this JIRA should actually belong to http://issues.apache.org/jira/browse/DAYTRADER. Daytrader: uncomment the drop table statements in daytrader.sql Key: GERONIMO-1499 URL: http://issues.apache.org/jira/browse/GERONIMO-1499 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Environment: winxp, Reporter: Lin Sun Priority: Minor Attachments: G1499-daytrader-sql.patch If the daytrader.sql is executed the 2nd time, you will see many errors like index already exisited...because the tables are not dropped.I think it is better to uncomment the drop table statements in daytrader/derby/src/sql/daytrader.sql. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 2.0 Milestone's and how were doing
Matt, JEE5 is critical to the widespread adoption of Geronimo. We can and should accomplish these milestones. Best wishes, Paul On 12/4/06, Matt Hogstrom [EMAIL PROTECTED] wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Compilation errors in cxf module
Apparao,
I was able to build cxf module rev. 482652 this morning. You could
try deleting .m2\repository\org\apache\cxf directory and building from
a command shell.
Thanks
Anita
--- Apparao Kalimireddy [EMAIL PROTECTED] wrote:
I am having same problem outside the netbeans. To me it looks like
there
there is some problem with CXF module's pom file. I expext to see all
the
dependecies that you have listed below in it, if it referencing. don'
t you
think?
Thanks
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Seems more like netbeans settings to me.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED]
wrote:
I agree, there must be something wrong in my settings. I got the
code
from
trunk and using maven to compile (from netbeans). Could it be
maven
settings?? thanks for all your help.
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Even though you manually installed the 2 cxf artifacts, you are
missing a lot of transitive dependencies that these artifacts
should
have brought. I suspect something is wrong with your settings
that it
is failing to download snapshots and their transitive deps.
Here are the other artifacts in the repo under the groupId
org.apache.cxf
cxf
cxf-api
cxf-common
cxf-common-metacode
cxf-common-schemas
cxf-common-utilities
cxf-metacode
cxf-rt
cxf-rt-bindings
cxf-rt-bindings-soap
cxf-rt-bindings-xml
cxf-rt-core
cxf-rt-databinding-jaxb
cxf-rt-frontend-jaxws
cxf-rt-frontend-simple
cxf-rt-transports-http
cxf-tools
cxf-tools-common
I believe you will be missing quite a few of these.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED]
wrote:
Got latest code from trunk and tried to compile and getting
compilation
errors in CXF module.
I had to install following dependencies manually:
cxf-rt-frontend-jaxws-2.0-incubator-M1-20061110.143844-5.jar
cxf-rt-transports-http-2.0-incubator-M1-20061110.143844-5.jar
Any help is appreciated.
-Apparao Kalimireddy
Here is a partial trace of the errors:
[INFO]
[ERROR]BUILD FAILURE
[INFO]
[INFO]Compilation failure
C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[23,22]
package org.apache.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[24,30]
package org.apache.cxf.bus.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[37,18]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.CXFWebServiceContainerFactoryGBean
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[5,36]
package org.apache.cxf.configuration does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[6,36]
package org.apache.cxf.service.model does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[7,32]
package org.apache.cxf.transport does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[9,22]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: package org.apache.cxf
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[11,7]
cannot access org.apache.cxf.transport.ConduitInitiator
[INFO]file
org\apache\cxf\transport\ConduitInitiator.class
not found
[INFO]public class GeronimoDestinationFactory extends
HTTPTransportFactory {
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[13,38]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[18,38]
cannot find symbol
[INFO]symbol : class EndpointInfo
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
Re: Compilation errors in cxf module
No. Those come by way of maven transitive dependencies.
I was able to build cxf from scratch now (on command line).
Cheers
Prasad
On 12/5/06, Apparao Kalimireddy [EMAIL PROTECTED] wrote:
I am having same problem outside the netbeans. To me it looks like there
there is some problem with CXF module's pom file. I expext to see all the
dependecies that you have listed below in it, if it referencing. don' t you
think?
Thanks
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Seems more like netbeans settings to me.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED] wrote:
I agree, there must be something wrong in my settings. I got the code
from
trunk and using maven to compile (from netbeans). Could it be maven
settings?? thanks for all your help.
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Even though you manually installed the 2 cxf artifacts, you are
missing a lot of transitive dependencies that these artifacts should
have brought. I suspect something is wrong with your settings that it
is failing to download snapshots and their transitive deps.
Here are the other artifacts in the repo under the groupId
org.apache.cxf
cxf
cxf-api
cxf-common
cxf-common-metacode
cxf-common-schemas
cxf-common-utilities
cxf-metacode
cxf-rt
cxf-rt-bindings
cxf-rt-bindings-soap
cxf-rt-bindings-xml
cxf-rt-core
cxf-rt-databinding-jaxb
cxf-rt-frontend-jaxws
cxf-rt-frontend-simple
cxf-rt-transports-http
cxf-tools
cxf-tools-common
I believe you will be missing quite a few of these.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED] wrote:
Got latest code from trunk and tried to compile and getting
compilation
errors in CXF module.
I had to install following dependencies manually:
cxf-rt-frontend-jaxws-2.0-incubator-M1-20061110.143844-5.jar
cxf-rt-transports-http-2.0-incubator-M1-20061110.143844-5.jar
Any help is appreciated.
-Apparao Kalimireddy
Here is a partial trace of the errors:
[INFO]
[ERROR]BUILD FAILURE
[INFO]
[INFO]Compilation failure
C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[23,22]
package org.apache.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[24,30]
package org.apache.cxf.bus.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[37,18]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.CXFWebServiceContainerFactoryGBean
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[5,36]
package org.apache.cxf.configuration does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[6,36]
package org.apache.cxf.service.model does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[7,32]
package org.apache.cxf.transport does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[9,22]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: package org.apache.cxf
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[11,7]
cannot access
org.apache.cxf.transport.ConduitInitiator
[INFO]file
org\apache\cxf\transport\ConduitInitiator.class
not found
[INFO]public class GeronimoDestinationFactory extends
HTTPTransportFactory {
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[13,38]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[18,38]
cannot find symbol
[INFO]symbol : class EndpointInfo
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[18,11]
cannot find symbol
[INFO]symbol : class Destination
[INFO]location: class
Re: Geronimo 2.0 Milestone's and how were doing
I saw the charts and the timeline looks a bit aggressive but feasible. I personally work better if I know when and what we are shooting for; personally, I like the challenge. It would be great if we manage to release a JEE5 milestone before the end of the year, it will give G a big push in the right direction - Release Early, Release Often with the features the users want. Are you planning to put a breakdown roadmap on the wiki? Cheers! Hernan Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Compilation errors in cxf module
Yes it worked. Deleting .m2\repository\org\apache\cxf directory solved the
problem.
Thanks a lot.
On 12/5/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
Apparao,
I was able to build cxf module rev. 482652 this morning. You could
try deleting .m2\repository\org\apache\cxf directory and building from
a command shell.
Thanks
Anita
--- Apparao Kalimireddy [EMAIL PROTECTED] wrote:
I am having same problem outside the netbeans. To me it looks like
there
there is some problem with CXF module's pom file. I expext to see all
the
dependecies that you have listed below in it, if it referencing. don'
t you
think?
Thanks
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Seems more like netbeans settings to me.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED]
wrote:
I agree, there must be something wrong in my settings. I got the
code
from
trunk and using maven to compile (from netbeans). Could it be
maven
settings?? thanks for all your help.
On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote:
Even though you manually installed the 2 cxf artifacts, you are
missing a lot of transitive dependencies that these artifacts
should
have brought. I suspect something is wrong with your settings
that it
is failing to download snapshots and their transitive deps.
Here are the other artifacts in the repo under the groupId
org.apache.cxf
cxf
cxf-api
cxf-common
cxf-common-metacode
cxf-common-schemas
cxf-common-utilities
cxf-metacode
cxf-rt
cxf-rt-bindings
cxf-rt-bindings-soap
cxf-rt-bindings-xml
cxf-rt-core
cxf-rt-databinding-jaxb
cxf-rt-frontend-jaxws
cxf-rt-frontend-simple
cxf-rt-transports-http
cxf-tools
cxf-tools-common
I believe you will be missing quite a few of these.
Cheers
Prasad
On 12/4/06, Apparao Kalimireddy [EMAIL PROTECTED]
wrote:
Got latest code from trunk and tried to compile and getting
compilation
errors in CXF module.
I had to install following dependencies manually:
cxf-rt-frontend-jaxws-2.0-incubator-M1-20061110.143844-5.jar
cxf-rt-transports-http-2.0-incubator-M1-20061110.143844-5.jar
Any help is appreciated.
-Apparao Kalimireddy
Here is a partial trace of the errors:
[INFO]
[ERROR]BUILD FAILURE
[INFO]
[INFO]Compilation failure
C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[23,22]
package org.apache.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[24,30]
package org.apache.cxf.bus.cxf does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\CXFWebServiceContainerFactoryGBean.java:[37,18]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.CXFWebServiceContainerFactoryGBean
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[5,36]
package org.apache.cxf.configuration does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[6,36]
package org.apache.cxf.service.model does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[7,32]
package org.apache.cxf.transport does not exist
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[9,22]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: package org.apache.cxf
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[11,7]
cannot access org.apache.cxf.transport.ConduitInitiator
[INFO]file
org\apache\cxf\transport\ConduitInitiator.class
not found
[INFO]public class GeronimoDestinationFactory extends
HTTPTransportFactory {
[INFO]
[INFO]C:\geronimo-dev\trunk\modules\geronimo-cxf\src\main\java\org\apache\geronimo\cxf\GeronimoDestinationFactory.java:[13,38]
cannot find symbol
[INFO]symbol : class Bus
[INFO]location: class
org.apache.geronimo.cxf.GeronimoDestinationFactory
[INFO]
[jira] Updated: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy updated GERONIMO-1519:
--
Component/s: specs
Fix Version/s: 1.1.2
1.2
2.0
Affects Version/s: 1.1
1.1.2
1.2
2.0
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1496) purge the dependency of cookie for admin console login
[ http://issues.apache.org/jira/browse/GERONIMO-1496?page=comments#action_12455693 ] David Jencks commented on GERONIMO-1496: I think the problem is that if you turn off cookies in your browser you can't log into the admin console. I really don't know how practical it is to put the sessionId in the really long complicated urls the portal generates, but it might be worth trying. purge the dependency of cookie for admin console login -- Key: GERONIMO-1496 URL: http://issues.apache.org/jira/browse/GERONIMO-1496 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Gao Yong Pan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy reassigned GERONIMO-1519:
-
Assignee: Vamsavardhana Reddy
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Assigned To: Vamsavardhana Reddy
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 4, 2006, at 10:54 AM, Matt Hogstrom wrote: If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. Cool. I've only merged license/notice information from branches/1.2 onto trunk. I haven't reviewed the trunk-unique dependencies. I'll get that done in time for the beta... Paul, Tomcat integration might have the most work to do for M1. How is that looking? Would be good to create proposed M1 release notes. This might drive some good discussion to insure we feel good about the proposal... --kevan
[jira] Closed: (GERONIMO-1519) ResourceException.toString() can return null
[ http://issues.apache.org/jira/browse/GERONIMO-1519?page=all ]
Vamsavardhana Reddy closed GERONIMO-1519.
-
Resolution: Fixed
Fixes toString() to return non-null string.
Fixed in rev 482713.
ResourceException.toString() can return null
Key: GERONIMO-1519
URL: http://issues.apache.org/jira/browse/GERONIMO-1519
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: connector, specs
Affects Versions: 1.1, 1.1.2, 1.2, 2.0
Reporter: Jörg Heinicke
Assigned To: Vamsavardhana Reddy
Priority: Minor
Fix For: 1.1.2, 1.2, 2.0
javax.resource.ResourceException overwrites toString() like the following:
public String toString() {
return getMessage();
}
Instantiating ResourceException without parameter getMessage() will return
null - and this leads to NPEs in nearly every environment when the stacktrace
is printed:
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:247)
at java.io.PrintWriter.print(PrintWriter.java:392)
at java.io.PrintWriter.println(PrintWriter.java:529)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
So I propose to either remove the toString() implemenation
(java.lang.Throwable implements it correctly) or to implement it correctly in
ResourceException, i.e. not returning null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Problem compiling javamail code?
I gave that a shot too, Vamsi. It didn't work either and after poking around a bit I figured out what is going on but not why. I took a close look at the maven output and found that despite the fact that there were actually changes in the files it was trying to compile, it was indicating that there were none and just went ahead and built the jars using the previously compiled classes. Because of this, none of my changes were making it into the jar. I fixed it by deleting every class file in the directory I had made changes in, thereby forcing it to compile the classes. What I don't understand though is why it would work for a while and then all of the sudden decide that any new changes made don't actually count as changes. Am I missing a step in the build process? Should I be removing the class files before building each time? Thanks for all the help! Jason On 12/5/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: May be there are some jars in the repo that are being used at assembly time instead of the jars created when you build javamail. Why don't you remove the corresponding jars from the repo and build javamail afresh and then G. --vamsi On 12/5/06, Jason Warner [EMAIL PROTECTED] wrote: That is a thought I had and I just checked again to confirm that I was editing the right files and that they were getting saved. I probably should have mentioned that it did work for a while, which I thought was odd. It reached a certain point though when the changes stopped taking effect after compiling. On 12/5/06, David Jencks [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 12:07 AM, Jason Warner wrote: Hey all, In working with the javamail code I've come across a strange issue. It might not be for javamail only, but this is where I am working with the code. I am finding that after I make changes to the code in eclipse and then save, when I run mvn in the javamail/ trunk directory none of my changes seem to be picked up. When I go to run javamail after building, nothing has changed. I have done things that should result in an obvious change such as changing a println statement that is definitely being printed out or changing the functionality of the code such that it should undoubtedly do the change I made but to no avail. Is there something wrong with my build/test process that's resulting in this? I've done an mvn clean on all applicable directories just in case, but that had no effect either. Any suggestions? cat file you think you modifed will tell you pretty quickly if eclipse actually saved your changes where you think it did. It sounds to me as if eclipse is working on different files than maven, or is not saving anything. thanks david jencks Jason
[jira] Commented: (GERONIMO-1534) Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db
[ http://issues.apache.org/jira/browse/GERONIMO-1534?page=comments#action_12455699 ] Vamsavardhana Reddy commented on GERONIMO-1534: --- Does this belong to http://issues.apache.org/jira/browse/DAYTRADER too?? Daytrader: ejb-ql-compiler-factory element is wrong for DB2 or Oracle db - Key: GERONIMO-1534 URL: http://issues.apache.org/jira/browse/GERONIMO-1534 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Environment: WinXP, Reporter: Lin Sun Priority: Minor Attachments: G1534-daytrader.patch In daytrader plan it contains the following ejb-ql-compiler-factory elements: !-- For DB2 database users uncomment the following line. ejb-ql-compiler-factoryorg.tranql.ejbcompiler.DB2EJBQLCompilerFactory/ejb-ql-compiler-factory db-syntax-factoryorg.tranql.sql.db2.DB2DBSyntaxFactory/db-syntax-factory -- If you uncomment the following line and configure daytrader with DB2, you will see a classloader problem when deploying daytrader. This should be changed to ejbqlcompiler instead of ejbcompiler: ejb-ql-compiler-factoryorg.tranql.ejbqlcompiler.DB2EJBQLCompilerFactory/ejb-ql-compiler-factory db-syntax-factoryorg.tranql.sql.db2.DB2DBSyntaxFactory/db-syntax-factory Same problem with Oracle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1594) deployment of a simple (only one jsp) web project failed
[ http://issues.apache.org/jira/browse/GERONIMO-1594?page=all ] Vamsavardhana Reddy updated GERONIMO-1594: -- Fix Version/s: Verification Required deployment of a simple (only one jsp) web project failed Key: GERONIMO-1594 URL: http://issues.apache.org/jira/browse/GERONIMO-1594 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Environment: windows xp SP2 with jsdk 1.4.2_10, geronimo 1.0, eclipse Version: 3.1.1 Build id: M20050929-0840, st 1.0.0, geronimo plugin 1.0.0 (build of 25.01) Reporter: Mark Mauerwerk Fix For: Verification Required following the instructions of the ibm article deployment of a simple (only one jsp) web project failed Despite geronimo management console displays web app as running, my test jsp is not there. I did not found any error message in the console window, but in .log (see below) !ENTRY org.apache.geronimo.devtools.eclipse.core 4 0 2006-02-05 19:16:45.78 !MESSAGE Starting of configuration failed. See .log for details. !STACK 0 java.lang.Exception: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) java.rmi.UnmarshalException: Error unmarshaling return; nested exception is: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source) at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(Unknown Source) at org.apache.geronimo.kernel.jmx.KernelDelegate.invokeKernel(KernelDelegate.java:339) at org.apache.geronimo.kernel.jmx.KernelDelegate.getGBeanState(KernelDelegate.java:121) at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:64) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: org.apache.geronimo.kernel.GBeanNotFoundException (no security manager: RMI class loader disabled) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source) at java.rmi.server.RMIClassLoader.loadClass(Unknown Source) at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source) at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at java.io.ObjectInputStream.readClassDesc(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) ... 9 more at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doFail(GeronimoServerBehaviour.java:352) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:299) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:241) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:225) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:658) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:738) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:596) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:799) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:788) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=all ] Vamsavardhana Reddy closed GERONIMO-1614. - Resolution: Fixed Installer - Console portal servlet fails to load properly after install --- Key: GERONIMO-1614 URL: http://issues.apache.org/jira/browse/GERONIMO-1614 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: installer Affects Versions: 1.2, 1.1 Reporter: erik daughtrey Attachments: installer-console-textline-fix.patch The FixTextLines function fixes all CRLFs in xml and other file types across the Geronimo install tree. Apparently, the version of the Pluto portal being used does not appreciate its XML files being adjusted. The fix will cause FixTextLines to bypass the config-store directory when fixing line endings. Additionally the fix blends in some new error/trace logging functionality which may be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1621) [Daytrader] TradeWSAction class is not a Servlet
[ http://issues.apache.org/jira/browse/GERONIMO-1621?page=all ] Vamsavardhana Reddy closed GERONIMO-1621. - Resolution: Won't Fix Closed as requested by the reporter. One less JIRA to worry about :o) [Daytrader] TradeWSAction class is not a Servlet Key: GERONIMO-1621 URL: http://issues.apache.org/jira/browse/GERONIMO-1621 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Reporter: Vincent Massol When trying to deploy the web/ module to Jetty I'm getting the following error: Servlet class org.apache.geronimo.samples.daytrader.TradeWSAction is not a javax.servlet.Servlet Indeed, looking at the TradeWSAction.java class reveals that it's not a Servlet and thus it shouldn't be declared as a Servlet in web.xml: servlet id=Servlet_30 display-nameorg_apache_geronimo_samples_daytrader_TradeWSAction/display-name servlet-nameorg_apache_geronimo_samples_daytrader_TradeWSAction/servlet-name servlet-classorg.apache.geronimo.samples.daytrader.TradeWSAction/servlet-class /servlet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1652) EJBModuleImpl.getEJBs() always return an empty array
[ http://issues.apache.org/jira/browse/GERONIMO-1652?page=comments#action_12455708 ] Vamsavardhana Reddy commented on GERONIMO-1652: --- Chris, can you take a look at this issue? EJBModuleImpl.getEJBs() always return an empty array Key: GERONIMO-1652 URL: http://issues.apache.org/jira/browse/GERONIMO-1652 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, OpenEJB Affects Versions: 1.2 Reporter: Christopher M. Cardona Attachments: EJBModuleImpl.java Calling EJBModuleImpl.getEJBs() always returns an empty String[] because of a wrong generated query. Here is an example query: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=null,j2eeType=EntityBean,* The correct query should have been: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=daytrader-ejb-1.1-SNAPSHOT.jar,j2eeType=EntityBean,* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 2.0 Milestone's and how were doing
Hi Matt, I agree as well. I'll have the JSF work completed for M1 (to the extent that MyFaces 1.2 is complete) plus the JSR-88 deployment changes for annotations ready for M2. Thanks much Tim Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
[jira] Resolved: (GERONIMO-2612) NPE thrown in console when shutting down server
[ http://issues.apache.org/jira/browse/GERONIMO-2612?page=all ] Hernan Cunico resolved GERONIMO-2612. - Fix Version/s: 1.2 Resolution: Fixed Cannot reproduce this NPE in the new build. Issue fixed. NPE thrown in console when shutting down server --- Key: GERONIMO-2612 URL: http://issues.apache.org/jira/browse/GERONIMO-2612 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Environment: this is for revision r480769 Reporter: Hernan Cunico Fix For: 1.2 On shutdown I get this exception on both Tomcat and Jetty Server shutdown begun 15:33:32,625 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:234) Server shutdown completed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2612) NPE thrown in console when shutting down server
[ http://issues.apache.org/jira/browse/GERONIMO-2612?page=all ] Hernan Cunico closed GERONIMO-2612. --- Cannot reproduce this NPE in the new build. Issue fixed. NPE thrown in console when shutting down server --- Key: GERONIMO-2612 URL: http://issues.apache.org/jira/browse/GERONIMO-2612 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Environment: this is for revision r480769 Reporter: Hernan Cunico Fix For: 1.2 On shutdown I get this exception on both Tomcat and Jetty Server shutdown begun 15:33:32,625 WARN [BasicLifecycleMonitor] Exception occured while notifying listener java.lang.NullPointerException at org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159) at org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireStoppedEvent(BasicLifecycleMonitor.java:259) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:359) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:310) at org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) at org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:234) Server shutdown completed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[DISCUSS] G 2.0 M1 Content
Given that we haven't created milestone releases for a while I wanted to make sure that we had all the bases covered for G 2.0-M1. Here is a list of things that I can think of and would like other's input on what is required. Should we use MN -- Jason posted in another thread about how Mn (I assume you were referring to Milestones) might be confusing for post 1.0 releases. I don't think its confusing as it represents a simple point in time reference of a work in progress but not a full implementation (I think that build would more appropriately be a beta). Alpha release might be appropriate but I'm good with milestone. Other thoughts? Documentation - Need the normal release notes to identify what works and what doesn't. I was talking to Sachin and he indicated that WTP would barf on most of the Java EE 5.0 stuff so that is a reasonable thing to post here. Also, a description of what is included and not would make sense as well. Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) Once we get this together and we can run Daytrader 2.0-SNAPSHOT on it I think we have a content ready milestone. Timeline This is less important than the content. I suggested 12/22 since its the Friday before the Christmas holiday. Personally it would feel good to know we packaged up something and finished it this year towards 2.0. There is a lot of small stuff we already have thats almost done. We've been discussing release early and often so the date is more of an artificial stake in the sand. If we don't get the work done then we don't ship. It largely depends on completing what goes into M1 rather than the date. My personal pattern is to wait until the last minute to get something done. I've done it through grade school, college and professionally. A date motivates me more than a function as I can polish things forever or put off the simple things until the last minute (just ask my wife about the pictures that have been waiting to be hung for months ;-P ) I think the other responses in the status thread are positive to make this happen so hopefully this thread will help flush out the content. Matt Hogstrom [EMAIL PROTECTED]
[jira] Created: (SM-766) Error whit chracters lati n1 when send message in JbiChannel. For example á
Error whit chracters latin1 when send message in JbiChannel. For example á
Key: SM-766
URL: https://issues.apache.org/activemq/browse/SM-766
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0.1
Environment: Windows XP XP2
servicemix 3.0.1
Reporter: Jorge Rodríguez Pedrianes
Hello, in this days i try to use jsr181 componet but i had a problem whith
latin1 characters. I show a example to understad better:
I hava a pojo:public class MyPojo {
public String echo() {
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 5, 2006, at 1:21 PM, Paul McMahan wrote: On 12/5/06, Kevan Miller [EMAIL PROTECTED] wrote: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy =2.4. servlets to. I'm looking at getting DayTrader 2.0-SNAPSHOT running now. Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? Best wishes, Paul Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
On 12/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I'm looking at getting DayTrader 2.0-SNAPSHOT running now. Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? that would be great.
[jira] Commented: (SM-766) Error whit chracters lat in1 when send message in JbiChannel. For example á
[
https://issues.apache.org/activemq/browse/SM-766?page=comments#action_37629 ]
Guillaume Nodet commented on SM-766:
It seems your example has been stripped someway.
Do you have a full reproducible test you could attach to this issue ?
Error whit chracters latin1 when send message in JbiChannel. For example á
Key: SM-766
URL: https://issues.apache.org/activemq/browse/SM-766
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0.1
Environment: Windows XP XP2
servicemix 3.0.1
Reporter: Jorge Rodríguez Pedrianes
Hello, in this days i try to use jsr181 componet but i had a problem whith
latin1 characters. I show a example to understad better:
I hava a pojo:public class MyPojo {
public String echo() {
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Geronimo 2.0 Milestone's and how were doing
Paul McMahan wrote: Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. We get what I assume are similar errors shutting down Jetty 6. I'm not sure if they are the same that you are seeing or not ... but with Jetty it looks like we're in an infinite loop getting connectionErrorOccured with null SQL Exception continually until we hit a StackOverflowError. following by a full NPEs trying to deal with that. If that's what you're seeing as well then it probably isn't Tomcat. Joe
Re: Geronimo 2.0 Milestone's and how were doing
On Dec 5, 2006, at 10:27 AM, Matt Hogstrom wrote: On Dec 5, 2006, at 1:21 PM, Paul McMahan wrote: On 12/5/06, Kevan Miller [EMAIL PROTECTED] wrote: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy =2.4. servlets to. I'm looking at getting DayTrader 2.0-SNAPSHOT running now. I'm seeing some problem with the PersistenceUnitRefBuilder misinterpreting the persistence-unit-ref for jpa. I'll be looking into it later today (I hope). I also see a really long stack trace when shutting down the jetty and jetty6 servers, hope to get to that one too. thanks david jencks Perhaps I can add a new WAR with some 2.5 and JSP 2.1 content. Interested? Best wishes, Paul Matt Hogstrom [EMAIL PROTECTED]
Re: Geronimo 2.0 Milestone's and how were doing
This sounds reasonable and achievable to me. A milestone JEE 5 driver would be a great way to close out the year and get some momentum built up for next. I started to work on G-1526 last week and will hopefully like to get this in for the milestone. I've got the server building with using the DeployableModule interface as a replacement for JarFile, and now I'm trying to tweak the interface and try to test out the Eclipse support for it. If it works I'd like to post the patch for review and get it in for M1. On Dec 4, 2006, at 10:54 AM, Matt Hogstrom wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED] -sachin
[jira] Updated: (GERONIMO-1657) CommandSupport doesn't bubble up the exception. Prints stacktrace.
[ http://issues.apache.org/jira/browse/GERONIMO-1657?page=all ] Vamsavardhana Reddy updated GERONIMO-1657: -- Fix Version/s: 1.1.2 1.2 2.0 Affects Version/s: 1.1.2 1.2 2.0 Assignee: Vamsavardhana Reddy CommandSupport doesn't bubble up the exception. Prints stacktrace. -- Key: GERONIMO-1657 URL: http://issues.apache.org/jira/browse/GERONIMO-1657 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.2, 1.2, 2.0 Reporter: Prasad Kashyap Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Attachments: command.patch, Command.patch C:\Apache\geronimo\modules\deploy-jsr88\src\java\org\apache\geronimo\deployment\plugin\local\ CommandSupport.addWebURLs() prints the stacktrace of an exception. It should be bubbled up to determine the correct status of the deploy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-766) Error whit chracters lat in1 when send message in JbiChannel. For example á
[
https://issues.apache.org/activemq/browse/SM-766?page=comments#action_37630 ]
Jorge Rodríguez Pedrianes commented on SM-766:
--
(I´m sorry i press enter :P)
I have a pojo: public class MyPojo {
public String echo() {
return Mi tilde á;
}
}
when i try to invoke this method i use jsr181 component, but i see that
the latin1 character is wrong. The problem is in 'Jsr181ExchangeProcessor'
class: in 'doProcess' method, where it's necessary to indicate the character
encoding of 'out' bytes:
// Set response or DONE status
if (isInAndOut(exchange)) {
String charSet = ctx.getOutMessage().getEncoding();
-
if (ctx.getExchange().hasFaultMessage()
ctx.getExchange().getFaultMessage().getBody() != null) {
Fault fault = exchange.createFault();
fault.setContent(new StringSource(out.toString(charSet)));
--
exchange.setFault(fault);
} else {
NormalizedMessage outMsg = exchange.createMessage();
outMsg.setContent(new StringSource(out.toString(charSet)));
-
exchange.setMessage(outMsg, out);
}
} else {
exchange.setStatus(ExchangeStatus.DONE);
}
Thanks
Error whit chracters latin1 when send message in JbiChannel. For example á
Key: SM-766
URL: https://issues.apache.org/activemq/browse/SM-766
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0.1
Environment: Windows XP XP2
servicemix 3.0.1
Reporter: Jorge Rodríguez Pedrianes
Hello, in this days i try to use jsr181 componet but i had a problem whith
latin1 characters. I show a example to understad better:
I hava a pojo:public class MyPojo {
public String echo() {
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2613) Some portlets in the console can't size correctly
[ http://issues.apache.org/jira/browse/GERONIMO-2613?page=comments#action_12455730 ] Hernan Cunico commented on GERONIMO-2613: - I still think it would look a whole lot better if we use the entire portlet space to displaly the info and we already alternate grey gradients to highlight rows. I think we should go back to use the entire portlet space. With that said, the portlet space should not span over the Web browser window sz. I think the bar should be set to 1024x768 as the minimum window sz, I mean we should not have to scroll using that resolution. (that specially applies to the log viewers) Comments? Some portlets in the console can't size correctly - Key: GERONIMO-2613 URL: http://issues.apache.org/jira/browse/GERONIMO-2613 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Environment: this is for revision r480769 Reporter: Hernan Cunico Fix For: 1.2 Here is a list of portlets I saw having rendering problems. JMS Server Manager (uses just 50% of the available space) Installed Web Applications (does not wrap up, have to scroll sideways) Installed J2EE Connectors (does not wrap up, have to scroll sideways) Installed System Modules (does not wrap up, have to scroll sideways) Console Realm, both Console Realm Users and Console Realm Groups (uses just 50% of the available space) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
[jira] Assigned: (GERONIMO-1711) WebServer Connectors portlet should provide a restart option for connectors
[ http://issues.apache.org/jira/browse/GERONIMO-1711?page=all ] Vamsavardhana Reddy reassigned GERONIMO-1711: - Assignee: Vamsavardhana Reddy WebServer Connectors portlet should provide a restart option for connectors - Key: GERONIMO-1711 URL: http://issues.apache.org/jira/browse/GERONIMO-1711 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.2 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Priority: Minor Fix For: Wish List WebServer Connectors portlet currently provides start, stop, edit and delete options. It does not provide a restart option for connectors that is already running. If any properties are edited, the changes are not reflected until the connector is stopped and started again. If one has to depend on this stop and start options clicked in succession, the admin console may not be accessible as soon as the connector is stopped and there is no way of issuing a start from admin console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
Most excellent :) On Dec 5, 2006, at 2:12 PM, anita kulshreshtha wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita __ __ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Matt Hogstrom [EMAIL PROTECTED]
[jira] Assigned: (GERONIMO-1749) Server Logs portlet - Web Access Log Viewer improvements
[ http://issues.apache.org/jira/browse/GERONIMO-1749?page=all ] Vamsavardhana Reddy reassigned GERONIMO-1749: - Assignee: Vamsavardhana Reddy Server Logs portlet - Web Access Log Viewer improvements Key: GERONIMO-1749 URL: http://issues.apache.org/jira/browse/GERONIMO-1749 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1, 1.2 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: Wish List Web Access Log Viewer portlet improvements: 1. Request Method field provides only ANY, GET and POST values. It should provide search based on other Request Methods as well. In my opinion, PUT and DELETE are more important than GET and POST for an administrator searching thru webserver logs. 2. Provide Filter Max Results and Line range. Currently 1001 lines are displayed from the results and there is no way to browse all the results. 3. Dates and Date range should be validated and a message should be displyed if From date falls after To date. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1020) Slow consumer terminally blocks both client and broker
[ https://issues.apache.org/activemq/browse/AMQ-1020?page=comments#action_37631 ] paul normington commented on AMQ-1020: -- I have run into this same issue I think. We have a scenario with a DurableSubscriber that has retrieved some messages and then disconnects. The publisher continuous publishing at 1000 messages per second. After 6 messages are sent, the publisher hangs, and the broker quiesces. I have seen this behavior with 4.0.1 and 4.1.0 I took a stack trace which showed the server was stuck in UsageManager.waitForSpace(). I can delay the hanging problem by configuring more memory in the MemoryManager. I have tried setting timeToLives and pendingMessageLimitStrategies but I still get the hanging. If I use a non durable subscriber the problem goes away, but this is not an ideal solution for us. Slow consumer terminally blocks both client and broker -- Key: AMQ-1020 URL: https://issues.apache.org/activemq/browse/AMQ-1020 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Environment: Broker: Windows XP, Sun JDK1.5 Client: activemq-dotnet (Trunk) Reporter: Rob Lugt I have a multi-threaded client (client1) which is acting as both a publisher (Topic1) and subscriber (Topic2) using a single session. There is another client process (client2) which publishes on Topic2. I have witnessed the following repeatable scenario where both clients get stuck, which can only be rectified by restarting the broker! :- Client1 publishes messages to Topic1 (rate = about 30 msgs/sec). Client2 publishes bursts of messages to Topic2 (rate = 500 msgs/sec) Client1 is a slow subscriber on Topic2 After running in this scenario for a couple of seconds, Client1 and Client2 become stuck. Looking at a stack trace for Client1 I can see that it's read_loop is stuck waiting for input, and it's publisher thread is stuck waiting for an acknowledgement to the synchronous message send (the acknowledgement never arrives because the broker won't sent any more messages). Client2 is also stuck waiting for an acknowledgement to a synchronous send. My perception is that it appears the broker is throttling the connection because the consumer is running slowly, but for some reason it gets into a state where all message flow stops (even though the consumer is automatically acknowledging messages, albeit slowly). Furthermore, if I kill Client1 the broker doesn't recover (using a JMX console the connection remains visible). The broker uses a vanilla configuration (i.e. no policies are set for the topics in quedtion). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
I don't see the confusion at all, as long as the Mn is preceded by the final release version (ex. geronimo-2.0-M1). On Dec 5, 2006, at 1:21 PM, Matt Hogstrom wrote: Should we use MN -- Jason posted in another thread about how Mn (I assume you were referring to Milestones) might be confusing for post 1.0 releases. I don't think its confusing as it represents a simple point in time reference of a work in progress but not a full implementation (I think that build would more appropriately be a beta). Alpha release might be appropriate but I'm good with milestone. Other thoughts? -sachin
Re: [DISCUSS] G 2.0 M1 Content
On Dec 5, 2006, at 11:34 AM, Sachin Patel wrote: I don't see the confusion at all, as long as the Mn is preceded by the final release version (ex. geronimo-2.0-M1). Yes, but already Matt is referring to M1 with no 2.0 prefix. Anyways... I don't like it... but I don't have the energy to debate it. --jason
Re: SNAPSHOT - Revision #
Eh... its just my opinion. I thought I had explained why I thought this was a bad idea in previous emails. But... I don't think this is worth debating either. So if you feel strongly about it... then go do it. I still don't like it, but I can live with that. --jason On Dec 5, 2006, at 6:55 AM, Hernan Cunico wrote: Once again Kevan beat me on the reply ( man, don't you stop for dinner !? ;-) ) Jason, I don't get why you think this is so bad. I'm talking about tweaking my local copy so I can make the doc look closer to the final Geronimo release. If some areas change later on, that's fine, I'm expecting so. But that would be just a very few areas, or you think the whole console and commands will change from now on until the final cut is released? In addition, there are some already reported bugs in the console and I will have to revisit those areas either way. I'm just trying to keep the revisiting to a minimum and save some time. This is what I originally asked help for. snip is there a way I could locally get rid of the SNAPSHOT or the revision number? It will really save me a lot of time with the Geronimo v1.2 documentation. /snip If there is no way to do it locally due to external dependencies, then fine, I can't, end of story. I'll need to find another way to get a similar result. With that said, I'm about try Kevan's suggestion on tweaking the pom.xml and see how it goes. Cheers! Hernan Kevan Miller wrote: On Dec 4, 2006, at 4:56 PM, Jason Dillon wrote: is this all for web console shots? If so, then update the console to make that configurable. But if its for build shorts, like capturing what mvn spits out, then I think that its be a very bad idea to change the project version just for a screen shot. Actually I think its a waste of time to even bother with the property thing, but if its low impact, and does not add any more burden/overhead for the normal build/release, then I think its fine. Jason, Hernan wants to create 1.2 documentation. He wants that documentation to be as close to the the actual user experience as he can. I think that is *fantastic*. And I think we could give him a bit of support in his efforts. Here's how it could work: 1) Hernan could make a private update to his pom.xml and build a preview of 1.2. There may be a few stumbling blocks, here. Hard- coded versions, OpenEJB dependencies, etc. 2) Hernan uses this preview build to generate reasonably accurate screenshots. No code is checked into svn. No artifacts are deployed to maven repos. I assume that Hernan's m2 repo/build environment will not build 1.2-SNAPSHOT properly after that. So, when Hernan is done, he wipes out his build tree and maven repo (or geronimo sections of his repo) and reverts back to 1.2-SNAPSHOT. What's so bad about all that? I'm certainly willing to lend Hernan a hand to get his environment up and running. I would hope that others involved with the 1.2 release might actually want to help him out too... --kevan
Re: Geronimo 2.0 Milestone's and how were doing
+1. Oh yeah, I agree. Let's give it a shot with all the best that we have. Cheers Prasad On 12/5/06, Paul McMahan [EMAIL PROTECTED] wrote: Matt, JEE5 is critical to the widespread adoption of Geronimo. We can and should accomplish these milestones. Best wishes, Paul On 12/4/06, Matt Hogstrom [EMAIL PROTECTED] wrote: While ripping out drywall this weekend I was thinking about our Geronimo 2.0 and all the work that needs to get done to complete this monsterous effort. While sifting through the scorecard and thinking about all the different things that need to be addressed it became a bit overwhelming. As everyone knows many different projects are working on their implementations of Java EE 5.0. Some are available and others are works in progress (as is ours). It seems that from user perspective people are really interested in the Java EE and have been asking for several months about where we are. At this point it would be nice to give them an idea of what we're thinking about. I had previously put out a set of milestones and dates. I wanted to make it a little more formal and of course with all the caveats that this is open source and our timetables are subject to people's time and contribution. With that, here is an updated timeline and some graphic representations that represent the Java EE specifications that need to be completed from a high level. I think it was Dain that used the term table stakes when referring to the specification. Meaning that we need the spec related functionality to get in the game but innovations beyond the specification were necessary to make a bigger splash. I don't capture those here but I'll work on pulling that together as well. Take a look at http://people.apache.org/~hogstrom/Geronimo2.0/ and provide your thoughts on how were doing. If we are going to make a Dec 22 Beta 1 then we would have to cut sometime in the next week and a half. What do y'all think? Matt Hogstrom [EMAIL PROTECTED]
Re: Openejb-2.3 itests fixed ! Well almost.
http://geronimo.apache.org/maven/server/testsuite/20061205/ejbcontainer-testsuite/test-ejbcontainer/surefire-report.html Cheers Prasad On 12/5/06, Prasad Kashyap [EMAIL PROTECTED] wrote: This is as far down to the bottom as I could get of this NoClassDefFoundError. java.lang.NoClassDefFoundError at org.apache.openejb.test.stateless.EncStatelessBean.lookupEntityBean(EncStatelessBean.java:60) And that code on line 60 of EncStatelessBean.java is: BasicBmpHome home = (BasicBmpHome) javax.rmi.PortableRemoteObject.narrow( ctx.lookup(java:comp/env/stateless/beanReferences/bmp_entity), BasicBmpHome.class ); Unless I'm missing something in the plan, the ejb-refs look alright to me. The BasicBmpHome and EncStatelessBean are in the same package, openejb-itests-core-2.3-incubating-SNAPSHOT.jar which is deployed prior to running the tests. Yet, we get this NoClassDefFoundError ! Cheers Prasad On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote: David, The .setup() and .teardown() still continue to show up withour their testnames prepended. We'll have to go back to using the DummyTest.java that was in the original patch (391). Anyways, here is the patch again. Please apply it. https://issues.apache.org/jira/browse/OPENEJB-397 In the ReuseOpenEJbTest, I changed the database system property from InstantDB to Derby. System.setProperty(openejb.test.database, org.apache.openejb.test.DerbyTestDatabase.class.getName()); We now execute 552 tests out of which 27 fail and 10 throw errors. All the faillures are due to a NoClassDefFoundError yet the stacktrace is not all that informative. All the errors are coming from the CMRMapping tests. One tiny fix someplace in each will fix them all. Here are the logs http://rifers.org/paste/show/2594 Cheers Prasad On 12/4/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Thanx David for taking care of those. The DummyTest.java didn't go into trunk. Can you please do the needful ? Thanx Prasad On 12/4/06, David Blevins [EMAIL PROTECTED] wrote: Made a couple extra fixes too and published new snapshots of the itests. -David On Dec 4, 2006, at 10:18 AM, David Blevins wrote: On Nov 30, 2006, at 9:06 PM, Prasad Kashyap wrote: Hi David, This is a continuation of the discussion we had in the Testsuite ready for action thread. First, the openejb-itests-core would not start. I have submitted a patch at https://issues.apache.org/jira/browse/OPENEJB-391 Please apply this. Applied. Next, openejb itests continued to fail looking for the same getName() method. I then fixed it in https://issues.apache.org/jira/browse/OPENEJB-392. Please apply this as well. Applied. -David Lastly for the almost part, after this and other fixes, we now have 185 passing tests, 2 failures and 5 errors. The stacktrace for the failures and errors can be seen here - http://rifers.org/paste/show/2527 Please apply the patches in the above JIRAs. You will notice that the names will show up in the logs as just .setUp. This needs to be fixed too. Thanx, Prasad
[jira] Commented: (GERONIMO-2537) All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy
[ http://issues.apache.org/jira/browse/GERONIMO-2537?page=comments#action_12455753 ] Kevan Miller commented on GERONIMO-2537: OK. I think I'm done with branches/1.2. We need to update the trunk license and notice files to reflect any projects unique to trunk (e.g. jetty6 and tomcat 6). I'll keep this open until I complete that task... All Geronimo source files must be brought in line with the new ASF source header and copyright notice policy Key: GERONIMO-2537 URL: http://issues.apache.org/jira/browse/GERONIMO-2537 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.2, 1.2 Reporter: Kevan Miller Assigned To: Kevan Miller Priority: Blocker Fix For: 1.1.2, 1.2 Attachments: geronimo-1.2-2537.addlicense-2.patch, geronimo-1.2-2537.addlicense.patch, geronimo-copyright.txt, geronimo-NoLicense.txt The ASF has new requirements for Source headers and copyright notices. See http://www.apache.org/legal/src-headers.html for details. All releases after November 1, 2006 must comply with this policy. It seems that 1.2 will be post November 1... :-) All Geronimo source files in trunk must be brought in line with this new policy... If we create a 1.1.2 release, we need to insure that all src files in branches/1.1 are brought inline with this new policy, also. There seem to be some scripts that will aid with these updates (see the FAQ in the above url). However, I can't access them at the moment... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
eh... I think proteinStrand, chimp, frog is s much better Matt :-P I just don't want to start hearing people talking about m1 and meaning 2.0-m1 compared to the first m1 of Geronimo. I'm going to drop this now... my opinion has been noted... and now ye all shall continue :-) --jason On Dec 5, 2006, at 12:35 PM, Matt Hogstrom wrote: On Dec 5, 2006, at 2:41 PM, Jason Dillon wrote: On Dec 5, 2006, at 11:34 AM, Sachin Patel wrote: I don't see the confusion at all, as long as the Mn is preceded by the final release version (ex. geronimo-2.0-M1). Yes, but already Matt is referring to M1 with no 2.0 prefix. Anyways... I don't like it... but I don't have the energy to debate it. My bad. I meant 2.0-M1...I'll correct that omission in the future. I now understand the confusion. What other suffix do you think would be appropriate? I don't care if its 2.0-frog1. Following an evolutionary theme we could have: 2.0-proteinStrand 2.0-singleCellOrganism 2.0-fish 2.0-frog 2.0-chimp 2.0-homosapien 2.0 :) --jason Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] G 2.0 M1 Content
Matt Hogstrom wrote: Should we use MN -- Jason posted in another thread about how Mn (I assume you were referring to Milestones) might be confusing for post 1.0 releases. I don't think its confusing as it represents a simple point in time reference of a work in progress but not a full implementation (I think that build would more appropriately be a beta). Alpha release might be appropriate but I'm good with milestone. Other thoughts? I find milestone more helpful than alpha or beta which I typically think of as being mostly function complete releases (which is not true for this initial delivery). Documentation - Need the normal release notes to identify what works and what doesn't. I was talking to Sachin and he indicated that WTP would barf on most of the Java EE 5.0 stuff so that is a reasonable thing to post here. Also, a description of what is included and not would make sense as well. Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) Yes, as I mentioned on earlier appends I believe including JSTL 1.2 is just a matter of including the library (which I'm still planning to pull from Glassfish based on the recommendation from the jakarta team). JSTL has pre-req on JSP 2.1 - Jetty 6 we have now is still using jsp 2.0 from jasper. I'm trying to get my local build to use the jsp-2.1 that is produced by Jetty 6 (which I think also includes Glassfish parts IIUC). - Tomcat 6 - It looks like Paul is covering JSP 2.1 with his work. If I get one of the containers working with JSP 2.1 then I can verify if the JSTL is just a matter of dropping in the jar. Joe
Re: NEED HELP on how i can Provide an ay for retrieving the amount of messages per priority that is waiting to be sent to subscribers
Could someone provide more help or an example (other than the documentation link on ActiveMQ site) on how to write a interceptor for finding the amount of messages per priority waiting to be sent to consumers ? - Sreenivas James.Strachan wrote: You could write a broker interceptor to keep a track of this kind of thing; or use selectors. http://incubator.apache.org/activemq/interceptors.html On 12/4/06, samahome [EMAIL PROTECTED] wrote: Which classes in ActiveMQ source i can look at for Providing an way for retrieving the amount of messages per priority that is waiting to be sent to subscribers ? I would like to get this functionality programatically (other than the use of JMX). Help /Insights on this greatly appreciated. Thanks, Sreenivas -- View this message in context: http://www.nabble.com/NEED-HELP--on-how-i-can-%22Provide-an-ay-for-retrieving-the-amount-of-messages-per-priority-that-is-waiting-to-be-sent-to-subscribers%22-tf2749797.html#a7671885 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/NEED-HELP--on-how-i-can-%22Provide-an-ay-for-retrieving-the-amount-of-messages-per-priority-that-is-waiting-to-be-sent-to-subscribers%22-tf2749797.html#a7707264 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] G 2.0 M1 Content
On Dec 5, 2006, at 2:41 PM, Jason Dillon wrote: On Dec 5, 2006, at 11:34 AM, Sachin Patel wrote: I don't see the confusion at all, as long as the Mn is preceded by the final release version (ex. geronimo-2.0-M1). Yes, but already Matt is referring to M1 with no 2.0 prefix. Anyways... I don't like it... but I don't have the energy to debate it. My bad. I meant 2.0-M1...I'll correct that omission in the future. I now understand the confusion. What other suffix do you think would be appropriate? I don't care if its 2.0-frog1. Following an evolutionary theme we could have: 2.0-proteinStrand 2.0-singleCellOrganism 2.0-fish 2.0-frog 2.0-chimp 2.0-homosapien 2.0 :) --jason Matt Hogstrom [EMAIL PROTECTED]
Re: [DISCUSS] G 2.0 M1 Content
Matt Hogstrom wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) Once we get this together and we can run Daytrader 2.0-SNAPSHOT on it I think we have a content ready milestone. Matt, JavaMail 1.4 and JAF 1.1 work was done by Rick and I already published the JavaMail specs, provider, mail jars to Apache snapshot repo. I'm currently working on updating trunk to use JavaMail 1.4 and JAF 1.1. and after this is done we need to test it and make sure it doesn't break anything and we should be set. This should be done this week. chris
Re: Geronimo build automation status (longish)
On Dec 4, 2006, at 8:57 PM, John Sisson wrote: Jason Dillon wrote: Maybe it is starting your response with the word What?. I could have interpreted it completely differently to how you intended, but it did not make you seem friendly and approachable. Eh.. maybe :-P Maybe Huh?... Hrm...? Whaddyamean? Wha-what?... Though they all seem to end up suggesting that I am surprised. Funny that the plain english version makes it seem like I am being a prick or something :-P As I mentioned in the initial email, the AntHill license is very similar to that of JIRA or Confluence... they grant licenses for use by open-source projects. Can the full text of the open source license be sent to the PMC for vetting? Sure. Did the PMC do any vetting for JIRA or Confluence? I had hopped to get a more perfect and complete system before I brought this to the community... though I'm not sure that would have mattered much. Probably more that the tool is not open- source is why you even mention this. If I did something similar with CC or Continuum no one would even mention it. Too bad neither of those tools is comprehensive enough to do the job though... but maybe if we wait for a few more years they will be closer. :-P Maybe I need an apple mail plugin to randomly insert emotions into mail so that folks don't think that I am being harsh... Maybe :-) Everyone doesn't have the same thickness of skin. Mybbbe not. :-) I know sometimes I misjudge the tone of email, :-P, and then reply with similar tone to that which I interpreted ;-) :-P IMO best not to think about tone at all when reading email... more often than not the interpreted tone is more a manifestation of your own mood than what the text of the message actually indicates. :-) :-) :-P --jason
Re: [DISCUSS] G 2.0 M1 Content
Matt Hogstrom wrote: ... Should we use MN -- I like Milestones better ( G2.0-M1 ) than Alpha/Beta schema. Documentation - The Apache Geronimo v2.0 cwiki space is already available at cwiki.apache.org/geronimo. We could use it to hold all v2.0 specific info (release notes, release roadmaps, documentation itself, etc.) Content --- We need this content on the wiki (and referenced from the Web site). I think it would help a features breakdown table grouped by Milestones. Timeline This is less important than the content. I suggested 12/22 since its the Friday before the Christmas holiday. Personally it would feel good to know we packaged up something and finished it this year towards 2.0. Agree, with the holidays approaching is either on 12/22 or some time next year, hopefully in the first few months. There is a lot of small stuff we already have thats almost done. We've We need to get that info in the Milestone release roadmap (let's give it a catchy name ;-) ) been discussing release early and often so the date is more of an artificial stake in the sand. If we don't get the work done then we don't ship. It largely depends on completing what goes into M1 rather than the date. ... Matt Hogstrom [EMAIL PROTECTED] Cheers! Hernan
[jira] Closed: (GERONIMO-1911) HTTPS algorithm=Default is not preserved after the server is started
[ http://issues.apache.org/jira/browse/GERONIMO-1911?page=all ] Vamsavardhana Reddy closed GERONIMO-1911. - Fix Version/s: (was: 1.x) Resolution: Invalid HTTPS algorithm=Default is not preserved after the server is started Key: GERONIMO-1911 URL: http://issues.apache.org/jira/browse/GERONIMO-1911 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.2 Environment: Sun or IBM 1.4.2 JDK Reporter: Donald Woods Priority: Minor Attachments: Geronimo-1911.patch During the first run of the server, the algorithm=Default attribute on the TomcatWebSSLConnector in config.xml is updated to match the current JVM being used. This causes problems for people switching between Sun and IBM JRE/JDK when using Eclipse. The fix, is to update HttpsConnectorGBean.java to not set the algorithm variable to getDefaultAlgorithm() when Default was set, but to just set the connector attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-657) Running configurations not saved on shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-657?page=all ] Vamsavardhana Reddy closed GERONIMO-657. Running configurations not saved on shutdown Key: GERONIMO-657 URL: http://issues.apache.org/jira/browse/GERONIMO-657 Project: Geronimo Issue Type: Bug Reporter: Dain Sundstrom Assigned To: Aaron Mulder Fix For: 1.0-M4 When the server shuts down the current running configuration should be saved to var/config/config.list but it doesn't look like this code works anymore. It would be nice if there were a test case for this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
anita kulshreshtha wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita Anita, I also started looking at J2EE management work and I'm just wondering what you plan to include specifically in M1 release. I think we should coordinate this work so we don’t do the same thing. Thanks, chris Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
[jira] Closed: (GERONIMO-436) JSR-88: Targets Ignored
[ http://issues.apache.org/jira/browse/GERONIMO-436?page=all ] Vamsavardhana Reddy closed GERONIMO-436. JSR-88: Targets Ignored --- Key: GERONIMO-436 URL: http://issues.apache.org/jira/browse/GERONIMO-436 Project: Geronimo Issue Type: Bug Components: deployment Affects Versions: 1.0-M2 Reporter: Aaron Mulder Assigned To: Aaron Mulder Priority: Critical Fix For: 1.1 The current JSR-88 deployer (JMXDeploymentManager) may potentially provide a list of targets for getTargets() -- one per config store. However, all the methods that take an array of Target or TargetModuleID objects ignore the specified Targets. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-515) GeronimoPolicyConfigurationFactory does not always return same instance
[ http://issues.apache.org/jira/browse/GERONIMO-515?page=all ]
Vamsavardhana Reddy closed GERONIMO-515.
GeronimoPolicyConfigurationFactory does not always return same instance
---
Key: GERONIMO-515
URL: http://issues.apache.org/jira/browse/GERONIMO-515
Project: Geronimo
Issue Type: Bug
Components: security
Affects Versions: 1.0-M3
Reporter: David Jencks
Assigned To: Alan Cabrera
From javadoc for getPolicyConfiguration(String contextID, boolean remove)
* For a given value of policy context identifier, this method must always
* return the same instance of PolicyConfiguration and there must be at
* most one actual instance of a PolicyConfiguration with a given policy
* context identifier (during a process context). p
*
* To preserve the invariant that there be at most one PolicyConfiguration
* object for a given policy context, it may be necessary for this method
* to be thread safe.
From our implementation:
if (configuration == null || remove) {
configuration = new PolicyConfigurationGeneric(contextID);
configurations.put(contextID, configuration);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-766) Error whit chracters lati n1 when send message in JbiChannel. For example á
[ https://issues.apache.org/activemq/browse/SM-766?page=all ]
Guillaume Nodet resolved SM-766.
Fix Version/s: 3.1
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Tue Dec 5 13:24:46 2006
New Revision: 482787
URL: http://svn.apache.org/viewvc?view=revrev=482787
Log:
SM-766: Error with latin characters in jsr181
Patch provided by Jorge Rodríguez Pedrianes. Thx !
Modified:
incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181ExchangeProcessor.java
incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/src/test/java/org/apache/servicemix/jsr181/Jsr181ComplexPojoTest.java
Error whit chracters latin1 when send message in JbiChannel. For example á
Key: SM-766
URL: https://issues.apache.org/activemq/browse/SM-766
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0.1
Environment: Windows XP XP2
servicemix 3.0.1
Reporter: Jorge Rodríguez Pedrianes
Assigned To: Guillaume Nodet
Fix For: 3.1
Hello, in this days i try to use jsr181 componet but i had a problem whith
latin1 characters. I show a example to understad better:
I hava a pojo:public class MyPojo {
public String echo() {
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-767) Statistics should be available at the endpoint level
Statistics should be available at the endpoint level Key: SM-767 URL: https://issues.apache.org/activemq/browse/SM-767 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Apache mod_jk Configuration
Hi All, I'm trying to walk through the steps described in the Apache HTTP - *Apache mod_jk Configuration* portlet but I'm not being able to get the things working. First I noticed that the info I enter in the first screen (Basic Configuration) is not entirely parsed to the subsequent screens. The last screen (Configuration Results) is providing incomplete and, for what I can see, wrong configuration information. Some of the values entered in the first screen are missing and the values suggested for the workers.properties on Step 3 do not match those suggested for the httpd.conf on Step 4 (worker name). The configuration described in Step 4: Apache Configuration seem to be incorrect or incomplete. I am too familiar with the configuration of the new Apache HTTP nor the use of the IfModule / tag. Somebody that knows more about the latest HTTPd should take a look at that portlet and see what's missing. Have anyone else seen this problem? FWIW, I tried my old recipe for using mod_jk still works :P (http://cwiki.apache.org/GMOxDOC12/configure-apache-httpd-with-jakarta-tomcat-connector-modjk.html) Cheers! Hernan
Re: Geronimo build automation status (longish)
On Dec 5, 2006, at 3:37 PM, Jason Dillon wrote: As I mentioned in the initial email, the AntHill license is very similar to that of JIRA or Confluence... they grant licenses for use by open-source projects. Can the full text of the open source license be sent to the PMC for vetting? Sure. Did the PMC do any vetting for JIRA or Confluence? To my knowledge, those are both being run by (and licensed to) the ASF, not Geronimo. Am I wrong? As you note, AntHill is going to be very similar to both of those. I doubt that there's going to be an issue. And don't mean to be picking on you (happy to pick on somebody else :-P, I just think it's a good idea for this type of information to be shared with and evaluated by the project... --kevan
[jira] Resolved: (SM-767) Statistics should be available at the endpoint level
[ https://issues.apache.org/activemq/browse/SM-767?page=all ] Guillaume Nodet resolved SM-767. Resolution: Fixed Author: gnodet Date: Tue Dec 5 13:46:47 2006 New Revision: 482795 URL: http://svn.apache.org/viewvc?view=revrev=482795 Log: SM-767: Statistics should be available at the endpoint level Put all statistics related package in its own package, so that the whole statistic service become optional. Add a onExchangeAccepted method on the ExchangeListener. Add a onComponentInitialized event on the ComponentListener. Add a service property on the JBIContainer so that it can register listeners on components and endpoints and still receive all the events. Add some javadocs to the event package. Statistics should be available at the endpoint level Key: SM-767 URL: https://issues.apache.org/activemq/browse/SM-767 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] G 2.0 M1 Content
On Dec 5, 2006, at 10:21 AM, Matt Hogstrom wrote: Should we use MN -- Jason posted in another thread about how Mn (I assume you were referring to Milestones) might be confusing for post 1.0 releases. I don't think its confusing as it represents a simple point in time reference of a work in progress but not a full implementation (I think that build would more appropriately be a beta). Alpha release might be appropriate but I'm good with milestone. Other thoughts? We have a history of using M1 syntax for releases and see no reason to change that. Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) Once we get this together and we can run Daytrader 2.0-SNAPSHOT on it I think we have a content ready milestone. We already have JPA but it is so cool we should mention it again :) Timeline This is less important than the content. I suggested 12/22 since its the Friday before the Christmas holiday. Personally it would feel good to know we packaged up something and finished it this year towards 2.0. There is a lot of small stuff we already have thats almost done. We've been discussing release early and often so the date is more of an artificial stake in the sand. If we don't get the work done then we don't ship. It largely depends on completing what goes into M1 rather than the date. +1 Lets get'er done -dain
[jira] Created: (SM-768) Throttling should be available on a per endpoint basis
Throttling should be available on a per endpoint basis -- Key: SM-768 URL: https://issues.apache.org/activemq/browse/SM-768 Project: ServiceMix Issue Type: New Feature Components: servicemix-core Reporter: Guillaume Nodet The throtling parameters should be (ideally) * easily configured dynamically * available on an endpoint output, input, or route (endpoint - endpoint ?) * persistent ... Not sure if all these features are needed atm. The first step would be to do that on a per endpoint basis ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Ehcache Standard JBI Component
On 12/3/06, jpuro [EMAIL PROTECTED] wrote: I am planning on creating a standard JBI component for ehcache so that one can easily deploy ehcache endpoints into ServiceMix and other JBI compliant containers. Here are some high level requirements that I think would be useful for this component. Please respond to this thread with any comments are concerns. Cool :) 1) There should be a way to configure endpoints that when deployed create actual Caches. The endpoints should be able to have expressions associated with them that can determine how the Cache matches information based off of the Normalized Message. So for example, if you have properties that need to be a part of your key in the cache then you can use an expression to match that. If there is an XPath expression that needs to be matched, this can also be used. The use of an expression is good. This is the way it was done for the lightweight one and should be flexible enough. 2) I'm still not sure whether it makes sense to allow for a SU to configure the CacheManager itself using the ehcache.xml configuration file. The benefit of this is that you leave the component to just worrying about configuration files and not starting up any cachemanagers itself. You will also be able to create specialized cachemanager's with their associated information on the fly. I could see this as being beneficial. However, perhaps it's better to leave the Ehcache configuration specific to the component itself. That is to say that when you deploy the component it loads up its already packaged ehcache.xml file which configures the CacheManager. If someone needs a different configuration they will have to edit the one packaged with the component or go to JMX and update the values stored there. I think both the configuration on the component, which would provide an easy way to get started, and the configuration on the SU are necessary. Maybe we could reuse spring EHCache support (see http://www.springframework.org/docs/api/org/springframework/cache/ehcache/package-summary.html) but I'm not sure if it will be really helpful for implementing this component as I haven't really looked at it yet. Regards, Jeff -- View this message in context: http://www.nabble.com/Ehcache-Standard-JBI-Component-tf2747953s12049.html#a7666554 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: Openejb-2.3 itests fixed ! Well almost.
On 12/5/06, Prasad Kashyap [EMAIL PROTECTED] wrote: http://geronimo.apache.org/maven/server/testsuite/20061205/ejbcontainer-testsuite/test-ejbcontainer/surefire-report.html That's nice. How did you do that? I mean the report not the itests runs themselves. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Geronimo build automation status (longish)
On Dec 5, 2006, at 1:35 PM, Kevan Miller wrote: Sure. Did the PMC do any vetting for JIRA or Confluence? To my knowledge, those are both being run by (and licensed to) the ASF, not Geronimo. Am I wrong? I believe so... though I need to check what the exact text of the granted license is to be sure. Though... I'm not sure that it really matters. I can get them to reissue the license using Apache Software Foundation as the licensee, looks like that is what Confluence has. Though this setup is a little different that JIRA and Confluence, as this is only for Geroniomo related projects... and I have not plans or intent to open up this particular install for ASF-wide usage... though AH can definitely support that... but I'm not heading in that direction now... or anytime soon. I also just asked Atlassian for the full-text of there open-source EULA and they told me they don't have one specific for there open- source licenses. They just pointed me at: http://www.atlassian.com/about/licensing/license.jsp But that page has like 14 EULAs on it. From talking to the UrbanCode folks, they too do not have a specific license for open-source use, but said Apache uses JIRA, so I'm sure a similar license would work for us too. As you note, AntHill is going to be very similar to both of those. I doubt that there's going to be an issue. And don't mean to be picking on you (happy to pick on somebody else :-P, I just think it's a good idea for this type of information to be shared with and evaluated by the project... Its okay... I agree with you. --jason
Re: Openejb-2.3 itests fixed ! Well almost.
surefire-report-plugin Check out all the reports we have generated at http://cwiki.apache.org/confluence/display/GMOxDEV/Maven+Generated+Documentation Go to Project Reports link at the bottom of the left hand menu. Cheers Prasad On 12/5/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 12/5/06, Prasad Kashyap [EMAIL PROTECTED] wrote: http://geronimo.apache.org/maven/server/testsuite/20061205/ejbcontainer-testsuite/test-ejbcontainer/surefire-report.html That's nice. How did you do that? I mean the report not the itests runs themselves. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Commented: (GERONIMO-1499) Daytrader: uncomment the drop table statements in daytrader.sql
[ http://issues.apache.org/jira/browse/GERONIMO-1499?page=comments#action_12455783 ] Piyush Agarwal commented on GERONIMO-1499: -- Lin, do you think this patch is still required? Daytrader-14 has been commited and it allows the user to create the db tables and indexes from the Config panel itself. The only prerequiste is that a database instance should exist, the user can now go to the Config page and use the Recreate Database tables and indexes to create the daytrader database. Daytrader: uncomment the drop table statements in daytrader.sql Key: GERONIMO-1499 URL: http://issues.apache.org/jira/browse/GERONIMO-1499 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 1.0 Environment: winxp, Reporter: Lin Sun Priority: Minor Attachments: G1499-daytrader-sql.patch If the daytrader.sql is executed the 2nd time, you will see many errors like index already exisited...because the tables are not dropped.I think it is better to uncomment the drop table statements in daytrader/derby/src/sql/daytrader.sql. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
DConfigBean Confusion
I'm trying to straighten out some classpath problems with the deployment code and dconfigbeans and am pretty confused about some of the code. The main thing I'm confused about is that in the geronimo-connector- builder module there seem to be two partial sets of DConfigBeans, in dconfigbean and in jsr88. There's some overlap... and a bunch of big differences. It looks to me as if the console is using the stuff in jsr88 to build connector plans. Does anyone know what is going on here and which is more correct? Does the connector 1.0 stuff in dconfigbean work? I think we should try to get all these consistent and in one directory. It would also be great to have the console support deploying connector 1.0 rars there's at least one (jaybird) that is only available as a 1.0 connector. - There's another longstanding problem with dconfigbeans which is that they've never been able to work from any reasonable standalone situation, such as the spec scenario where you get them from a DeploymentManager.createConfiguration call since you'd need a large fraction of the geronimo server on the classpath to make it work. I think that any solution for this is going to have to use the geronimo repository since thats where the zillion jars needed are and are likely to stay. So, I think we have to start a kernel and load a configuration and have the Configurers register with something that the DeploymentManagers can get at. Anyone have a better idea? thanks david jencks
Error compiling Geronimo with Maven
I'm getting several exceptions when building Geronimo as told in the Geronimo wiki. How am I suppose to compile this? __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
