Re: Info needed: migrating openejb-itests to testsuite framework
OK. This is what is happening. I built the server from scratch, clean repo and fresh checkout. When I deploy the openejb-itests.jar in this server, I get a deployment exception that it needs a plan at META-INF/openejb-jar.xml. The plan is embedded inside the jar. I get the same error even when I pass the plan as a CLI arg to the deploy command. (Now why does this happen ?) Then I replaced the openejb-builder-2.2-incubating-SNAPSHOT.jar in the geronimo repository with the jar from the m2 local repo. This jar was built from scratch. Now when I try to deploy the same again, I get the previously mentioned error with the plan (wrong ns and xsd). Cheers Prasad On 10/12/06, David Jencks <[EMAIL PROTECTED]> wrote: On Oct 12, 2006, at 1:27 PM, Prasad Kashyap wrote: > My efforts in deploying the openejb-itests.jar with the attached plan > is failing b'coz of some errors in the plan. The errors in the plan > are being introduced at some stage in the deploy process. > > My plan uses the pkgen ns for key-generator >xmlns:pkgen="http://openejb.apache.org/xml/ns/pkgen-2.1"; > ... > ... > > > > But the deploy tool is seeing the following the ns >xmlns:pkg="http://www.openejb.org/xml/ns/pkgen-2.0"; >.. >.. > > > > Where is this coming from ? I can't find anywhere it could be coming from. There are namespace substitutions in XmlBeansUtil and Upgrader but neither of those could produce this change. They could change 2.0 to 2.1. Wish I could offer useful advice :-( david jencks > > Thanx > Prasad > > > > > On 10/11/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> Hi Jacek, >> >> We now have a testsuite directory under geronimo which is the basis >> for a system and functional test framework for all of Geronimo. I >> have >> begun with a doc in the wiki about this. >> http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is >> still in a rudimentary stage but it will give you a general idea. >> I am >> enhancing it as I go along. >> >> This discussion revolves around migrating the openejb itests to this >> new framework. So after a G assembly is done, the build will continue >> to testing the various functional pieces of the server like >> webcontainer, ejbcontainer, console, clustering etc. >> >> Cheers >> Prasad >> >> On 10/11/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: >> > On 10/11/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: >> > > David, >> > > >> > > Thanks for that write-up on the openejb itests. It helped me >> > > understand the structure better. >> > > >> > > All the client code (in src/itests) have a dependency on the >> beans (in >> > > src/java) anyway. So this is what I did. I put all the beans >> in 1 core >> > > project (openejb-itests). I put the plans and DDs in their >> individual >> > > projects. The individual projects then unpack just the needed >> classes >> > > from that core project and build the ejb archive with it's >> plan and >> > > DD. >> > > >> > > testsuite/ejbcontainer-testsuite >> > >ejb-modules >> > >openejb-itests <-- core project with beans >> > >openejb-security-001 <-- just plan and DD >> > >openejb-security-002 >> > >openejb-security-003 >> > >openejb-cmp2-prefetch >> > >openejb-cmp2-petstore >> > >openejb-cmp2-cmrmapping >> > >openejb-cmp2-storage >> > >test-ejbcontainer <--- junit tests in client >> > >> > Hi Prasad, >> > >> > Why are the matter being discussed here? Shouldn't it go to >> openejb-dev? >> > >> > Jacek >> > >> > -- >> > Jacek Laskowski >> > http://www.laskowski.net.pl >> > >> >> >>
[jira] Created: (GERONIMO-2493) Integrate Axis2 webservices
Integrate Axis2 webservices --- Key: GERONIMO-2493 URL: http://issues.apache.org/jira/browse/GERONIMO-2493 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: webservices Affects Versions: 1.2 Reporter: David Jencks Fix For: 1.2 Integrate axis 2 for webservices. Probably at least 3 steps - pojo ws - ejb ws - ws client -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2492) Integrate CXF webservices
Integrate CXF webservices - Key: GERONIMO-2492 URL: http://issues.apache.org/jira/browse/GERONIMO-2492 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: webservices Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Integrate CXF for webservices. Probably at least 3 steps - pojo ws - ejb ws - ws client There's a early version of a celtix-geronimo deployer we can try updating. -- 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: Priorities for 1.2
Sorry to be completely late on this thread but I'd like to add one more to the list... - Improved Tooling/Runtime integration. Abstract out use of JarFile in deployers so J2EE deployment can occur in-place within IDE project structures.On Oct 2, 2006, at 3:40 PM, Dain Sundstrom wrote:We have collected 14 features for 1.2 and now we need to prioritize them. The sorted list of features will help guide us in determining when to release based on how many high priority features we have completed.Please, sort the following list according to what *you* believe are the most important features to include in 1.2. It will help me tally the list if you simply reorder the list instead of putting numbers next to the features. Also, please *do not* attempt to give more than one feature the same priority. In such a case, I will give priority to the highest left-most item in your list.I will tally the results on Friday, October 6th.-dainOpenJPA integrationGlobal JNDIYoko ORB supportFull Java 5 supportJAF 1.1GShell integrationCMP improvementsConsole usability improvementsJetspeed integrationMore server modularization via pluginsConsole extensibilityMore out of the box samplesOpenEJB 3.0 integration with @Stateless EJBs supportGeronimo OSGi bundle -sachin
[jira] Created: (GERONIMO-2491) Hibernate passes connections between servlets which we don't support
Hibernate passes connections between servlets which we don't support Key: GERONIMO-2491 URL: http://issues.apache.org/jira/browse/GERONIMO-2491 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.1.1, 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.1.2, 1.2 This is based on examination of roller running in geronimo-tomcat and is partly speculation. There's certainly a problem. 1. request sets InstanceContext 1 in ConnectionTrackingCoordinator. 2. roller starts a persistence context (in hibernate jargon a session) in a servlet filter. No connection is opened yet 3. tiles dispatches to a jsp 4. dispatch sets InstanceContext 2 in CTC 5. jsp does something persistent causing hibernate to open a db connection. This is registered with IC 2. 6. jsp dispatch returns, so IC 1 is set in CTC 7. roller commits the persistence context in the servlet filter, which closes the connection. Closing the connection attempts to unregister from the current IC. IC 1 doesn't know anything about this connection. we get an NPE. The solution isn't clear to me 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: Info needed: migrating openejb-itests to testsuite framework
On Oct 12, 2006, at 1:27 PM, Prasad Kashyap wrote: My efforts in deploying the openejb-itests.jar with the attached plan is failing b'coz of some errors in the plan. The errors in the plan are being introduced at some stage in the deploy process. My plan uses the pkgen ns for key-generator xmlns:pkgen="http://openejb.apache.org/xml/ns/pkgen-2.1"; ... ... But the deploy tool is seeing the following the ns xmlns:pkg="http://www.openejb.org/xml/ns/pkgen-2.0"; .. .. Where is this coming from ? I can't find anywhere it could be coming from. There are namespace substitutions in XmlBeansUtil and Upgrader but neither of those could produce this change. They could change 2.0 to 2.1. Wish I could offer useful advice :-( david jencks Thanx Prasad On 10/11/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: Hi Jacek, We now have a testsuite directory under geronimo which is the basis for a system and functional test framework for all of Geronimo. I have begun with a doc in the wiki about this. http://cwiki.apache.org/GMOxDEV/integration-testing.html The doc is still in a rudimentary stage but it will give you a general idea. I am enhancing it as I go along. This discussion revolves around migrating the openejb itests to this new framework. So after a G assembly is done, the build will continue to testing the various functional pieces of the server like webcontainer, ejbcontainer, console, clustering etc. Cheers Prasad On 10/11/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > On 10/11/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > > David, > > > > Thanks for that write-up on the openejb itests. It helped me > > understand the structure better. > > > > All the client code (in src/itests) have a dependency on the beans (in > > src/java) anyway. So this is what I did. I put all the beans in 1 core > > project (openejb-itests). I put the plans and DDs in their individual > > projects. The individual projects then unpack just the needed classes > > from that core project and build the ejb archive with it's plan and > > DD. > > > > testsuite/ejbcontainer-testsuite > >ejb-modules > >openejb-itests <-- core project with beans > >openejb-security-001 <-- just plan and DD > >openejb-security-002 > >openejb-security-003 > >openejb-cmp2-prefetch > >openejb-cmp2-petstore > >openejb-cmp2-cmrmapping > >openejb-cmp2-storage > >test-ejbcontainer <--- junit tests in client > > Hi Prasad, > > Why are the matter being discussed here? Shouldn't it go to openejb-dev? > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.net.pl >
[jira] Commented: (GERONIMO-2413) Add a Certification Authority (CA) portlet to Geronimo console
[ http://issues.apache.org/jira/browse/GERONIMO-2413?page=comments#action_12441843 ] Hernan Cunico commented on GERONIMO-2413: - I am almost done testing with Tomcat on trunk (1.2). How do you remove/edit CA info once configured? > Add a Certification Authority (CA) portlet to Geronimo console > -- > > Key: GERONIMO-2413 > URL: http://issues.apache.org/jira/browse/GERONIMO-2413 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: console, security >Reporter: Vamsavardhana Reddy > Fix For: 1.2, 1.x > > Attachments: 02.ca-initialization-enter-details.JPG, > 07.issue-certificate-show-csr-details.JPG, > 09.issue-certificate-successful.JPG, GERONIMO-2413-revised.patch, > GERONIMO-2413.patch, GeronimoCA.zip > > > A Certification Authority portlet will be very useful. A full fledged CA may > be a long way to go. But what ever minimum function is required to process > CSR's etc. is not hard and the users can issue their own digital certificates > instead of getting trial certificates from some CA. -- 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-2490) Include Java enviroment info in Server and Client logfiles
[ http://issues.apache.org/jira/browse/GERONIMO-2490?page=all ] Donald Woods updated GERONIMO-2490: --- Attachment: G2490-1.1.x.patch Patch created against modules directory of 1.1.1 release. > Include Java enviroment info in Server and Client logfiles > -- > > Key: GERONIMO-2490 > URL: http://issues.apache.org/jira/browse/GERONIMO-2490 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Logging >Affects Versions: 1.x >Reporter: Donald Woods >Priority: Minor > Fix For: 1.1.2, 1.2 > > Attachments: G2490-1.1.x.patch > > > Add some informational logging of the Java environment being used for both > the Server and Client runtimes, so when users post a server.log or > client.log, all the basic Java info will be there. -- 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-2448) Add ServiceModules group in the JMX tree of the JMX portlet
[ http://issues.apache.org/jira/browse/GERONIMO-2448?page=all ] Christopher M. Cardona updated GERONIMO-2448: - Attachment: GERONIMO-2448_2471_2472-trunk.patch GERONIMO-2448.jpg The attached patch includes the fixes for GERONIMO-2448, GERONIMO-2471 and GERONIMO-2472. I combined the patches to avoid conflicts with other patches which modify the same files. I suggest that this patch be applied to get all the changes for the 3 jiras. Please check patch. Thanks. > Add ServiceModules group in the JMX tree of the JMX portlet > --- > > Key: GERONIMO-2448 > URL: http://issues.apache.org/jira/browse/GERONIMO-2448 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Reporter: Christopher M. Cardona > Assigned To: Christopher M. Cardona > Fix For: 1.2 > > Attachments: GERONIMO-2448.jpg, GERONIMO-2448_2471_2472-trunk.patch > > > Add ServiceModules group in the JMX tree of the JMX portlet. Adding this will > enable a user to list / view MBeans grouped by service modules as suggested > in the devlist - > http://www.mail-archive.com/dev@geronimo.apache.org/msg33687.html. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2490) Include Java enviroment info in Server and Client logfiles
Include Java enviroment info in Server and Client logfiles -- Key: GERONIMO-2490 URL: http://issues.apache.org/jira/browse/GERONIMO-2490 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Logging Affects Versions: 1.x Reporter: Donald Woods Priority: Minor Fix For: 1.1.2, 1.2 Add some informational logging of the Java environment being used for both the Server and Client runtimes, so when users post a server.log or client.log, all the basic Java info will be there. -- 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-2489) Client builder bug is blocking usage of Daytrader AppClient
[ http://issues.apache.org/jira/browse/GERONIMO-2489?page=all ] Donald Woods updated GERONIMO-2489: --- Attachment: G2489-1.1.1.patch Patch created against the modules/ directory of 1.1.1. > Client builder bug is blocking usage of Daytrader AppClient > --- > > Key: GERONIMO-2489 > URL: http://issues.apache.org/jira/browse/GERONIMO-2489 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: application client >Affects Versions: 1.1.1, 1.1 >Reporter: Donald Woods > Fix For: 1.1.2, 1.2 > > Attachments: G2489-1.1.1.patch > > > If you try to use the Daytrader app client, the following exception is thrown: > java -jar client.jar wasce-samples/daytrader-derby-tomcat_streamer.jar/1.1/car > 16:10:19,562 INFO [Log4jService] > -- > 16:10:19,562 INFO [Log4jService] Started Logging Service > 16:10:22,484 WARN [RMIRegistryService] RMI Registry failed > 16:10:22,500 ERROR [GBeanInstanceState] Error while starting; GBean is now in > th > e FAILED state: > abstractName="geronimo/rmi-naming/1.1/car?ServiceModule=geronimo > /rmi-naming/1.1/car,j2eeType=GBean,name=RMIRegistry" > java.rmi.server.ExportException: Port already in use: 1099; nested exception > is: > java.net.BindException: Address already in use: NET_Bind > at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:284) > at > sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219 > ) > at > sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398) > at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:131) > at > sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:19 > 5) > at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:107) > at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:93) > at > java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:1 > 98) > at > org.apache.geronimo.system.rmi.RMIRegistryService.doStart(RMIRegistry > Service.java:58) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI > nstance.java:981) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart > (GBeanInstanceState.java:267) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta > nceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G > BeanInstanceState.java:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI > nstance.java:540) > at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi > cKernel.java:379) > at > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio > nGBeans(ConfigurationUtil.java:374) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke > rnelConfigurationManager.java:187) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon > figuration(SimpleConfigurationManager.java:527) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon > figuration(SimpleConfigurationManager.java:508) > at > org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla > ssByCGLIB$$ce77a924.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod > Invoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio > n.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. > java:817) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 > 7) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat > ionInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro > xyMethodInterceptor.java:96) > at > org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ec0bda8e.s > tartConfiguration() > at > org.apache.geronimo.system.main.CommandLine.loadConfigurations(Comman > dLine.java:167) > at > org.apache.geronimo.system.main.CommandLine.invokeMainGBean(CommandLi > ne.java:92) > at > org.apache.geronimo.system.main.ClientCommandLine.(ClientComman > dLine.java:79) > at > org.apache.geronimo.system.main.ClientCommandLine.main(ClientCommandL > ine.java:49) > Caused by: > java.net.BindException: Address already in use: NET_Bind > at java.net.PlainSocketImpl.socketBind(Native Method) > at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:398) > at java.net.Server
[jira] Created: (GERONIMO-2489) Client builder bug is blocking usage of Daytrader AppClient
Client builder bug is blocking usage of Daytrader AppClient --- Key: GERONIMO-2489 URL: http://issues.apache.org/jira/browse/GERONIMO-2489 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: application client Affects Versions: 1.1.1, 1.1 Reporter: Donald Woods Fix For: 1.1.2, 1.2 If you try to use the Daytrader app client, the following exception is thrown: java -jar client.jar wasce-samples/daytrader-derby-tomcat_streamer.jar/1.1/car 16:10:19,562 INFO [Log4jService] -- 16:10:19,562 INFO [Log4jService] Started Logging Service 16:10:22,484 WARN [RMIRegistryService] RMI Registry failed 16:10:22,500 ERROR [GBeanInstanceState] Error while starting; GBean is now in th e FAILED state: abstractName="geronimo/rmi-naming/1.1/car?ServiceModule=geronimo /rmi-naming/1.1/car,j2eeType=GBean,name=RMIRegistry" java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use: NET_Bind at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:284) at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:219 ) at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:398) at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:131) at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:19 5) at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:107) at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:93) at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:1 98) at org.apache.geronimo.system.rmi.RMIRegistryService.doStart(RMIRegistry Service.java:58) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:527) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:508) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastCla ssByCGLIB$$ce77a924.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ec0bda8e.s tartConfiguration() at org.apache.geronimo.system.main.CommandLine.loadConfigurations(Comman dLine.java:167) at org.apache.geronimo.system.main.CommandLine.invokeMainGBean(CommandLi ne.java:92) at org.apache.geronimo.system.main.ClientCommandLine.(ClientComman dLine.java:79) at org.apache.geronimo.system.main.ClientCommandLine.main(ClientCommandL ine.java:49) Caused by: java.net.BindException: Address already in use: NET_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:398) at java.net.ServerSocket.bind(ServerSocket.java:331) at java.net.ServerSocket.(ServerSocket.java:197) at java.net.ServerSocket.(ServerSocket.java:109) at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMI DirectSocketFactory.java:46) at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMI MasterSocketFactory.java:350) at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:63 8) at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:272)
[jira] Updated: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Donald Woods updated GERONIMO-2377: --- Patch Info: [Patch Available] Fix Version/s: 1.2 Verified that the patch works. > deploying a new datasource with the same name does not indicate any problem > in the console > -- > > Key: GERONIMO-2377 > URL: http://issues.apache.org/jira/browse/GERONIMO-2377 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Bill Dudney > Fix For: 1.2 > > Attachments: GERONIMO-2377.bdudney.patch > > > Console acts as if it deployeed the datasource but the console spits out an > error message; > Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already > exists in the server. Try to undeploy it first or use the redeploy command. > org.apache.geronimo.common.DeploymentException: Module > console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to > undeploy it first or use the redeploy command. > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > 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:855) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:552) -- 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: DayTrader with an AJAX based Web interface
When I first loaded the initial page, it didn't look right in FireFox (text jumbled up a bit, etc.). However, I clicked refresh and it resolved the problem. After that, everything works perfectly. The interface is really cool. I'd like to see that patch get in soon, so the Geronimo world can contribute. Stan. Paul McMahan wrote: On 10/12/06, Christopher Blythe <[EMAIL PROTECTED]> wrote: Paul... Just read through the chain and the idea is sound... I like the idea of having a base dojo library accessible within the server, thus removing the burden on the developer of maintaining the dojo libraries within their code. Yes that's the idea, plus (hopefully) there is some performance improvement via browser caching when multiple apps share the same library. Plus, I don' t think there would be any conflicts if someone chose to do that in order to use newer builds of dojo, etc. My initial thinking on that has been that if an app needs a specific newer or older build of dojo then they could still include it in their war. Or they could deploy a new shared version at a different context, say /dojo-verX.Y.Z/dojo.js, but that could quickly get unmanageable.. The server's version of dojo would still be deployed at /dojo and support applications that are not as sensitive to version changes (see below). Just curious, would it be permissible for a developer to upgrade the dojo library inside the appserver on their own? Yes I think so, in the same way that an application might want to upgrade any other library in the server, say tranql for instance. Of course other applications and native components in the server that were using the old version would automatically start using the new version, so some care must be taken. Something else I just thought of... I wonder if there would be any impact on custom dojo widgets created by the developer. This is actually what I have done with the DayTrader interface. May be worth trying out... Ideally custom widgets could be contributed back to the Dojo foundation and show up in a later standard build of the library that gets incorporated into geronimo. But that's of course not always possible due to time constraints as well as there being cases where the custom widgets are not appropriately licensed for dojo or not reusable in a highly generalized kind of way. It would be interesting to find out if one could include customized widgets from their application's context while still using the shared library for the standard components. I think its possible by overriding certain parts of dojo's packaging mechanism but haven't tried it. Your idea for serving up customized builds sounds interesting; however, I'm not sure if there is currently a way to accurately detect all of the libraries that are used by an application. Based on my experience, you manually put together the list of libraries required for your build and then kick off ant. Let me poke around further and see what I can find out... If you pick up dojo from svn then they provide some build profiles that I think could be used for this purpose. http://svn.dojotoolkit.org/dojo/trunk/buildscripts/profiles/ There's a thread on this titled "dojo in Geronimo (long)" where this is being discussed. Best wishes, Paul
Re: Fixing javamail (again)
Jay D. McHugh wrote: Rick McGuire wrote: This problem can be easily corrected if we just switched the references to the javamail spec file to the geronimo-javamail_1.3_mail uber jar that contains the merged spec and provider classes. More and more users are tripping over this problem, which can be very easily corrected. Are there any objections to making this change in 1.2? I actually did a test of using javamail on the 1.2 snapshot and ended up putting in this dependency to make it work: org.apache.geronimo.configs javamail 1.2-SNAPSHOT car I don't know how that fits in with your suggestion though - but this did work for me. And that's generally the correct solution, although in the case I cited with Quartz, it wasn't enough to fix it because of the jar file split. A lot of users trip over this because the javamail spec jar is pulled in by other components (such as axix), without also pulling in the provider jar. The missing provider doesn't show up until they attempt to use the API and they get the exception. Rick Jay
Re: Spring in Geronimo 1.1.1
On Oct 11, 2006, at 10:20 PM, Aaron Mulder wrote: Let's say we were going to release a 1.1.2 and we were going to drop WADI, Spring, and ActiveCluster from the Jetty module in that release... Would that break anybody's heart? I can't see why that would cause any heart-breakage, at all... I'll volunteer to handle the TCK testing... --kevan
Re: Fixing javamail (again)
Rick McGuire wrote: This problem can be easily corrected if we just switched the references to the javamail spec file to the geronimo-javamail_1.3_mail uber jar that contains the merged spec and provider classes. More and more users are tripping over this problem, which can be very easily corrected. Are there any objections to making this change in 1.2? I actually did a test of using javamail on the 1.2 snapshot and ended up putting in this dependency to make it work: org.apache.geronimo.configs javamail 1.2-SNAPSHOT car I don't know how that fits in with your suggestion though - but this did work for me. Jay
[ANNOUNCE] Geronimo 1.1.1 Certified on Azul Compute Appliances
The Apache Geronimo Project is pleased to announce the J2EE 1.4 Certification of Apache Geronimo 1.1.1 running on an Azul Compute Appliance. The testing was performed on an Azul Compute Appliance Model 1920B (8 chip / 192 cores, 64GB memory) coupled with Azul VM release 2.3.1.2 (HotSpot™ Java™ 1.4.2_12), 64-bit Server mode. The Apache Geronimo Project wishes to thank Azul Systems for providing the machine time on the Azul Compute Appliance used for this certification efort. For more information on Azul Compute Appliances, please visit http://www.azulsystems.com. For more information on Apache Geronimo visit http://geronimo.apache.org.--kevan
[jira] Updated: (GERONIMO-2486) All plans should use 1.2 namespace
[ http://issues.apache.org/jira/browse/GERONIMO-2486?page=all ] Anita Kulshreshtha updated GERONIMO-2486: - Attachment: pom.patch configs.patch A property geronimoSchemaVersion is used and the plans are filtered by PlanProcessorMojo. > All plans should use 1.2 namespace > -- > > Key: GERONIMO-2486 > URL: http://issues.apache.org/jira/browse/GERONIMO-2486 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 > Environment: All >Reporter: Anita Kulshreshtha > Assigned To: Anita Kulshreshtha >Priority: Minor > Attachments: configs.patch, pom.patch > > > The plans are still using 1.1 namespace. Here is an example: > http://geronimo.apache.org/xml/ns/deployment-1.1";> > class="org.apache.geronimo.axis.builder.AxisBuilder"/> > class="org.apache.geronimo.axis.builder.AxisServiceRefBuilder"> > name="eeNamespaces">http://java.sun.com/xml/ns/j2ee > > xmlns="http://geronimo.apache.org/xml/ns/deployment-1.1";> > > > All plans must be updated to use 1.2 namespace. -- 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
Fixing javamail (again)
There have been 3 javamail questions on the user list in recent weeks about how to resolve a NoSuchProviderException trying to use SMTP. These problems all had the same root cause, having the javax.mail and the provider implementations in separate jar files. It's not obvious to most people that the dependency requirement exists and occasionally, even adding the dependency doesn't fix the problem. There was a recent problem of trying to use javamail from a Quartz job class where it was necessary to explicitly set the context classloader before requesting a transport instance to ensure the correct class loader was getting used. This was a situation that could not occur with the Sun javamail implementation because the api code and the providers are contained in the same jar file. This problem can be easily corrected if we just switched the references to the javamail spec file to the geronimo-javamail_1.3_mail uber jar that contains the merged spec and provider classes. More and more users are tripping over this problem, which can be very easily corrected. Are there any objections to making this change in 1.2? Rick
[jira] Updated: (GERONIMO-2404) Edit HTTPS Connector page does not display the connector name
[ http://issues.apache.org/jira/browse/GERONIMO-2404?page=all ] Donald Woods updated GERONIMO-2404: --- Patch looks good to me. > Edit HTTPS Connector page does not display the connector name > - > > Key: GERONIMO-2404 > URL: http://issues.apache.org/jira/browse/GERONIMO-2404 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1.1 > Environment: G 1.1.1 >Reporter: Vamsavardhana Reddy >Priority: Minor > Fix For: 1.2, 1.1.x, 1.1.2 > > Attachments: GERONIMO-2404-v1.1.x.patch, GERONIMO-2404-v1.2.patch, > GERONIMO-2404.patch > > > Edit HTTPS Connector page does not display the connector name while editing > an existing HTTPS connector. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2488) Improve "Install New Applications" portlet so you can choose the Network Listener
Improve "Install New Applications" portlet so you can choose the Network Listener - Key: GERONIMO-2488 URL: http://issues.apache.org/jira/browse/GERONIMO-2488 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 1.2 Reporter: Hernan Cunico Currently there are two fields, Archive and Plan for the "Install New Applications" portlet. As an improvement to this portlet, it would be useful if the user could select the network listener from a pull down list (one, many, all by default). This has been brought up a couple of times in the user list ( http://marc2.theaimsgroup.com/?l=geronimo-user&m=116066364519515&w=2 ) -- 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: DayTrader with an AJAX based Web interface
On 10/12/06, Christopher Blythe <[EMAIL PROTECTED]> wrote: Paul... Just read through the chain and the idea is sound... I like the idea of having a base dojo library accessible within the server, thus removing the burden on the developer of maintaining the dojo libraries within their code. Yes that's the idea, plus (hopefully) there is some performance improvement via browser caching when multiple apps share the same library. Plus, I don' t think there would be any conflicts if someone chose to do that in order to use newer builds of dojo, etc. My initial thinking on that has been that if an app needs a specific newer or older build of dojo then they could still include it in their war. Or they could deploy a new shared version at a different context, say /dojo-verX.Y.Z/dojo.js, but that could quickly get unmanageable.. The server's version of dojo would still be deployed at /dojo and support applications that are not as sensitive to version changes (see below). Just curious, would it be permissible for a developer to upgrade the dojo library inside the appserver on their own? Yes I think so, in the same way that an application might want to upgrade any other library in the server, say tranql for instance. Of course other applications and native components in the server that were using the old version would automatically start using the new version, so some care must be taken. Something else I just thought of... I wonder if there would be any impact on custom dojo widgets created by the developer. This is actually what I have done with the DayTrader interface. May be worth trying out... Ideally custom widgets could be contributed back to the Dojo foundation and show up in a later standard build of the library that gets incorporated into geronimo. But that's of course not always possible due to time constraints as well as there being cases where the custom widgets are not appropriately licensed for dojo or not reusable in a highly generalized kind of way. It would be interesting to find out if one could include customized widgets from their application's context while still using the shared library for the standard components. I think its possible by overriding certain parts of dojo's packaging mechanism but haven't tried it. Your idea for serving up customized builds sounds interesting; however, I'm not sure if there is currently a way to accurately detect all of the libraries that are used by an application. Based on my experience, you manually put together the list of libraries required for your build and then kick off ant. Let me poke around further and see what I can find out... If you pick up dojo from svn then they provide some build profiles that I think could be used for this purpose. http://svn.dojotoolkit.org/dojo/trunk/buildscripts/profiles/ There's a thread on this titled "dojo in Geronimo (long)" where this is being discussed. Best wishes, Paul
[jira] Created: (SM-706) FilePoller needs to add check for delete file before removing the file from workingset
FilePoller needs to add check for delete file before removing the file from
workingset
--
Key: SM-706
URL: https://issues.apache.org/activemq/browse/SM-706
Project: ServiceMix
Issue Type: Improvement
Components: servicemix-components
Affects Versions: 3.0
Environment: Windows XP/JSE 6
Reporter: Los Morales
Priority: Minor
Fix For: 3.0
In the "processFileAndDelete(File aFile)" method of the
org.apache.servicemix.components.file.FilePoller class, there is a finally
block that contains a call to " workingSet.remove(aFile)". This is called
regardless if the file should be deleted or not. Hence this works when the
file is physically removed. If the file is not physically removed but is
removed from the Set, this poller will pick up the same file(s) again and again
in the "pollFile(final File aFile)" method. Maybe add a check in the finally
block like this:
**
finally {
if (!aFile.exists())
workingSet.remove(aFile);
}
*
-los
--
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 integration steps
One option would be to distribute the service as a plugin. The initial process is the same in any case: - Implement the GBean - Create the plan (geronimo-service.xml) with any necessary dependencies - Package the GBean class(es) and optionally the plan into a JAR - Deploy the JAR to Geronimo as a new module From there, the process is a little different for plugins: - Using the console, create the plugin metadata file for the new module - Create a Maven 2 build with two modules -- one for the service as above, and one to create a plugin CAR out of the service JAR using the car-maven-plugin and the plugin metadata file above - Make sure all the dependencies are in a Maven 2 repository, referenced in the plugin metadata file - Test the plugin install on a clean Geronimo build That avoids needing to integrate the service into the assemblies directly. Bruce and I are working through building a new plugin for our talk at ApacheCon on Friday -- you can see the work in progress at https://svn.apache.org/repos/asf/geronimo/plugins/spring/trunk Thanks, Aaron On 10/11/06, Tim McConnell <[EMAIL PROTECTED]> wrote: I'm trying to figure out all the steps necessary to integrate a new component/service into Geronimo. Do these high-level tasks below seem generally accurate ?? And most importantly what else am I missing ?? Thanks much for reviewing. Tim 1. Implement a GBean to represent the deployed component with appropriate: a. Constructor b. Attributes c. References d. Operations e. Interfaces 2. Create the XML Plan with the appropriate deployment descriptors 3. Create the appropriate configuration file(s) 4. Implement a Module to contain the GBean 5. Implement the class loader for the Module 6. Create/implement any/all appropriate dependencies 7. Create the POM XML file(s) for integration into existing maven build 8. Test all assemblies (that contain the new component/service) 9. Others ??
Re: DayTrader with an AJAX based Web interface
Paul...Just read through the chain and the idea is sound... I like the idea of having a base dojo library accessible within the server, thus removing the burden on the developer of maintaining the dojo libraries within their code. Plus, I don' t think there would be any conflicts if someone chose to do that in order to use newer builds of dojo, etc. Just curious, would it be permissible for a developer to upgrade the dojo library inside the appserver on their own? Something else I just thought of... I wonder if there would be any impact on custom dojo widgets created by the developer. This is actually what I have done with the DayTrader interface. May be worth trying out... Your idea for serving up customized builds sounds interesting; however, I'm not sure if there is currently a way to accurately detect all of the libraries that are used by an application. Based on my experience, you manually put together the list of libraries required for your build and then kick off ant. Let me poke around further and see what I can find out... Chris On 10/12/06, Paul McMahan <[EMAIL PROTECTED]> wrote: Hey Chris this looks very impressive - great work! FYI the nextversion of Geronimo has a shared version of the Dojo library (kitchensink variety) deployed at /dojo. The admin console uses this sharedlibrary, see GERONIMO-2333 for details. Using this shared version of the library would allow you to avoidincluding it in your webapp, manage the library separately from yourapplication, and let browsers used cached versions of the libraryacross multiple webapps deployed in the server. If you can pick up one of the weekly 1.2-snapshot builds it should be pretty easy to hookthe shared version of Dojo into your app by replacing
Re: Geronimo integration steps
Hi Jacek, one I better understand the entire end-to-end process I'll certainly document it fully on the wiki. Thanks for the suggestion... Tim Jacek Laskowski wrote: On 10/12/06, Tim McConnell <[EMAIL PROTECTED]> wrote: 1. Implement a GBean to represent the deployed component with appropriate: a. Constructor b. Attributes c. References d. Operations e. Interfaces 2. Create the XML Plan with the appropriate deployment descriptors 3. Create the appropriate configuration file(s) 4. Implement a Module to contain the GBean 5. Implement the class loader for the Module That's quite confusing to me, likely because I have (never|rarely - cross out more appropriate adverb) done it before. 6. Create/implement any/all appropriate dependencies Isn't the step part of 2? 7. Create the POM XML file(s) for integration into existing maven build Do you mean integrate into Geronimo the server or Geronimo the build? 8. Test all assemblies (that contain the new component/service) 9. Others ?? Yes. Fix bugs that are reported by affected/interested parties ;-) The best approach is to give it a shot and see how it works. If it does work it doesn't mean it's the one and best approach, but the one who's worked. I'd be very very glad if I could read it on our Wiki. What do you think to put it there, Tim? Jacek
Re: svn commit: r463024 - in /geronimo/plugins/spring: branches/ tags/ trunk/ trunk/modules/ trunk/modules/spring-deployer-service/ trunk/modules/spring-deployer-service/src/ trunk/modules/spring-depl
On 10/12/06, Jason Dillon <[EMAIL PROTECTED]> wrote: GShell is one example: http://svn.apache.org/viewvc/geronimo/sandbox/gshell/trunk/ So is Plexus: http://svn.codehaus.org/plexus/trunk/ The main idea is to organize by functionality... not by type. Putting components under modules/* is not what I would recommend with m2. I created modules/* years ago to support the m1 build. Now that we are using m2, we should stop using the legacy project layout and instead organize components into logical groups based on functionality. Ah, that explains it so clearly. Thanks! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: DayTrader with an AJAX based Web interface
Hey Chris this looks very impressive - great work! FYI the next version of Geronimo has a shared version of the Dojo library (kitchen sink variety) deployed at /dojo. The admin console uses this shared library, see GERONIMO-2333 for details. Using this shared version of the library would allow you to avoid including it in your webapp, manage the library separately from your application, and let browsers used cached versions of the library across multiple webapps deployed in the server. If you can pick up one of the weekly 1.2-snapshot builds it should be pretty easy to hook the shared version of Dojo into your app by replacing with We would be very interested in getting feedback from you on this approach, especially since I believe your application is oriented towards measuring AJAX performance (at least that was my impression when Stan originally started this thread). Also, I realize you're using a custom Dojo build to speed up download time. We're looking into enabling the shared version of Dojo to serve up customized builds on the fly by invoking Dojo's built-in profile mechanism from a servlet in case you're interested in helping us look into that. Best wishes, Paul On 10/12/06, Christopher Blythe <[EMAIL PROTECTED]> wrote: All... I have posted a new revision of the Dojo UI for Daytrader at the following site... http://packattack.dyndns.org:8080/dojo_trader/daytrader.html Seems to be working without any major issues now on Firefox and IE; however, it does require the Flash plugin (may do some additional work to remove this dependency if possible). Here are some additional notes... - Upgraded to a 9/28 custom build of dojo to include newer widgets and hopefully reduce initial download time - Added refresh intervals for the current quote prices to the portfolio and buy quote panes - Quote prices updates and Market Summary updates are highlighted - Revised portfolio pane to handle incremental updates (versus a full table redraw on each buy/sell) - Packaged simple JSON to JAX-RPC proxy in ear with dojo impl Feel free to play around and let me know if you encounter any breaks or problems... I would also like to know if anyone has any suggestions for further improvements to the interface. Just for reference, you can access most of the javascript source directly inside the war via a browser... http://packattack.dyndns.org:8080/dojo_trader/ I have also placed the complete ear at the following location... http://packattack.dyndns.org:8080/dojo_trader/temp_storage/daytrader-dojo-ear.ear Thanks... Chris
Re: DayTrader with an AJAX based Web interface
Actually, I think it is in a fairly decent shape to start layering onto DayTrader... I have been working with a "custom" copy of the DayTrader code base and simply add the dojo interface along with the proxy in a separate ear (which I provided a link to in my previous email). Let me perform a base build of the DayTrader ear and make sure it works with that and get back to you... ChrisOn 10/12/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Hi Chris,Thanks for the update.I tried it with Safari (on Mac) and its a little confused :( I'm sure it should be fairly simple to get fixed for that environment too. I like what your doing and was wondering when you thought you might have a patch to start layering this into DayTrader? Remember, it doesn't have to be totally complete and there are others in the community that would love to help out. Cheers.On Oct 12, 2006, at 9:49 AM, Christopher Blythe wrote:All...I have posted a new revision of the Dojo UI for Daytrader at the following site... http://packattack.dyndns.org:8080/dojo_trader/daytrader.html Seems to be working without any major issues now on Firefox and IE; however, it does require the Flash plugin (may do some additional work to remove this dependency if possible). Here are some additional notes... - Upgraded to a 9/28 custom build of dojo to include newer widgets and hopefully reduce initial download time- Added refresh intervals for the current quote prices to the portfolio and buy quote panes- Quote prices updates and Market Summary updates are highlighted - Revised portfolio pane to handle incremental updates (versus a full table redraw on each buy/sell)- Packaged simple JSON to JAX-RPC proxy in ear with dojo implFeel free to play around and let me know if you encounter any breaks or problems... I would also like to know if anyone has any suggestions for further improvements to the interface. Just for reference, you can access most of the _javascript_ source directly inside the war via a browser... http://packattack.dyndns.org:8080/dojo_trader/ I have also placed the complete ear at the following location... http://packattack.dyndns.org:8080/dojo_trader/temp_storage/daytrader-dojo-ear.ear Thanks...ChrisOn 8/10/06, J. Stan Cox < [EMAIL PROTECTED]> wrote:It seems to have some issues even in Firefox. It is working for me about 1/2 the time. So, there's definitely some bugs to fix in this first pass, but when it works it looks really good. This (Web 2.0) is going to drastically change the server side load characteristics. I'm looking forward to digging into this more deeply. Stan. Jason Dillon wrote: This is definitely not happy in Safari :-( ... and when run from Camino it popped up a little dialog saying that the script was unresponsive, but telling it to continue eventually did display the UI. --jason On Aug 9, 2006, at 11:29 AM, Christopher Blythe wrote: All, Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.html FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance. This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks... Matt Hogstrom[EMAIL PROTECTED]
Re: DayTrader with an AJAX based Web interface
Hi Chris,Thanks for the update.I tried it with Safari (on Mac) and its a little confused :( I'm sure it should be fairly simple to get fixed for that environment too.I like what your doing and was wondering when you thought you might have a patch to start layering this into DayTrader? Remember, it doesn't have to be totally complete and there are others in the community that would love to help out.Cheers.On Oct 12, 2006, at 9:49 AM, Christopher Blythe wrote:All...I have posted a new revision of the Dojo UI for Daytrader at the following site...http://packattack.dyndns.org:8080/dojo_trader/daytrader.html Seems to be working without any major issues now on Firefox and IE; however, it does require the Flash plugin (may do some additional work to remove this dependency if possible). Here are some additional notes... - Upgraded to a 9/28 custom build of dojo to include newer widgets and hopefully reduce initial download time- Added refresh intervals for the current quote prices to the portfolio and buy quote panes- Quote prices updates and Market Summary updates are highlighted - Revised portfolio pane to handle incremental updates (versus a full table redraw on each buy/sell)- Packaged simple JSON to JAX-RPC proxy in ear with dojo implFeel free to play around and let me know if you encounter any breaks or problems... I would also like to know if anyone has any suggestions for further improvements to the interface. Just for reference, you can access most of the _javascript_ source directly inside the war via a browser...http://packattack.dyndns.org:8080/dojo_trader/ I have also placed the complete ear at the following location...http://packattack.dyndns.org:8080/dojo_trader/temp_storage/daytrader-dojo-ear.ear Thanks...ChrisOn 8/10/06, J. Stan Cox <[EMAIL PROTECTED]> wrote:It seems to have some issues even in Firefox. It is working for me about 1/2 the time. So, there's definitely some bugs to fix in this first pass, but when it works it looks really good. This (Web 2.0) is going to drastically change the server side load characteristics. I'm looking forward to digging into this more deeply. Stan. Jason Dillon wrote: This is definitely not happy in Safari :-( ... and when run from Camino it popped up a little dialog saying that the script was unresponsive, but telling it to continue eventually did display the UI. --jason On Aug 9, 2006, at 11:29 AM, Christopher Blythe wrote: All, Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.html FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance. This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks...Matt Hogstrom[EMAIL PROTECTED]
Re: DayTrader with an AJAX based Web interface
All...I have posted a new revision of the Dojo UI for Daytrader at the following site...http://packattack.dyndns.org:8080/dojo_trader/daytrader.html Seems to be working without any major issues now on Firefox and IE; however, it does require the Flash plugin (may do some additional work to remove this dependency if possible). Here are some additional notes... - Upgraded to a 9/28 custom build of dojo to include newer widgets and hopefully reduce initial download time- Added refresh intervals for the current quote prices to the portfolio and buy quote panes- Quote prices updates and Market Summary updates are highlighted - Revised portfolio pane to handle incremental updates (versus a full table redraw on each buy/sell)- Packaged simple JSON to JAX-RPC proxy in ear with dojo implFeel free to play around and let me know if you encounter any breaks or problems... I would also like to know if anyone has any suggestions for further improvements to the interface. Just for reference, you can access most of the _javascript_ source directly inside the war via a browser...http://packattack.dyndns.org:8080/dojo_trader/ I have also placed the complete ear at the following location...http://packattack.dyndns.org:8080/dojo_trader/temp_storage/daytrader-dojo-ear.ear Thanks...ChrisOn 8/10/06, J. Stan Cox <[EMAIL PROTECTED]> wrote: It seems to have some issues even in Firefox. It is working for me about 1/2 the time. So, there's definitely some bugs to fix in this first pass, but when it works it looks really good. This (Web 2.0) is going to drastically change the server side load characteristics. I'm looking forward to digging into this more deeply. Stan. Jason Dillon wrote: This is definitely not happy in Safari :-( ... and when run from Camino it popped up a little dialog saying that the script was unresponsive, but telling it to continue eventually did display the UI. --jason On Aug 9, 2006, at 11:29 AM, Christopher Blythe wrote: All, Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.html FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance. This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks...
[jira] Created: (AMQ-974) .Net client needs centralised trace facility
.Net client needs centralised trace facility Key: AMQ-974 URL: https://issues.apache.org/activemq/browse/AMQ-974 Project: ActiveMQ Issue Type: New Feature Components: NMS (C# client) Affects Versions: 4.0.2 Environment: Windows Reporter: Rob Lugt There are several classes within activemq-dotnet which need to write log/trace information. This data is currently written to an ad-hoc mixture of the Console and System.Diagnostics.Trace. Neither of these detinations are suitable because System.Diagnostics.Trace is not fully supported in the .Net compact framework and the Console is unsuitable for severl reasons - not least of which is that output is discarded in a Windows (i.e. non-console) application. There are two possible solutions to this problem 1) adopt log4net as the strategic logging/tracing platform 2) write our own Tracing interface which can be controlled at run-time to make use of any logging mechanism. Log4net is an attractive proposition because it is powerful, full-featured, reliable and is also an Apache incubator project. However, there is a strong desire to keep activemq-dotnet as clear as possible from any external dependencies. So far this has been successfull and as there is an alternative solution perhaps we should not create a dependency now. Creating a custom Tracing interface is attractive because it is stand-alone and allows the client application to plug-in whichever trace mechanism it requires. There don't seem to be many down sides to this solution, so I'll post a sample impementation shortly. -- 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: [jira] Created: (GERONIMO-2486) All plans should use 1.2 namespace
It is an excellent idea. The plans could define the namespace as follows: The filtering will be done by PlanProcessorMojo. ThanksAnitaJacek Laskowski <[EMAIL PROTECTED]> wrote: On 10/12/06, Anita Kulshreshtha (JIRA) wrote:> All plans should use 1.2 namespaceI've got an idea of using M2 filtering resources feature to achieveit, but am not quite sure it would work with all XML stuff (XSDs,etc.). Just a thought. If anyone could explain the problems one couldrun across while implementing it using filtering I'd appreciate it. OrI'll just wait patiently till Anita commits the change...Jacek-- Jacek Laskowskihttp://www.laskowski.net.pl Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail.
[jira] Commented: (AMQ-968) Store and Forward reconnect failures
[ https://issues.apache.org/activemq/browse/AMQ-968?page=comments#action_37172 ] Qiang-Kevin-Wang commented on AMQ-968: -- Good news, the Scenario #4 has been succeeded in Domain Log as well, now restarting the AS will automatically reconnect the store-forward AMQ with remote MS (s). I guess the reason is the store-forward broker (on MS) should disable the JMX or must guarantee the JMX is started correctly if JMX enabled. In previous failure of reconnection, the JMX of managed broker is not started successfully; but when I disable JMX on the broker (broker.setUseJmx(false)), the Scenario is okay! but it is still an issue that the client (store-forward) AMQ can not stop when the server AMQ is closed. > Store and Forward reconnect failures > > > Key: AMQ-968 > URL: https://issues.apache.org/activemq/browse/AMQ-968 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.2 > Environment: All >Reporter: Andy Piper > Attachments: jmstest.zip > > > For the AMQ reconnection issue, I think it is caused by client can not stop > the broker correctly after server broker is stopped. > Attached zip is the test case, it is an IDEA prj, to compile or run it the > incubator-activemq-4.0.jar (download from > http://people.apache.org/repository/incubator-activemq/jars/incubator-activemq-4.0.jar > ) should be involved. In the prj, I added two run configurations: Client, > Sever to try all kinds of connection scenarios below: > 1. Start client, then start server > 2. Start server, then start client > 3. Restart client > 4. Restart server > 5. Stop server, then stop client, after that restart server again, then > restart client > All scenarios will be successful if using the run configurations in IDEA, but > if we run the server and client in DOS command line, we will find the #5 is > failed. > Here is the reason, if the server broker is stopped, the client can not be > stopped using CTL + C, and the interrupt signal is always only captured by > the client broker rather than its JVM. In this time, if we restart the > server, no any messages can be received again. But the messages in client can > not be lost, after killing the client and restarting it, the messages can be > still sent to server. > So to the scenario in Domain Log, the managed server must be killed by kill-9 > shell and can not be stopped by shutdown.bat (sh) script. > Uunfortunately, the scenario #4 is still failed in Domain Log though the > codes are same with above test case's (it IS successful in the test case). I > can not get the reason after I struggled for it the whole day :(. I am not > sure if the AMQ network connector is impacted in Tomcat runtime env. -- 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: Build fails with SVN checkout
Hi, Here are the errors Maven reports. I have direct access to the Internet, no proxy. Where can I find the missing files for manual download? Regards, NGC ... 12.10.06. 08.59.54 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun -DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator-SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator-SNAPSHOT.jar ... 12.10.06. 09.54.13 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun -DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator-SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator-SNAPSHOT.jar ... 12.10.06. 10.06.18 CEST: Missing: -- 1) com.sun:tools:jar:1.4.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.sun -DartifactId=tools \ -Dversion=1.4.2 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.activemq:activemq-openwire-generator:jar:4.1-incubator-SNAPSHOT 2) com.sun:tools:jar:1.4.2 -- 1 required artifact is missing. for artifact: org.apache.activemq:activemq-openwire-generator-4.1-incubator-SNAPSHOT.jar -- View this message in context: http://www.nabble.com/Build-fails-with-SVN-checkout-tf2318351.html#a6772114 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: svn commit: r463024 - in /geronimo/plugins/spring: branches/ tags/ trunk/ trunk/modules/ trunk/modules/spring-deployer-service/ trunk/modules/spring-deployer-service/src/ trunk/modules/spring-depl
GShell is one example: http://svn.apache.org/viewvc/geronimo/sandbox/gshell/trunk/ So is Plexus: http://svn.codehaus.org/plexus/trunk/ The main idea is to organize by functionality... not by type. Putting components under modules/* is not what I would recommend with m2. I created modules/* years ago to support the m1 build. Now that we are using m2, we should stop using the legacy project layout and instead organize components into logical groups based on functionality. --jason On Oct 11, 2006, at 10:55 PM, Jacek Laskowski wrote: On 10/12/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I'd avoid making new projects that have a modules/* Just organize your modules in the root, or make modules to organize them into meaningful groups. I didn't get it. Could you show an example of it? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (SM-705) Static Parameter map injected into XsltComponent
Static Parameter map injected into XsltComponent Key: SM-705 URL: https://issues.apache.org/activemq/browse/SM-705 Project: ServiceMix Issue Type: New Feature Components: servicemix-components Affects Versions: 3.0.1 Environment: NA Reporter: Ramon Buckland Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.0.1 Attachments: xslt-parameters.patch This patch is an enhancement for the XsltComponent. We had a requirement whereby we wanted to inject a "System Variable" into the XSLT so we could use it's value as part of the transformation process. eg: java -Dsome.system.property=SomeValue In the servicemix.xml file where the XsltComponent is defined you can now add a map of parameters. And, as are properties on the JBI message added in, we also add these parameters to the XSLT. Of course you need to declare your intention to use the properties. A handy Hint, we use this in a real world by using the Spring PropertyPlaceholder, the properties files sit outside the SU's and SA's and we can then change "behaviour" really easily by adjusting our properties. http://xbean.org/schemas/spring/1.0";> classpath:myproperties.properties -- 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
