[jira] Updated: (GERONIMO-4582) Add Edit action forJMS Resource Parameters after create it
[ https://issues.apache.org/jira/browse/GERONIMO-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4582: --- Summary: Add Edit action forJMS Resource Parameters after create it (was: Can Edit JMS Resource Parameters after create it) > Add Edit action forJMS Resource Parameters after create it > -- > > Key: GERONIMO-4582 > URL: https://issues.apache.org/jira/browse/GERONIMO-4582 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.1.4, 2.2 > Environment: Any platfrom >Reporter: viola.lu >Priority: Minor > > In current G server, if i create a JMS resource, i should set all paramets > when create it, after creation, if i want to tune ActivMQ performance via set > Queue or topic PoolSize, i should delete this JMS resource, and re-create one > with different configuraiton.So improve edit action in JMS resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 1:26 AM, David Jencks wrote: I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. Why Scala? --jason
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 3:30 PM, David Jencks wrote: >> >> Right but that's an important problem which we run into all the time >> in Geronimo (same jar loaded by two different classloaders). And the >> solution to this problem is to create another >> configuration/classloader and make that the parent of the two. This is >> a pretty 'static' solution while osgi offers 'dynamic' solution where >> it figures out at runtime which packages to wire together. So >> Geronimo's and osgi's classloading models might be equivalent ONLY IF >> we support classloader-per-jar model. Hiding classes/packages in a >> classloader is not enough. > > Our classloading system does support classloader-per-jar right now, but we > haven't set up enough classloaders to act that way, and I'm hoping that osgi > will provide the same features with less work. Right, no argument there. > From a conceptual point of > view I don't see why osgi would be any more or less dynamic than geronimo. > The classes are coming out of some versioned jar and IMNSHO you are > unlikely to want to allow the resolution method to pick anything other than > the version of the jar for you. If you leave out the version in the > dependency geronimo will pick one for you... I'm not sure what the > equivalent osgi configuration would be. The point I was trying to make is that with Geronimo the classloader hierarchy is pretty much created/setup at build time while in osgi if you are using Import-Package is at runtime. Here's an example. Say, we have configuration A that has dependency on configuration B and C. Both B and C have dependency on commons-logging.jar. In Geronimo it would be very likely that you would run into ClassCastExceptions with such configuration. And the only way to fix it, it would be to create a new configuration D that would have the dependency on commons-logging.jar and B and C configurations would have to be updated to have dependency on D. In osgi world, bundle B and C would define a Import-Package on the commons-logging package and the osgi system at runtime would figure out that B and C must be wired to the same bundle that provides the commons-logging library. So classloader-per-jar is important and so is the runtime dependency resolution to make sure that the same library is not loaded from two different classloaders within the hierarchy. Hmm... I'm not sure what would happen if B and C used Require-Bundle and specify two different bundle names for libraries that provide the commons-logging library. Would we would see ClassCastExceptions (same as in Geronimo right now) or would osgi just pick one of these bundles as the default? Hmm... in Geronimo with artifact substitutions can we substitute jar for car or car for jar? > Basically it seems to me that osgi has the same problem as geronimo here, > that you have to include some really intrusive metadata in every jar to > specify the classloading behavior. Osgi has merely brainwashed everyone > into thinking that its metadata is desirable since its part of the manifest > whereas geronimo has some weird binary goo that no one is familiar with. > Maven does the same thing, packing the pom into every jar it builds (plus > supplying it alongside in the repository) > > So, everyone has the same problem -- you need a bunch of classloader > metadata associated with the artifacts you want to use -- and pretty much > agrees on the content, although each solution emphasizes different things. > IMO no one has a good solution yet. For instance AFAICT the felix bundle > maven plugin is typically used to effectively convert the maven artifact > dependencies to equivalent package import/export specifications. Yep, I agree. Jarek
[jira] Assigned: (GERONIMO-4516) Can't edit datasource and JMS Resource deployment plan in Data pool porlet of admin console
[ https://issues.apache.org/jira/browse/GERONIMO-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin reassigned GERONIMO-4516: -- Assignee: Gang Yin (was: Ivan) > Can't edit datasource and JMS Resource deployment plan in Data pool porlet of > admin console > --- > > Key: GERONIMO-4516 > URL: https://issues.apache.org/jira/browse/GERONIMO-4516 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.1.3, 2.2 >Reporter: viola.lu >Assignee: Gang Yin >Priority: Minor > > 1.Go to database pool, input a datasource name EmployeeDatasource, choose > system database driver > 2.Click Show Deployment Plan ,and it will display deployment plan including > the part below: > .. > > console.dbpool > test > 1.0 > rar > > . > 3.Click "edit setting" , you just edit information like database name, user > name ,password, But "console.dbpool" is fixed, > can't edit it.If you want to change this part , you should create a > datasource deployment plan and deploy it via tranql rar in command line. > This alos happens to JMS Resource porlet: > console.jms is fixed, can't edit it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4582) Can Edit JMS Resource Parameters after create it
Can Edit JMS Resource Parameters after create it Key: GERONIMO-4582 URL: https://issues.apache.org/jira/browse/GERONIMO-4582 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 2.1.4, 2.2 Environment: Any platfrom Reporter: viola.lu Priority: Minor In current G server, if i create a JMS resource, i should set all paramets when create it, after creation, if i want to tune ActivMQ performance via set Queue or topic PoolSize, i should delete this JMS resource, and re-create one with different configuraiton.So improve edit action in JMS resource. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
About daytrader patches
Hi folks, Is there anyone has time to help look at JIRA daytrader-63, 64, 65? Please help review and commit them if it's ok for us. If anything unclear, please comment on them. I will have more commits about daytrader for tomcat, for jboss4. Thanks! Forrest -- View this message in context: http://www.nabble.com/About-daytrader-patches-tp22469673s134p22469673.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4529: --- Attachment: fix-g4529-jeffyin.patch Instantiate an anonymous sub-class to solve the problem. > Corba port 1050 is not released after stopping j2ee-corba-yoko configuration > > > Key: GERONIMO-4529 > URL: https://issues.apache.org/jira/browse/GERONIMO-4529 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: CORBA >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP > JDK 1.5 > Geronimo 2.2 SNAPSHOT 20090202 >Reporter: Ivan >Assignee: Gang Yin > Fix For: 2.2 > > Attachments: fix-g4529-jeffyin.patch > > > After stopping the corba component in the console, port 1050 is not released. > Use command netstat or connect it with Eclipse Debug. Those two threads are > still running. > Yoko:Server:StartedThread. It seems it is still blocked on > ServerSocket.accept method. And I could not start the Corba service in the > admin console due to address already in use. > Thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681153#action_12681153 ] Gang Yin commented on GERONIMO-4529: Hi Ivan, Please help to review and commit the patch, thanks. > Corba port 1050 is not released after stopping j2ee-corba-yoko configuration > > > Key: GERONIMO-4529 > URL: https://issues.apache.org/jira/browse/GERONIMO-4529 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: CORBA >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP > JDK 1.5 > Geronimo 2.2 SNAPSHOT 20090202 >Reporter: Ivan >Assignee: Gang Yin > Fix For: 2.2 > > Attachments: fix-g4529-jeffyin.patch > > > After stopping the corba component in the console, port 1050 is not released. > Use command netstat or connect it with Eclipse Debug. Those two threads are > still running. > Yoko:Server:StartedThread. It seems it is still blocked on > ServerSocket.accept method. And I could not start the Corba service in the > admin console due to address already in use. > Thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4581) The batch file for deploying the ExampleClient.jar doesn't work.
[
https://issues.apache.org/jira/browse/GERONIMO-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ying Tang closed GERONIMO-4581.
---
Resolution: Fixed
Fix Version/s: 2.1
2.2
Thanks, Shawn. The command could be:
{{jar cvfm app_client.jar
D:\workspace2\GERONIMO_APPLICATION\bin\your_manifest_file_name -C
D:\workspace2\GERONIMO_APPLICATION\bin .}}
to specify the MANIFEST file.
Or
{{jar cvfM app_client.jar -C D :\workspace2\GERONIMO_APPLICATION\bin .}}
Doc updated. Closing this bug.
> The batch file for deploying the ExampleClient.jar doesn't work.
>
>
> Key: GERONIMO-4581
> URL: https://issues.apache.org/jira/browse/GERONIMO-4581
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: documentation
>Affects Versions: 2.1, 2.2
> Environment: IBM JDK 6 + Windows XP SP3
>Reporter: Ying Tang
>Priority: Trivial
> Fix For: 2.2, 2.1
>
>
> http://cwiki.apache.org/confluence/display/GMOxDOC22/Deploying+and+running+Java+EE+application+client
> The .bat file in this page for deploying the application client doesn'w work,
> as the command "jar" for packing the .jar file has incorrect format:
> jar -cfM app_client.jar -C D:\workspace2\GERONIMO_APPLICATION\bin .
> we can locate the batch file in the application home directory, where there
> should be a META-INF folder and class files (class files can be in its
> subdirectory), and use this syntax:
> jar cfM app_client.jar *
> Does anybody know how to specify the directory in the batch file? The -C
> option doesn't work.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 752699
Geronimo Revision: 752699 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090311/build-2100.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090311
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 36 minutes 41 seconds
[INFO] Finished at: Wed Mar 11 21:41:58 EDT 2009
[INFO] Final Memory: 675M/978M
[INFO]
TESTSUITE RESULTS (Failures only)
=
See detailed results at
http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html
Assembly: tomcat
=
See the full test.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090311/logs-2100-tomcat/test.log
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:2.2-SNAPSHOT: checking
for updates from codehaus-snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:40.718
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/2.2-SNAPSHOT/testsuite-2.2-SNAPSHOT.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:00:59.303)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:28.190)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:33.416)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:16.195)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:23.981)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:19.892)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:01:42.635)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:49.070)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:48.515)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:42.157)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:30.431)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:31.498)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:33.344)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:47.860)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:00:54.731)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:59.277)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:26.784)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:48.616)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security FAILURE (0:00:37.259) Java
returned: 1
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:30.135)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-sysdb.patch > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, js-localization-sysdb.patch, screenshot-1.jpg, > screenshot-2.jpg, screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: jsp-localization-activemq.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-openejb.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-sysdb.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: (was: js-localization-console.patch) > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4517) Apply unified message display style(G-4484) to javascript alert messages. Together with the localization of these messages.
[ https://issues.apache.org/jira/browse/GERONIMO-4517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin updated GERONIMO-4517: --- Attachment: js-localization-openejb.patch js-localization-activemq.patch js-localization-console.patch > Apply unified message display style(G-4484) to javascript alert messages. > Together with the localization of these messages. > --- > > Key: GERONIMO-4517 > URL: https://issues.apache.org/jira/browse/GERONIMO-4517 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Gang Yin >Assignee: Ivan >Priority: Minor > Fix For: 2.2 > > Attachments: js-localization-activemq.patch, > js-localization-console.patch, js-localization-core.patch, > js-localization-openejb.patch, screenshot-1.jpg, screenshot-2.jpg, > screenshot-3.jpg > > > Currently all the messages generated from backend is displayed in a unified > manner(G-4484), but frontend javascript use alert boxes to display all kinds > of messages without distinguishing their types(e.g. error, warn, info), and > the UX of alert boxes is not so good, so I'm going to extend the unified > message display style of backend messages to frontend messages. Also, the > localization work will be done meantime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4529) Corba port 1050 is not released after stopping j2ee-corba-yoko configuration
[ https://issues.apache.org/jira/browse/GERONIMO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yin reassigned GERONIMO-4529: -- Assignee: Gang Yin > Corba port 1050 is not released after stopping j2ee-corba-yoko configuration > > > Key: GERONIMO-4529 > URL: https://issues.apache.org/jira/browse/GERONIMO-4529 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: CORBA >Affects Versions: 2.1.4, 2.2 > Environment: Windows XP > JDK 1.5 > Geronimo 2.2 SNAPSHOT 20090202 >Reporter: Ivan >Assignee: Gang Yin > Fix For: 2.2 > > > After stopping the corba component in the console, port 1050 is not released. > Use command netstat or connect it with Eclipse Debug. Those two threads are > still running. > Yoko:Server:StartedThread. It seems it is still blocked on > ServerSocket.accept method. And I could not start the Corba service in the > admin console due to address already in use. > Thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: EJB 3.1 PFD2 is up for download
On Mar 11, 2009, at 1:09 PM, David Jencks wrote:
On Mar 11, 2009, at 12:27 PM, David Blevins wrote:
The JSR #318 Expert Group has put another Proposed Final Draft
(PFD) up for download:
Enterprise JavaBeans 3.1
http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
Note this is still a draft and no the final spec.
Have a look at chapter 22 and see if anything feels familiar.
Essentially this:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
Context context = new InitialContext(p);
Movies movies = (Movies) context.lookup("MoviesLocal");
Becomes this:
Properties p = new Properties();
p.put("javax.ejb.embeddable.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
How do you get from a driver to a datasource?
Just using commons-dbcp. Better said (which I think is the real
question) the properties starting with 'javax.ejb' are standard
properties, the rest are vendor specific.
-David
Re: EJB 3.1 PFD2 is up for download
On Mar 11, 2009, at 12:27 PM, David Blevins wrote:
The JSR #318 Expert Group has put another Proposed Final Draft (PFD)
up for download:
Enterprise JavaBeans 3.1
http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
Note this is still a draft and no the final spec.
Have a look at chapter 22 and see if anything feels familiar.
Essentially this:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
Context context = new InitialContext(p);
Movies movies = (Movies) context.lookup("MoviesLocal");
Becomes this:
Properties p = new Properties();
p.put("javax.ejb.embeddable.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
How do you get from a driver to a datasource?
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
EJBContainer container = EJBContainer.createEJBContainer(p);
Context context = container.getContext();
Movies movies = (Movies) context.lookup("MoviesLocal");
pretty simple :-)
david jencks
-David
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 20:30, David Jencks wrote: > > On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote: > > On Wed, Mar 11, 2009 at 1:29 PM, David Jencks >> wrote: >> >>> >>> On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: >>> >>> Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. >>> >>> I agree. I doubt Guillaume has seen your additions to classloading in >>> trunk >>> which allow you to not export packages from a classloader. I haven't >>> tried >>> to prove it mathematically but I think that with this feature the >>> classloading models for geronimo and osgi are equivalent in that you can >>> express the same ability to access classes with either of them. Of >>> course, >>> the notation you use to express this and the specific information >>> included >>> in the configuration is different. >>> >>> I think I probably have the most experience with classloading problems in >>> geronimo and the only real problem that arises is loading a jar in two >>> different classloaders. This can be solved by a classloader-per-jar >>> model >>> which offers no theoretical problems to set up in geronimo but >>> practically >>> would take a lot of work (and maven projects to build a plugin per jar). >>> So >>> I think we'll have to see what kind of problems we get with trying to >>> actually use OSGI. >>> >> >> Right but that's an important problem which we run into all the time >> in Geronimo (same jar loaded by two different classloaders). And the >> solution to this problem is to create another >> configuration/classloader and make that the parent of the two. This is >> a pretty 'static' solution while osgi offers 'dynamic' solution where >> it figures out at runtime which packages to wire together. So >> Geronimo's and osgi's classloading models might be equivalent ONLY IF >> we support classloader-per-jar model. Hiding classes/packages in a >> classloader is not enough. >> > > Our classloading system does support classloader-per-jar right now, but we > haven't set up enough classloaders to act that way, and I'm hoping that osgi > will provide the same features with less work. From a conceptual point of > view I don't see why osgi would be any more or less dynamic than geronimo. > The classes are coming out of some versioned jar and IMNSHO you are > unlikely to want to allow the resolution method to pick anything other than > the version of the jar for you. If you leave out the version in the > dependency geronimo will pick one for you... I'm not sure what the > equivalent osgi configuration would be. > > Basically it seems to me that osgi has the same problem as geronimo here, > that you have to include some really intrusive metadata in every jar to > specify the classloading behavior. Osgi has merely brainwashed everyone > into thinking that its metadata is desirable since its part of the manifest > whereas geronimo has some weird binary goo that no one is familiar with. > Maven does the same thing, packing the pom into every jar it builds (plus > supplying it alongside in the repository) > > So, everyone has the same problem -- you need a bunch of classloader > metadata associated with the artifacts you want to use -- and pretty much > agrees on the content, although each solution emphasizes different things. > IMO no one has a good solution yet. For instance AFAICT the felix bundle > maven plugin is typically used to effectively convert the maven artifact > dependencies to equivalent package import/export specifications. > FWIW, the bundle plugin does not really use maven dependencies. What happens is that the code that goes inside the osgi bundle is introspected to find all the list of all packages that are needed. This list is then converted into the OSGi manifest import along with any additional constraints or modification of those default constrainst. At some point (not sure if this has been done yet), maven optional dependencies should be used to specify optional package imports, but even if you mi
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 11:27 AM, Jarek Gawor wrote: On Wed, Mar 11, 2009 at 1:29 PM, David Jencks wrote: On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/ import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per- jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. Right but that's an important problem which we run into all the time in Geronimo (same jar loaded by two different classloaders). And the solution to this problem is to create another configuration/classloader and make that the parent of the two. This is a pretty 'static' solution while osgi offers 'dynamic' solution where it figures out at runtime which packages to wire together. So Geronimo's and osgi's classloading models might be equivalent ONLY IF we support classloader-per-jar model. Hiding classes/packages in a classloader is not enough. Our classloading system does support classloader-per-jar right now, but we haven't set up enough classloaders to act that way, and I'm hoping that osgi will provide the same features with less work. From a conceptual point of view I don't see why osgi would be any more or less dynamic than geronimo. The classes are coming out of some versioned jar and IMNSHO you are unlikely to want to allow the resolution method to pick anything other than the version of the jar for you. If you leave out the version in the dependency geronimo will pick one for you... I'm not sure what the equivalent osgi configuration would be. Basically it seems to me that osgi has the same problem as geronimo here, that you have to include some really intrusive metadata in every jar to specify the classloading behavior. Osgi has merely brainwashed everyone into thinking that its metadata is desirable since its part of the manifest whereas geronimo has some weird binary goo that no one is familiar with. Maven does the same thing, packing the pom into every jar it builds (plus supplying it alongside in the repository) So, everyone has the same problem -- you need a bunch of classloader metadata associated with the artifacts you want to use -- and pretty much agrees on the content, although each solution emphasizes different things. IMO no one has a good solution yet. For instance AFAICT the felix bundle maven plugin is typically used to effectively convert the maven artifact dependencies to equivalent package import/ export specifications. To me it seems like there are two opposing forces at work here. On the one hand you want your code to be able to run in a variety of environments. On the other hand you want to be able to know and specify stuff about the environment. The environment basically boils down to a graph of a bunch of jars. (with osgi, the classes you specifiy in import/export requirements are in fact coming from some jar, somewhere). So how are you going to specify that graph? How are you going to make it flexible? What's the boundary between your app and the outside world? Maven and geronimo deal with this by having your app specify the jars it wants and by allowing some way to substitute jars (artifact-aliases in geronimo, exclusions in maven). osgi lets yo
EJB 3.1 PFD2 is up for download
The JSR #318 Expert Group has put another Proposed Final Draft (PFD)
up for download:
Enterprise JavaBeans 3.1
http://jcp.org/aboutJava/communityprocess/pfd/jsr318/index.html
Note this is still a draft and no the final spec.
Have a look at chapter 22 and see if anything feels familiar.
Essentially this:
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
Context context = new InitialContext(p);
Movies movies = (Movies) context.lookup("MoviesLocal");
Becomes this:
Properties p = new Properties();
p.put("javax.ejb.embeddable.initial",
"org.apache.openejb.client.LocalInitialContextFactory");
p.put("movieDatabase", "new://Resource?type=DataSource");
p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource");
p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver");
p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb");
p.put("movieDatabaseUnmanaged.JtaManaged", "false");
EJBContainer container = EJBContainer.createEJBContainer(p);
Context context = container.getContext();
Movies movies = (Movies) context.lookup("MoviesLocal");
-David
Re: maven-xbean-plugin
Is this the right list to discuss such things? yes Greate. First I must say that I don't have much knowledge about the xbean project yet but we're using the maven-xbean-plugin in the directory project. Looking for some documentation I came across XBEAN Jira. To understand how things work it may be helpfull to look into the code and see how it works. As I found some spare time I tried to improve my knowledge about site report generation using maven and thought that one of the issues could be a good point to hit both targets a little bit. Do you thing that my submitted patches are in the right direction to help to improve the plugin (if you find some time for reviewing)? Regards Felix
Branch created for geronimo-jpa_2.0_spec-1.0-EA
In preparation for a new public draft/release review of the JPA 2.0 Spec, I've created a branch for the current Spec at: https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jpa_2.0_spec-1.0-EA/ This will allow the OpenJPA 2.0.0-M1 branch to continue to be built, based on Public Draft #1 of the spec. The trunk will be updated to 1.0.1-EA-SNAPSHOT, until we see if the next review is called a Draft or not. If it is a release preview, then we may change it to 1.0-SNAPSHOT instead. -Donald
[jira] Updated: (XBEAN-72) Plugin needs to implement MavenReport
[ https://issues.apache.org/jira/browse/XBEAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated XBEAN-72: -- Attachment: report-1.diff Some improvements against my first diff - add some docu for site generation - use less hardcoded paths but the ones used/defined for maven in general (like src-/build directory) - make GeneratorPlugin configurable -> Exept some mandatory plugins (Xsd, XmlMeta) the plugins are now configurable by adding a comma seperated list to the configuration section of the maven-xbean-plugin configuration section in the pom. Custom GeneratorPlugins must implement the GeneratorPlugin interface and be avaliable in the classpath. For default configuration see also the generated site (cd maven-xbean-plugin, mvn site) > Plugin needs to implement MavenReport > - > > Key: XBEAN-72 > URL: https://issues.apache.org/jira/browse/XBEAN-72 > Project: XBean > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 2.8 >Reporter: Kohsuke Kawaguchi > Attachments: report-1.diff > > > The HTML files that the maven-xbean-plugin generates are very useful inside > the site HTML files. > If the plugin provides MavenReport, then this could happen automatically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (XBEAN-72) Plugin needs to implement MavenReport
[ https://issues.apache.org/jira/browse/XBEAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated XBEAN-72: -- Attachment: (was: report.diff) > Plugin needs to implement MavenReport > - > > Key: XBEAN-72 > URL: https://issues.apache.org/jira/browse/XBEAN-72 > Project: XBean > Issue Type: New Feature > Components: maven-plugin >Affects Versions: 2.8 >Reporter: Kohsuke Kawaguchi > > The HTML files that the maven-xbean-plugin generates are very useful inside > the site HTML files. > If the plugin provides MavenReport, then this could happen automatically. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (XBEAN-124) Create documentation as xml file
[ https://issues.apache.org/jira/browse/XBEAN-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated XBEAN-124: --- Attachment: xbean-spring-1.diff Some more smaller changes to make the maven-xbean-plugin more generic > Create documentation as xml file > > > Key: XBEAN-124 > URL: https://issues.apache.org/jira/browse/XBEAN-124 > Project: XBean > Issue Type: Sub-task > Components: maven-plugin > Environment: all >Reporter: Felix Knecht >Priority: Minor > Attachments: xbean-spring-1.diff > > > Create a xml file to make processing and generation of a report easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 1:29 PM, David Jencks wrote: > > On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: > >> Hi, >> >> So let's agree to disagree for now. This may be related to my personal way >> of comparing stuff which is pretty much limited to: >> 1. understand what the requirements are. >> 2. understand how the technologies support these requirements. I do not >> need all the bells and whistles that a technology offers to fulfill the >> requirements. Moreover comparing stuff based on technology differentiators >> not clearly linked to the requirements is pointless. >> 3. assess best way forward based on above scoring. >> >> Key steps are 1 and 2 where stuff offering all the bells and whistles may >> well be scored as good as other stuff (I clearly do not support over-bloated >> stuff...). >> >> Obviously, I am keen to be proven wrong and adjust accordingly. So far, I >> am still saying that the main challenge is to properly tune export/import of >> dependency declarations. For me, the technology is not the core issue and >> switching is not going to resolve problems. > > I agree. I doubt Guillaume has seen your additions to classloading in trunk > which allow you to not export packages from a classloader. I haven't tried > to prove it mathematically but I think that with this feature the > classloading models for geronimo and osgi are equivalent in that you can > express the same ability to access classes with either of them. Of course, > the notation you use to express this and the specific information included > in the configuration is different. > > I think I probably have the most experience with classloading problems in > geronimo and the only real problem that arises is loading a jar in two > different classloaders. This can be solved by a classloader-per-jar model > which offers no theoretical problems to set up in geronimo but practically > would take a lot of work (and maven projects to build a plugin per jar). So > I think we'll have to see what kind of problems we get with trying to > actually use OSGI. Right but that's an important problem which we run into all the time in Geronimo (same jar loaded by two different classloaders). And the solution to this problem is to create another configuration/classloader and make that the parent of the two. This is a pretty 'static' solution while osgi offers 'dynamic' solution where it figures out at runtime which packages to wire together. So Geronimo's and osgi's classloading models might be equivalent ONLY IF we support classloader-per-jar model. Hiding classes/packages in a classloader is not enough. Jarek
[jira] Updated: (XBEAN-124) Create documentation as xml file
[ https://issues.apache.org/jira/browse/XBEAN-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated XBEAN-124: --- Attachment: (was: xbean-spring.diff) > Create documentation as xml file > > > Key: XBEAN-124 > URL: https://issues.apache.org/jira/browse/XBEAN-124 > Project: XBean > Issue Type: Sub-task > Components: maven-plugin > Environment: all >Reporter: Felix Knecht >Priority: Minor > > Create a xml file to make processing and generation of a report easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 12:57 AM, Gianny Damour wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/ import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. thanks david jencks If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of "from the bottom". Another approach to many of these issues is perhaps "from the top", from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The "init" method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended me
Lets use nexus and hudson and auto-publish snapshots
Apparently it is now possible to build on apache's hudson instance and arrange for successful builds to be pushed automatically to the apache nexus instance (cxf has set this up) I think we should do this also. This would depend on first changing our poms to deploy to the nexus instance as discussed earlier. Are the current automated builds that Jarek runs pushing snapshots to apache snapshot repo? thoughts? thanks david jencks
Re: maven-xbean-plugin
On Mar 11, 2009, at 6:09 AM, Felix Knecht wrote: Hi all I'd like to do some contibutions/improvements to the maven-xbean- plugin. Is this the right list to discuss such things? yes thanks david jencks Regards Felix
Re: Whence the geronimo kernel?
On Mar 11, 2009, at 1:46 AM, Gianny Damour wrote: Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. I agree. I doubt Guillaume has seen your additions to classloading in trunk which allow you to not export packages from a classloader. I haven't tried to prove it mathematically but I think that with this feature the classloading models for geronimo and osgi are equivalent in that you can express the same ability to access classes with either of them. Of course, the notation you use to express this and the specific information included in the configuration is different. I think I probably have the most experience with classloading problems in geronimo and the only real problem that arises is loading a jar in two different classloaders. This can be solved by a classloader-per- jar model which offers no theoretical problems to set up in geronimo but practically would take a lot of work (and maven projects to build a plugin per jar). So I think we'll have to see what kind of problems we get with trying to actually use OSGI. One thing I'd really like actual user data on is how people actually specify osgi classloading info in real life. I'm very aware that in theory you are supposed to specify the package imports and exports for your bundle but I've been told that in real life everyone with a serious osgi project actually specifies the jar dependencies they want using require-bundle. thanks david jencks Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour > wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style
[jira] Resolved: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved GERONIMO-4579.
---
Resolution: Fixed
Fix Version/s: 2.2
2.1.4
The problem was really witch creating the zip file and not extracting it.
Anyway, committed the fixes to trunk (revision 752493), branches/2.1 (revision
752494) and branches/2.1.4 (revision 752506). Thanks for the patch!
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4, 2.2
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
>Assignee: Jarek Gawor
> Fix For: 2.1.4, 2.2
>
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680889#action_12680889
]
Jarek Gawor commented on GERONIMO-4579:
---
Shawn,
When submitting a patch make sure it does not change the formatting of the file
(even though the formatting of the original file might be wrong) because it is
hard to see the particular changes.
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4, 2.2
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
>Assignee: Jarek Gawor
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
maven-xbean-plugin
Hi all I'd like to do some contibutions/improvements to the maven-xbean-plugin. Is this the right list to discuss such things? Regards Felix
[jira] Updated: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor updated GERONIMO-4579:
--
Affects Version/s: 2.2
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4, 2.2
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
>Assignee: Jarek Gawor
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor reassigned GERONIMO-4579:
-
Assignee: Jarek Gawor
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
>Assignee: Jarek Gawor
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of "from the bottom". Another approach to many of these issues is perhaps "from the top", from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The "init" method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. Don't fall into the trap of thinking of the blueprint service as just a "bean assembler". There's a lot more going on in the runtime beyond just creating class instances and injecting dependencies. There are different sorts of lifecyle considerations (lazy-init, prototype scope), as well as all of the work that goes into supporting the dynamics of the OSGi service registry. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. I thnk it will be too! thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import-bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really well ee6 dependency injection. EE6 is going to have a pretty sophisticated dependency injection service which we'll need to support anyway. We should try to figure out how much of the core we can assemble using it. Other great stuff we have: xbean-reflect, xbean-finder, xbean-spring These ideas have been floating around in my head for a long time and I've chatted with various people about them occasionally. While more discussion is certainly needed on everything here I need to do some implementation to understand much more. So, what I'm planning to do: Dave's crazy work plan... - Try to use the osgi classloader. I think this involves putting the classloader creation in Configuration into a service. Configurations will turn into osgi bundles. I'll put the Kernel in the osgi ServiceRegistry so the Configuration
Re: Whence the geronimo kernel?
Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour mailto:gianny.dam...@optusnet.com.au>> wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). I have to agree with Guillaume on this. A lot of the difficulties that people run into with trying to configure the classloading options on Geronimo can become non-issues under the OSGi model. Those sorts of problems are handled automatically by the OSGi framework. On the downside, a lot more work needs to go into specifying the package dependencies. This can make "bundlizing" a jar an interesting exercise the first time. OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... OSGi is definitely moving in that direction. There are a number of RFCs in the works for how that sort of autodiscovery should behave running on an OSGi framework. The new blueprint service will provide a native application assembly model, and other RFCs cover discovering/running different types of JEE application types. I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of "from the bottom". Another approach to many of these issues is perhaps "from the top", from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The "init" method could deal
[jira] Commented: (GERONIMO-4581) The batch file for deploying the ExampleClient.jar doesn't work.
[ https://issues.apache.org/jira/browse/GERONIMO-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680827#action_12680827 ] Shawn Jiang commented on GERONIMO-4581: --- Try this to include your manifest file in jar file: jar cvfm app_client.jar D:\workspace2\GERONIMO_APPLICATION\bin\your_manifest_file_name -C :\workspace2\GERONIMO_APPLICATION\bin . > The batch file for deploying the ExampleClient.jar doesn't work. > > > Key: GERONIMO-4581 > URL: https://issues.apache.org/jira/browse/GERONIMO-4581 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: documentation >Affects Versions: 2.1, 2.2 > Environment: IBM JDK 6 + Windows XP SP3 >Reporter: Ying Tang >Priority: Trivial > > http://cwiki.apache.org/confluence/display/GMOxDOC22/Deploying+and+running+Java+EE+application+client > The .bat file in this page for deploying the application client doesn'w work, > as the command "jar" for packing the .jar file has incorrect format: > jar -cfM app_client.jar -C D:\workspace2\GERONIMO_APPLICATION\bin . > we can locate the batch file in the application home directory, where there > should be a META-INF folder and class files (class files can be in its > subdirectory), and use this syntax: > jar cfM app_client.jar * > Does anybody know how to specify the directory in the batch file? The -C > option doesn't work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-562) Can't install plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Zhang updated GERONIMODEVTOOLS-562: Attachment: 562.patch Unzip the car files when copy them to the Repository. > Can't install plugin via GEP > > > Key: GERONIMODEVTOOLS-562 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-562 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:win 2003 JDK: 1.6 >Reporter: viola.lu >Assignee: Tim McConnell > Attachments: 562.patch, sample-plugins.zip > > > Steps: > 1.Extract attached sample plugin file > 2.In eclipse, right-click g server , choose "open" and click "convert app > to plugin", choose sample plugin location as local repository and click next, > but no plugin is listed > to install, so this also result in summary page can't display for server > plugin manger > But i can install it via admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Zhang updated GERONIMODEVTOOLS-564: Attachment: (was: GeronimoServerPluginManager.java) > Fail to create plugin via GEP > - > > Key: GERONIMODEVTOOLS-564 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:wind2003 jdk:1.5 >Reporter: viola.lu >Assignee: Tim McConnell > Attachments: 564.patch > > > Steps: > 1.Define a G server runtime, and right-click to open it > 2.Open "plugin" page, click "convert app to plugin"->choose any item you > would like->next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Zhang updated GERONIMODEVTOOLS-564: Attachment: GeronimoServerPluginManager.java It seems something wrong with the 'getGBean' method used in GeronimoServerPluginManager when trying to init the PluginInstaller, but I still do not know the reason exactly. Now I used Proxy instead, and it works fine. > Fail to create plugin via GEP > - > > Key: GERONIMODEVTOOLS-564 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:wind2003 jdk:1.5 >Reporter: viola.lu >Assignee: Tim McConnell > Attachments: 564.patch > > > Steps: > 1.Define a G server runtime, and right-click to open it > 2.Open "plugin" page, click "convert app to plugin"->choose any item you > would like->next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Zhang updated GERONIMODEVTOOLS-564: Attachment: 564.patch It seems something wrong with the 'getGBean' method used in GeronimoServerPluginManager when trying to init the PluginInstaller, but I still do not know the reason exactly. Now I used Proxy instead, and it works fine. > Fail to create plugin via GEP > - > > Key: GERONIMODEVTOOLS-564 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:wind2003 jdk:1.5 >Reporter: viola.lu >Assignee: Tim McConnell > Attachments: 564.patch > > > Steps: > 1.Define a G server runtime, and right-click to open it > 2.Open "plugin" page, click "convert app to plugin"->choose any item you > would like->next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680819#action_12680819
]
Shawn Jiang commented on GERONIMO-4579:
---
The file in the snapshot is a flatten long file:
"WEB-INF\classes\java"
But it should be just a short file xxx.java under directories like this;
Web-INF
-classes
xxx.java
This only happens when deploying a cluster with one farm node on windows and
the other on linux/unix. I guess this is caused by "RMI + different
file.separator" .
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to a
[jira] Updated: (GERONIMODEVTOOLS-560) Can't Add or Remove AppClient Project via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai updated GERONIMODEVTOOLS-560: --- Attachment: 560_trunk_new.patch 560_214branch_new.patch The patch "560_214branch.patch" and "560_trunk.patch" just let appclient can be removed and added into server within eclipse. After adding, appclient can't be shown in admin console. So it's not really deployed into server. To fix this, we need add some process to deploy appclient module into server with GEP. "560_214branch_new.patch" is a patch for 214 branch and "560_trunk_new.patch" is for trunk. Both of them have cover the patch attached last time. Thanks! > Can't Add or Remove AppClient Project via GEP > - > > Key: GERONIMODEVTOOLS-560 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-560 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.3, 2.2.0 > Environment: OS:windows 2003 > JDK:1.5 >Reporter: viola.lu >Assignee: Delos Dai > Attachments: 560_214branch.patch, 560_214branch_new.patch, > 560_trunk.patch, 560_trunk_new.patch > > > 1.Run a fresh new eclipse in new workspace, install GEP , create geronimo > server runtime > 2.Create a JEE application client attached, and then right-click G server > runtime->"add and remove project", but it indicates "no project to add" > 3.If i imported other war or ear, ejb jar, then "add and remove project", > then all are listed to add and remove, if i choose app client, it will > reminde me that: > "The server does not support version 1.4 or 5 of the J2EE Application Client > module specification." > So fail to deploy app client to server via GEP -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Zhang updated GERONIMODEVTOOLS-564: Comment: was deleted (was: It seems something wrong with the 'getGBean' method used in GeronimoServerPluginManager when trying to init the PluginInstaller, but I still do not know the reason exactly. Now I used Proxy instead, and it works fine. ) > Fail to create plugin via GEP > - > > Key: GERONIMODEVTOOLS-564 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:wind2003 jdk:1.5 >Reporter: viola.lu >Assignee: Tim McConnell > > Steps: > 1.Define a G server runtime, and right-click to open it > 2.Open "plugin" page, click "convert app to plugin"->choose any item you > would like->next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-564) Fail to create plugin via GEP
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680814#action_12680814 ] Yang Zhang commented on GERONIMODEVTOOLS-564: - It seems something wrong with the 'getGBean' method used in GeronimoServerPluginManager when trying to init the PluginInstaller, but I still do not know the reason exactly. Now I used Proxy instead, and it works fine. > Fail to create plugin via GEP > - > > Key: GERONIMODEVTOOLS-564 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-564 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.1.4 > Environment: os:wind2003 jdk:1.5 >Reporter: viola.lu >Assignee: Tim McConnell > > Steps: > 1.Define a G server runtime, and right-click to open it > 2.Open "plugin" page, click "convert app to plugin"->choose any item you > would like->next, all fields are empty, and fail to convert it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4579) There are errors during zip file extracted on Linux OS using farm clustering
[
https://issues.apache.org/jira/browse/GERONIMO-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Jiang updated GERONIMO-4579:
--
Attachment: G4579_trunk.patch
G4579_21.patch
See the patch to fix this problem. Couple with the snapshot, you will
understand what the defect is.
> There are errors during zip file extracted on Linux OS using farm clustering
>
>
> Key: GERONIMO-4579
> URL: https://issues.apache.org/jira/browse/GERONIMO-4579
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Clustering
>Affects Versions: 2.1.4
> Environment: SW:
> JAVA6+WIN2008+SLES10SP2
> HW:
> Intel x86
>Reporter: Zhen Chen
> Attachments: G4579_21.patch, G4579_trunk.patch, zip_extracted_errors
> .jpg
>
>
> Can't deploy a war to farm clustering successfully, because the zip file
> extracted on Linux OS is wrong.
> After deploying a war to farm clustering(ex, NODE-A,NODE-B), I found that the
> files are not in the correct path, while named in the form like
> "WEB-INF\classes\..
> .java" in cluster-repository on Linux OS.
> I have tried that on RHEL 5.2, SLES 10 OS. Same error occurs.
> I think this is a bug, Please check it.
> My steps:
> 1.Login on NODE-A server
> 1.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-A
> RemoteDeployHostname=MachineA_IP
> {code}
> 1.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
>name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2
> .1.4/car,j2eeType=NodeInfo,name=NodeInfoB"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-B
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineB_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 2.Login on NODE-B server
> 2.1 For var\config\config-substitutions.properties
> {code:xml}
>clusterNodeName=NODE --> clusterNodeName=NODE-B
> RemoteDeployHostname=MachineB_IP
> {code}
> 2.2 For var\config\config.xml, add the following contents to module:
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car
> {code:xml}
> name="org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/far
> ming/2.1.4-SNAPSHOT/car,j2eeType=NodeInfo,name=NodeInfoA"
> gbeanInfo="org.apache.geronimo.farm.config.BasicNodeInfo">
> NODE-A
> propertyEditor="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfoEditor"
> name="extendedJMXConnectorInfo">
> class="org.apache.geronimo.farm.config.BasicExtendedJMXConnectorInfo"
> xmlns:ns4="http://geronimo.apache.org/xml/ns/attributes-1.2";
> xmlns:ns="http://geronimo.apache.org/xml/ns/deployment/javabean-1.0"; xmlns="">
> system
> manager
> rmi
> MachineA_IP
> 1099
> JMXConnector
> false
>
>
> {code}
> 3. Start NODE- A server , and NODE-B server
> 4.Run the following commands in GERONIMO_HOME\bin in Machine A
> {code:xml}
>4.1 deploy.bat/sh --user system --password manager start
> org.apache.geronimo.configs/farming//car
>4.2 deploy.bat/sh --user system --password manager --host MachineB_IP
> start org.apache.geronimo.configs/farming//car
> {code}
> 5.deploy.bat/sh --user system --password manager deploy --targets
> {code:xml}
> org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/farming/2.1.4-SNAPSHOT/car,j2eeType=Confi
> gurationStore,name=MasterConfigurationStore
> SAMPLE_HOME\applications\tomcat-cluster\servlet-examples-cluster-server1.war
> servlet-examples-cluster-plan.xml
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4581) The batch file for deploying the ExampleClient.jar doesn't work.
The batch file for deploying the ExampleClient.jar doesn't work. Key: GERONIMO-4581 URL: https://issues.apache.org/jira/browse/GERONIMO-4581 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: documentation Affects Versions: 2.1, 2.2 Environment: IBM JDK 6 + Windows XP SP3 Reporter: Ying Tang Priority: Trivial http://cwiki.apache.org/confluence/display/GMOxDOC22/Deploying+and+running+Java+EE+application+client The .bat file in this page for deploying the application client doesn'w work, as the command "jar" for packing the .jar file has incorrect format: jar -cfM app_client.jar -C D:\workspace2\GERONIMO_APPLICATION\bin . we can locate the batch file in the application home directory, where there should be a META-INF folder and class files (class files can be in its subdirectory), and use this syntax: jar cfM app_client.jar * Does anybody know how to specify the directory in the batch file? The -C option doesn't work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
Hi, So let's agree to disagree for now. This may be related to my personal way of comparing stuff which is pretty much limited to: 1. understand what the requirements are. 2. understand how the technologies support these requirements. I do not need all the bells and whistles that a technology offers to fulfill the requirements. Moreover comparing stuff based on technology differentiators not clearly linked to the requirements is pointless. 3. assess best way forward based on above scoring. Key steps are 1 and 2 where stuff offering all the bells and whistles may well be scored as good as other stuff (I clearly do not support over-bloated stuff...). Obviously, I am keen to be proven wrong and adjust accordingly. So far, I am still saying that the main challenge is to properly tune export/import of dependency declarations. For me, the technology is not the core issue and switching is not going to resolve problems. Thanks, Gianny On 11/03/2009, at 7:11 PM, Guillaume Nodet wrote: On Wed, Mar 11, 2009 at 08:57, Gianny Damour wrote: Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http:// www.grails.org/Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of "from the bottom". Another approach to many of these issues is perhaps "from the top", from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from
[jira] Created: (XBEAN-124) Create documentation as xml file
Create documentation as xml file Key: XBEAN-124 URL: https://issues.apache.org/jira/browse/XBEAN-124 Project: XBean Issue Type: Sub-task Components: maven-plugin Environment: all Reporter: Felix Knecht Priority: Minor Create a xml file to make processing and generation of a report easier. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Whence the geronimo kernel?
On Wed, Mar 11, 2009 at 08:57, Gianny Damour wrote: > Hi, > > FWIW, I believe that improving the configuration style to simplify the > means of creating a bunch of objects in the kernel has more benefits than > swapping the classloading infra. On paper OSGi may appear as superior from a > classloading isolation perspective; however, I believe the current CLing > design is nearly up to par with the OSGi one and that the main challenge is > to properly tune export/import dependency declarations. I have to disagree with that. The CLing mechanism is very different in Geronimo (from what I recall) and OSGi. Geronimo uses a multi-parent classloader style with some nice features to be able to hide / never override + parent or self-first delegation. OSGi CLind is very different: the first one is that you don't really have parent classloaders: the classloader for a given OSGi bundle is calculated wrt to the constraints expressed in the OSGi manifest using imported packages or required bundles. Let's take an example: bundle A needs api packages from bundles B and C implementation classes from bundle B and C needs something from bundle D but with different versions OSGi will be able to handle that because of non tree-like CLind mechanism: if bundle A is wired to bundle B, it does not have to see all the requirements from bundle B, and same for C. Therefore, bundle A can be wired to both B and C without problems because it will not see bundle D at all (so there's no conflicts between the two versions of bundle D). OSGi has a much more powerful CLing mechanism where you can express lots of different constraints. The drawback is that establishing the classloader can take a bit of time, so going to OSGi most certainly leads to a big slowdown at startup while creating the classloaders. Also, OSGi does not really play nicely with the usual JEE way to discover implementations through the MANIFEST/services entries. That's kinda what we've tried to solve in servicemix specs, though I'm not sure if that really applies everywhere because I would imagine the classloaders for EARs are not really OSGi classloaders ... I certainly don't want to say OSGi is not the way to go, just want to make the point that there are benefits but also drawbacks. > > The JAXB approach to turn xml plans to a bunch of objects is certainly > interesting. I believe it is still a technology limiting decision whereby a > lot of custom code will have to be implemented to support various style > (factory methods or beans et cetera) of configurations. I have been bouncing > around this idea a while back and here it is again. Why do we want to define > a XML language to create a bunch of objects when scripting can do that for > us? > > I believe that xbean-spring is still unnecessary noisy when compared to > something like the Spring Bean Builder (http://www.grails.org/ > Spring+Bean+Builder). > > If there is an interest in a scripting approach, then I can investigate > further. > > Thoughts? > > Thanks, > Gianny > > > On 11/03/2009, at 6:54 AM, David Jencks wrote: > > So as mentioned below I'm starting to look into the osgi classloading bit, >> sort of "from the bottom". >> >> Another approach to many of these issues is perhaps "from the top", from >> the point of view of going from a presumably xml plan to a bunch of objects. >> >> I've long thought that it must be possible to leverage jaxb to do most of >> the heavy lifting here. In particular sxc is some code we can presumably >> actually extend to do stuff like constructor dependency injection. So >> another avenue that could perhaps be approached in parallel would be to >> investigate sxc, jaxb, xbean-spring, xbean-reflect, the blueprint service >> schema, and jsr299 requirements and see what we can come up with. >> >> For instance, it might be possible to have a large part of the blueprint >> service functionality in jaxb-enabled objects that jaxb instantiates from >> the xml. The "init" method could deal with feeding the metadata into the >> blueprint service core. Maybe we can get sxc to use xbean-reflect to create >> the objects. >> >> So far this is more or less wild speculation in my head... but I think it >> would be a lot of fun to investigate. >> >> >> thanks >> david jencks >> >> >> On Mar 4, 2009, at 4:56 PM, David Jencks wrote: >> >> Geronimo has been around for a while and despite the many good features >>> gbeans and the geronimo kernel are not catching on big time. I think we >>> want to consider taking action now to avoid ending up being dragged down by >>> supporting a dead container. Here are a few thoughts. >>> >>> Actual problems with geronimo: >>> - gbeans are too restrictive. It's too hard to instantiate other peoples >>> components as gbeans. GBeans don't support common patterns like factory >>> methods, factory beans, etc etc, and require the component to be >>> instantiated directly by the gbean framework. >>> - it's too hard to get the classloaders
Re: Whence the geronimo kernel?
Hi, FWIW, I believe that improving the configuration style to simplify the means of creating a bunch of objects in the kernel has more benefits than swapping the classloading infra. On paper OSGi may appear as superior from a classloading isolation perspective; however, I believe the current CLing design is nearly up to par with the OSGi one and that the main challenge is to properly tune export/ import dependency declarations. The JAXB approach to turn xml plans to a bunch of objects is certainly interesting. I believe it is still a technology limiting decision whereby a lot of custom code will have to be implemented to support various style (factory methods or beans et cetera) of configurations. I have been bouncing around this idea a while back and here it is again. Why do we want to define a XML language to create a bunch of objects when scripting can do that for us? I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/ Spring+Bean+Builder). If there is an interest in a scripting approach, then I can investigate further. Thoughts? Thanks, Gianny On 11/03/2009, at 6:54 AM, David Jencks wrote: So as mentioned below I'm starting to look into the osgi classloading bit, sort of "from the bottom". Another approach to many of these issues is perhaps "from the top", from the point of view of going from a presumably xml plan to a bunch of objects. I've long thought that it must be possible to leverage jaxb to do most of the heavy lifting here. In particular sxc is some code we can presumably actually extend to do stuff like constructor dependency injection. So another avenue that could perhaps be approached in parallel would be to investigate sxc, jaxb, xbean- spring, xbean-reflect, the blueprint service schema, and jsr299 requirements and see what we can come up with. For instance, it might be possible to have a large part of the blueprint service functionality in jaxb-enabled objects that jaxb instantiates from the xml. The "init" method could deal with feeding the metadata into the blueprint service core. Maybe we can get sxc to use xbean-reflect to create the objects. So far this is more or less wild speculation in my head... but I think it would be a lot of fun to investigate. thanks david jencks On Mar 4, 2009, at 4:56 PM, David Jencks wrote: Geronimo has been around for a while and despite the many good features gbeans and the geronimo kernel are not catching on big time. I think we want to consider taking action now to avoid ending up being dragged down by supporting a dead container. Here are a few thoughts. Actual problems with geronimo: - gbeans are too restrictive. It's too hard to instantiate other peoples components as gbeans. GBeans don't support common patterns like factory methods, factory beans, etc etc, and require the component to be instantiated directly by the gbean framework. - it's too hard to get the classloaders to work. The most common problem is a class cast exception due to loading the same jar in two plugins. NoClassDefFound errors from an optional jar in a child classloader are also really annoying. Really good things about geronimo I haven't seen elsewhere (at least in one place): - gbean dependencies work across plugins. Dependencies are a unified system, not per-plugin. - gbean dependencies are resolved in the ancestors of a plugin, not server wide. This means that you can't make a partially specified dependency ambiguous by deploying additional plugins. I consider this an extremely important feature for predictability. - plugin dependencies allow assembly of a server from the explicit dependencies which are normally the same as the maven dependencies. Other projects and specs that have stuff we should look into: maven. Maven has a lot better infrastructure for dealing with dependency resolution from partial transitive dependency specification than we do. We should look into using more of their infrastructure. osgi. osgi has a lot of similarities to geronimo. The osgi classloading model is getting a lot of people excited. The import- bundle idea is pretty much the same as our classloader model where every jar is a plugin. I don't know if people are really using the allegedly recommended method of specifying imports and exports and letting the osgi runtime figure out where they come from; this seems worth investigating to me. Also, we get periodic inquiries about when we are going to support osgi and the was ce folks get even more. osgi blueprint service (rfc 124) This appears to be a simple wiring framework for a single plugin. IIUC it uses the osgi service registry for component dependencies between bundles. xbean-spring. I'd be reluctant to try to implement a blueprint service that didn't provide the xbean-spring capabilities really
