Re: JAXB upgrade
I'm OK with rolling back for now. However the spec itself is final and the RI impl is already out: https://jax-ws.dev.java.net/2.1/ Everyone else ok with it? In Eclipse-land we've got an IP clearance request in on 2.0, we'll add another one for 2.1, so we can have enabler plugins for current and future CXF. What's the Real Truth on JAX-WS . JAXB cross product? I'd like to be able to produce a rolled up integration plugin with both parts. regards --oh
Property substitution in config.xml implemented
Following Ted Kirby's idea of property substitution in config.xml files (GERONIMO-2735) I applied and modified his patch. Jason Dillon had a jexl expression evaluator lying around so I replace the evaluation code in the patch with the jexl stuff, so now you can use expressions in your substitutions. The substitutions are in a new file, default location var/config/ config-substitutions.properties. This is used to evaluate expressions in config.xml. I implemented a small example in geronimo- jetty6-jee5 for the jetty connectors, using hostName httpPort httpsPort portOffset. You can override a value in the properties file with an environment variable or a system property. Therefore, to start a server on a different set of jetty connector ports, you can say: java -DportOffset=1 -jar bin/server.jar --long If this generally seems like a good idea and no one has a better idea I'll go through the config.xmls and use substitutions more systematically in a few days. One question I have is whether it's really a good idea to use environment variables for substitutions. I really don't know and would appreciate more informed opinions. Also, you can specify an alternate properties file on the command line with java -Dorg.apache.geronimo.config.substitutions.file=where.ever.you.want Many thanks to ted for coming up with the original patch and pushing for it. thanks david jencks
[jira] Commented: (GERONIMO-2735) Add property substitution capability in the config.xml and plan files
[
https://issues.apache.org/jira/browse/GERONIMO-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477738
]
David Jencks commented on GERONIMO-2735:
I worked on trunk (2.0) and reworked the patch substantially. There's now a
small example in the geronimo-jetty6-jee5 config.xml.
rev 514355.
features:
- jexl expressions in ${} such as ${httpPort + portOffset}
- expressions are only evaluated when gbeanData overrides are being applied,
not on set.
- default properties file is var/config/config-substitutions.properties
- refactored most of the LocalAttributeManager related classes to use generics.
If no one objects or has a better idea in a few days I'll make more extensive
use of this feature in our config.xmls.
I don't think it's practical to try to get this into the 1.2 branch.
> Add property substitution capability in the config.xml and plan files
> -
>
> Key: GERONIMO-2735
> URL: https://issues.apache.org/jira/browse/GERONIMO-2735
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
>Affects Versions: 1.1.1, 1.1.x, 2.0-M1
> Environment: All
>Reporter: Ted Kirby
> Assigned To: David Jencks
>Priority: Minor
> Attachments: JIRA2735.1.1.1.patch, JIRA2735.2.0.patch
>
>
> Allow property substitution as it works in maven, Spring, and JBoss.
> Allow a geronimo.properties type file. In that file, allow something like
> this:
> tomcat.port=9090
> tomcat.listen.ip=10.0.0.7
> In the config.xml, then allow the following:
> ...
>
>
> ${tomcat.port}
> ${tomcat.listen.ip}
>
>
> The server reads the property file on boot (if one exists). When the
> config.xml is processed, it substitutes the declared property.
> Properties might also come from a GBean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2735) Add property substitution capability in the config.xml and plan files
[
https://issues.apache.org/jira/browse/GERONIMO-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks reassigned GERONIMO-2735:
--
Assignee: David Jencks
> Add property substitution capability in the config.xml and plan files
> -
>
> Key: GERONIMO-2735
> URL: https://issues.apache.org/jira/browse/GERONIMO-2735
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
>Affects Versions: 1.1.1, 1.1.x, 2.0-M1
> Environment: All
>Reporter: Ted Kirby
> Assigned To: David Jencks
>Priority: Minor
> Attachments: JIRA2735.1.1.1.patch, JIRA2735.2.0.patch
>
>
> Allow property substitution as it works in maven, Spring, and JBoss.
> Allow a geronimo.properties type file. In that file, allow something like
> this:
> tomcat.port=9090
> tomcat.listen.ip=10.0.0.7
> In the config.xml, then allow the following:
> ...
>
>
> ${tomcat.port}
> ${tomcat.listen.ip}
>
>
> The server reads the property file on boot (if one exists). When the
> config.xml is processed, it substitutes the declared property.
> Properties might also come from a GBean.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Geronimo web site update - RESULTS
Ok folks we have 14 votes "+1 Let's move the authoring over Confluence." there have been no 0's nor -1's We'll move forward and go live with the site generated via Confluence. Thank you all Cheers! Hernan Hernan Cunico wrote: Folks, this vote is for moving the authoring of Geronimo's web site over Confluence. This mean that we will no longer use the anakia, xdocs and ant scripts to generate the web site, instead we will use Confluence. There is a GMOxSITE space in the cwiki site that only Geronimo committers can edit, this space will get automatically exported and massaged with a presentation template over geronimo.apache.org The source of the web site will remain in Confluence, svn repo will hold a copy of the HTML version. The other resources we serve from geronimo.apache.org such as plugins, schemas, redirects, etc. will remain unaffected. This vote will end this Saturday March 3rd at 1800 Eastern time. [ ] +1 Let's move the authoring over Confluence. [ ] 0 No opinion. [ ] -1 Do not change the authoring to Confluence, stay with ant scripts and xdocs. Cheers! Hernan
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
On Mar 3, 2007, at 6:39 PM, Jason Dillon wrote: How modular is the existing console code? I'm thinking that some work is probably needed to make it more modular, so that the existing functionality could be split up into smaller domain- specific modules and then deployed into the console app. Right now it looks like a big app, would like to see each of the major bits as a separate module... to help keep things orderly and prevent spaghetti code (which I've already started to notice when I looked at some Derby and AMQ-related console bits last). modular == good How much _heavier_ is Jetspeed2 vs. Pluto? A really lot heavier. A reasonable j2 integration will also be a significant effort since its going to involve a big security integration, probably a new jacc provider (or using triplesec), and a lot of other stuff. An unreasonably incomplete integration wouldn't need all of this but j2 has a lot of stuff for laying out apps, administering everything, etc etc etc. I know that J2 now uses Pluto (though not sure what version, hopefully its 1.1). I think they're still on 1.0.1. I'm all for lightweight... but I'm also okay with a little bit of extra pounds if it makes the console application easier for app developers/sysadmins to plugin/customize their own administration bits. I'm not sure that j2 would really make it a lot easier to add in admin plugins. I think its definitely worth investigating how far pluto 1.1 will get us. thanks david jencks --jason On Mar 3, 2007, at 9:04 AM, Paul McMahan wrote: I agree with Aaron that Pluto 1.1 would provide a much better baseline for making the admin console more pluggable. Jetspeed and Liferay are excellent portals as well but since they are application frameworks in their own right I think they provide a lot of functionality beyond what is needed for the admin console. David DeWolf from the Pluto team contacted us offering his assistance in upgrading the admin console to pluto 1.1, and that sparked a very interesting conversation. He specifically said that pluto 1.1 supports dynamic addition of portlets, which is key for making the admin console pluggable. See: http://tinyurl.com/3cdmj3 That was in 12/2005 (!) but maybe we can rekindle that conversation while we put the finishing touches on G 2.0. Best wishes, Paul On 3/3/07, Aaron Mulder <[EMAIL PROTECTED]> wrote: Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > > It's used by pluto for the admin console. No idea if more recent > > would work. > > > > We could upgrade pluto too if anyone has some time to investigate > > I wonder if anyone from the Pluto team would want to help with > that... looks like 1.1 is not compatible with 1.0.1... but also looks > like that might not be a bad thing: > > > Pluto 1.1 introduces a new container architecture. If you are > embedding Pluto in your portal, realize that 1.1 is not binarily > compatible with Pluto 1.0.x. > > Pluto 1.1 aims to simplify the architecture in order to make it more > user and developer friendly. You should find Pluto 1.1 easier to get > started with, easier to understand, and easier to embed with your > portal. Your feedback regarding how far we've come is always welcome > on the user and developer mailing lists! > > > > I don't know much abort portal muck, so I can't really show how much > better 1.1 might be... but I know that there have been some issues > with the console asis now to get stuff like plugin porlets installed > dynamically... perhaps 1.1 can help solve some of these issues? > > Anyone know? > > --jason > > > > >
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
On Mar 3, 2007, at 4:41 PM, Joe Bohn wrote: Jason Dillon wrote: How modular is the existing console code? I'm thinking that some work is probably needed to make it more modular, so that the existing functionality could be split up into smaller domain- specific modules and then deployed into the console app. Right now it looks like a big app, would like to see each of the major bits as a separate module... to help keep things orderly and prevent spaghetti code (which I've already started to notice when I looked at some Derby and AMQ-related console bits last). What is there isn't very modular. We've discussed this before. We need to make the console architecture a bit more modular so that the console management components could added as functions that they manage are added. For example, adding an EJB management portlet with EJB functions to a minimal Geronimo assembly. The down-side is that there are no standards here, so it would be Geronimo specific. Wouldn't using a more a more full-featured portal framework, like Jetspeed2 solve this... or really move the problem from us having to invent a solution to us being able to implement a solution based on another's framework? How much _heavier_ is Jetspeed2 vs. Pluto? I know that J2 now uses Pluto (though not sure what version, hopefully its 1.1). I'm all for lightweight... but I'm also okay with a little bit of extra pounds if it makes the console application easier for app developers/sysadmins to plugin/customize their own administration bits. I think that we need to keep things light-weight for the web console. We're already catching grief for the footprint. Sure... but how much _heavier_ is Jetspeed2 vs. Pluto? If its not that much bigger, and provides things like the modularity/deploy functionality already... then it might end up being less overall code for us to maintain, and would move the impl of the modularity to being specific to that vendors portal framework and not specific to Geronimo. The other aspect here is that users would like portal capability to exploit for their purposes and not just for Geronimo administration. There was some discussion on this in the past too. Right. There is Geronimo admin, and then there is app-admin, and then there is the app itself it is portal-based. My main focus would be on G admin and app-admin, but if the same portal could be used to handle everything (and isn't a massive dog) then... well... why not? For customer use something like Jetspeed2 or Liferay may make more sense. For an embedded administration console for Geronimo use Pluto provides the necessary functions with a smaller footprint. Again... how much _heavier_ is Jetspeed2 vs. Pluto? I'd imagine J2 is bigger... but does anyone know how much bigger? And how much more overhead is our custom framework for modularity (and admin/ customization of those modules) going to add... in terms of resident footprint, lines of code and complexity? IMO... if using a more full-featured portal that fits our licensing needs... that does not add a huge bloat to the assembly/footprint, and provides some solutions to the framework needs we have (and/or adding more useful features)... then seems like that makes more sense. I'm not pushing for one or the other... just trying to gather some real details from folks who know about this better than I do. But so far, I've only heard that one is more lightweight... nothing specific at all :-( So, does anyone know? Does using J2 bloat the distro by like 10mb or something? Or eat up 25m in heap when running, etc... I'm all for light... but if a bit of extra fat adds support OOTB for modularity features, reduces G-specific portal infrastructure, and provides folks with a usable portal system for their own custom administration or simple application, then I'd be happy with a little extra grease on my bacon with my morning eggs. But if its more like adding a tub of butter on my toast... I might not like that so much (as good as it might taste) ;-) --jason
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Jason Dillon wrote: How modular is the existing console code? I'm thinking that some work is probably needed to make it more modular, so that the existing functionality could be split up into smaller domain-specific modules and then deployed into the console app. Right now it looks like a big app, would like to see each of the major bits as a separate module... to help keep things orderly and prevent spaghetti code (which I've already started to notice when I looked at some Derby and AMQ-related console bits last). What is there isn't very modular. We've discussed this before. We need to make the console architecture a bit more modular so that the console management components could added as functions that they manage are added. For example, adding an EJB management portlet with EJB functions to a minimal Geronimo assembly. The down-side is that there are no standards here, so it would be Geronimo specific. How much _heavier_ is Jetspeed2 vs. Pluto? I know that J2 now uses Pluto (though not sure what version, hopefully its 1.1). I'm all for lightweight... but I'm also okay with a little bit of extra pounds if it makes the console application easier for app developers/sysadmins to plugin/customize their own administration bits. I think that we need to keep things light-weight for the web console. We're already catching grief for the footprint. The other aspect here is that users would like portal capability to exploit for their purposes and not just for Geronimo administration. There was some discussion on this in the past too. For customer use something like Jetspeed2 or Liferay may make more sense. For an embedded administration console for Geronimo use Pluto provides the necessary functions with a smaller footprint. IMO the ideal solution would be: - Improve the modularity of the console components such that management could be installed with a function. This is really an orthogonal discussion but was raised here because Pluto 1.1 provides some necessary features to make this a reality. - Continue to ship Geronimo using Pluto (1.1) as the default portal for our administration console. - Provide the capability to install/run the console on other Portal solutions such as JetSpeed2 or Liferay if deployed on Geronimo. I guess in these situations we could support running two portals (one for Geronimo and a user Portal) but that eliminates any possible integration between user portlets and Geronimo admin portlets. Joe --jason On Mar 3, 2007, at 9:04 AM, Paul McMahan wrote: I agree with Aaron that Pluto 1.1 would provide a much better baseline for making the admin console more pluggable. Jetspeed and Liferay are excellent portals as well but since they are application frameworks in their own right I think they provide a lot of functionality beyond what is needed for the admin console. David DeWolf from the Pluto team contacted us offering his assistance in upgrading the admin console to pluto 1.1, and that sparked a very interesting conversation. He specifically said that pluto 1.1 supports dynamic addition of portlets, which is key for making the admin console pluggable. See: http://tinyurl.com/3cdmj3 That was in 12/2005 (!) but maybe we can rekindle that conversation while we put the finishing touches on G 2.0. Best wishes, Paul On 3/3/07, Aaron Mulder <[EMAIL PROTECTED]> wrote: Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > > It's used by pluto for the admin console. No idea if more recent > > would work. > > > > We could upgrade pluto too if anyone has some time to investigate > > I wonder if anyone from the Pluto team would want to help with > that... looks like 1.1 is not compatible with 1.0.1... but also looks > like that might not be a bad thing: > > > Pluto 1.1 introduces a new container architecture. If you are > embedding Pluto in your portal, realize that 1.1 is not binarily > compatible with Pluto 1.0.x. > > Pluto 1.1 aims to simplify the architecture in order to make it more > user and developer friendly. You should find Pluto 1.1 easier to get > started with, easier to understand, and easier to embed with your > portal. Your feedback regarding how far we've come is always welcome > on the user and developer mailing lists! > > > > I don't know much abort portal muck, so I can't really show how much > better 1.1 might be... but I know that there have been some issues > with the c
Re: mx4j dependencies
Why not just change these to use org/apache/geronimo/system/main/ Daemon, which should be on the parent's classloader? Or org/apache/ log4j/Level ? Anyways... I don't know enough about what this is really testing to just nuke it. Seems a tad safer to just pick a different class to load. --jason On Mar 2, 2007, at 3:53 PM, Anita Kulshreshtha wrote: Go for it... Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: Ah... I didn't notice that ;-) Maybe it should be nuked then... --jason On Mar 2, 2007, at 4:49 AM, Anita Kulshreshtha wrote: The tests have been disabled (the names starts with xtest)... Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: On Mar 1, 2007, at 4:04 PM, Dain Sundstrom wrote: * modules/geronimo-jetty6/src/test/java/org/apache/geronimo/ jetty6/ClassLoaderTest.java (attempts to use "mx4j.MBeanDescription" to test classloading stuff) Not sure what to do about the later... or even if anything needs to be done. I'd just say remove the test. This test doesn't actually fail with the mx4j deps removed from the project. So either is picking up mx4j somewhere (that isn't getting included in the assembly, cause I can't find it there... though didn't look too hard for it), or the test is disabled, or its not testing anything useful... or its a broken test... or i've been sucked into a biiaaar universe. --jason __ __ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com __ __ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front
Re: JAXB upgrade
This currently says... Sorry! Temporarily unavailable will be back soon... :-( --jason On Mar 2, 2007, at 4:31 PM, Dan Diephouse wrote: I'm OK with rolling back for now. However the spec itself is final and the RI impl is already out: https://jax-ws.dev.java.net/2.1/ Everyone else ok with it? Cheers, - Dan On 3/2/07, David Jencks <[EMAIL PROTECTED]> wrote: At this time Geronimo can only certify with JAXB 2.0 and JAXWS 2.0. We're hoping that sun will update the tck to allow supporting the 2.1 specs, but as far as we can tell this has not yet happened. Getting information out of sun about this stuff can be difficult, but perhaps if we started now and now and are sufficiently persistent we will eventually find out something useful. Are the 2.1 spec versions officially released? Meanwhile we'd certainly appreciate it at Geronimo if you went back to the 2.0 spec versions for now. thanks david jencks On Mar 1, 2007, at 7:43 AM, Jarek Gawor wrote: > Oh... I didn't even realize you guys are targeting JAX-WS 2.1. Now, > I'm not sure how that affects things. > > Jarek > > On 3/1/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: >> I'm happy to revert the change, but I think that we ultimately >> need it. I >> believe we're targeting JAX-WS 2.1 (we switched the API jar the >> other day), >> and that requires JAXB 2.1. There are many benefits from a user >> perspective >> in 2.1. For isntance it has a lot better functionality for things >> like WS-A >> and also makes it easier for people to use substitution types, which >> requires all sorts of hacks right now. >> >> Is Geronimo just looking to release JAX-WS 2.0 support or 2.1? Any >> idea if >> its possible to certify Geronimo with 2.1? Or does certification >> require 2.0? >> I'm not sure what the status is of the JAX-WS 2.1 TCK either. >> >> - Dan >> >> (I CC'd [EMAIL PROTECTED] in, hope thats ok) >> >> On 2/28/07, Jarek Gawor <[EMAIL PROTECTED]> wrote: >> > >> > Hi again, >> > >> > CXF code was recently upgraded to JAXB 2.1 and so I tired to figure >> > out what sort of implications that might have on Geronimo. First of >> > all, JAXB is one of those libraries that is shared by all >> applications >> > in the Geronimo server. We also have a bunch of different >> components >> > using JAXB to do deployment descriptor parsing, etc. So if we >> upgrade >> > JAXB in G, we have to retest all these subcomponents to make >> sure they >> > are ok. And I think in general that should be ok but >> potentially time >> > consuming. Another potential issue that somebody raised was TCK >> > testing. We don't know what happens if for example TCK expects JAXB >> > 2.0 API but gets JAXB 2.1 API/implementation. Maybe nothing (as >> things >> > supposed to be backwards compatible) but maybe it blows up. That's >> > another thing for us to worry about. >> > >> > So, if this JAXB upgrade is not a critical issue for CXF would >> it be >> > possible to switch back to JAXB 2.0? >> > >> > Thanks, >> > Jarek >> > >> >> >> >> -- >> Dan Diephouse >> Envoi Solutions >> http://envoisolutions.com | http://netzooid.com/blog >> -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
[jira] Created: (GERONIMO-2927) Cannot rebuild Geronimo with external ActiveMQ XBean configuration because Spring Framework is missing
Cannot rebuild Geronimo with external ActiveMQ XBean configuration because Spring Framework is missing -- Key: GERONIMO-2927 URL: https://issues.apache.org/jira/browse/GERONIMO-2927 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: ActiveMQ Affects Versions: 1.2 Reporter: Aman Nanner Fix For: 1.2 I rebuilt Geronimo with a change to the ActiveMQ module. I enabled the configuration of ActiveMQ to be loaded from an external configuration using XBeans. However, the server now will not startup because of the following NoClassDefFoundError: Caused by: java.lang.NoClassDefFoundError: org/springframework/beans/BeansException at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:61) at org.apache.activemq.util.FactoryFinder.newInstance(FactoryFinder.java:47) at org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:41) It seems like this is triggered when the classloader tries to load the following class: org.apache.activemq.xbean.XBeanBrokerFactory. It seems that the Spring Framework does not exist in the repository. This should be added so that the ActiveMQ XBean configuration can be enabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
How modular is the existing console code? I'm thinking that some work is probably needed to make it more modular, so that the existing functionality could be split up into smaller domain-specific modules and then deployed into the console app. Right now it looks like a big app, would like to see each of the major bits as a separate module... to help keep things orderly and prevent spaghetti code (which I've already started to notice when I looked at some Derby and AMQ-related console bits last). How much _heavier_ is Jetspeed2 vs. Pluto? I know that J2 now uses Pluto (though not sure what version, hopefully its 1.1). I'm all for lightweight... but I'm also okay with a little bit of extra pounds if it makes the console application easier for app developers/sysadmins to plugin/customize their own administration bits. --jason On Mar 3, 2007, at 9:04 AM, Paul McMahan wrote: I agree with Aaron that Pluto 1.1 would provide a much better baseline for making the admin console more pluggable. Jetspeed and Liferay are excellent portals as well but since they are application frameworks in their own right I think they provide a lot of functionality beyond what is needed for the admin console. David DeWolf from the Pluto team contacted us offering his assistance in upgrading the admin console to pluto 1.1, and that sparked a very interesting conversation. He specifically said that pluto 1.1 supports dynamic addition of portlets, which is key for making the admin console pluggable. See: http://tinyurl.com/3cdmj3 That was in 12/2005 (!) but maybe we can rekindle that conversation while we put the finishing touches on G 2.0. Best wishes, Paul On 3/3/07, Aaron Mulder <[EMAIL PROTECTED]> wrote: Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > > It's used by pluto for the admin console. No idea if more recent > > would work. > > > > We could upgrade pluto too if anyone has some time to investigate > > I wonder if anyone from the Pluto team would want to help with > that... looks like 1.1 is not compatible with 1.0.1... but also looks > like that might not be a bad thing: > > > Pluto 1.1 introduces a new container architecture. If you are > embedding Pluto in your portal, realize that 1.1 is not binarily > compatible with Pluto 1.0.x. > > Pluto 1.1 aims to simplify the architecture in order to make it more > user and developer friendly. You should find Pluto 1.1 easier to get > started with, easier to understand, and easier to embed with your > portal. Your feedback regarding how far we've come is always welcome > on the user and developer mailing lists! > > > > I don't know much abort portal muck, so I can't really show how much > better 1.1 might be... but I know that there have been some issues > with the console asis now to get stuff like plugin porlets installed > dynamically... perhaps 1.1 can help solve some of these issues? > > Anyone know? > > --jason > > > > >
Build Failure - Eclipse-Plugin trunk Rev513960
Latest Eclipse-Plugin trunk at Rev513960 fails to build with the following error on WinXP, Maven 2.0.5 and Java 1.5.0_11 - [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.devtools -Dartifact Id=org.apache.geronimo.st.v20.core \ -Dversion=2.0.0 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.devtools:assembly:pom:2.0.0 2) org.apache.geronimo.devtools:org.apache.geronimo.st.v20.core:jar:2.0. 0 -- 1 required artifact is missing. for artifact: org.apache.geronimo.devtools:assembly:pom:2.0.0 -Donald smime.p7s Description: S/MIME Cryptographic Signature
Running the MimeBodyPartTest.java file
I'm trying to run the MimeBodyPartTest from geronimo-javamail_1.4_spec/src/test/java folder but it can't compile due to a missing dependency. It requires junit.framework package that I do not seem to have. Does anyone know what this package is a part of and where I can get it? Thanks, Jason Warner
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
I actually pinged the pluto dev list yesterday: http://www.nabble.com/Pluto-1.0.x-to-1.1-upgrade-guide-%28Apache- Geronimo-Console%29-tf3337657.html If someone who knows more about the details could chime in (Paul? Aaron?) it might help. --jason On Mar 3, 2007, at 9:04 AM, Paul McMahan wrote: I agree with Aaron that Pluto 1.1 would provide a much better baseline for making the admin console more pluggable. Jetspeed and Liferay are excellent portals as well but since they are application frameworks in their own right I think they provide a lot of functionality beyond what is needed for the admin console. David DeWolf from the Pluto team contacted us offering his assistance in upgrading the admin console to pluto 1.1, and that sparked a very interesting conversation. He specifically said that pluto 1.1 supports dynamic addition of portlets, which is key for making the admin console pluggable. See: http://tinyurl.com/3cdmj3 That was in 12/2005 (!) but maybe we can rekindle that conversation while we put the finishing touches on G 2.0. Best wishes, Paul On 3/3/07, Aaron Mulder <[EMAIL PROTECTED]> wrote: Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > > It's used by pluto for the admin console. No idea if more recent > > would work. > > > > We could upgrade pluto too if anyone has some time to investigate > > I wonder if anyone from the Pluto team would want to help with > that... looks like 1.1 is not compatible with 1.0.1... but also looks > like that might not be a bad thing: > > > Pluto 1.1 introduces a new container architecture. If you are > embedding Pluto in your portal, realize that 1.1 is not binarily > compatible with Pluto 1.0.x. > > Pluto 1.1 aims to simplify the architecture in order to make it more > user and developer friendly. You should find Pluto 1.1 easier to get > started with, easier to understand, and easier to embed with your > portal. Your feedback regarding how far we've come is always welcome > on the user and developer mailing lists! > > > > I don't know much abort portal muck, so I can't really show how much > better 1.1 might be... but I know that there have been some issues > with the console asis now to get stuff like plugin porlets installed > dynamically... perhaps 1.1 can help solve some of these issues? > > Anyone know? > > --jason > > > > >
[jira] Commented: (SM-191) Request to add xpp3 jar to optional libraries
[ https://issues.apache.org/activemq/browse/SM-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38650 ] Jamie Goodyear commented on SM-191: --- Hi All, After a quick look into this request here is my analysis... Adding this jar should be relatively straight forward, the part that requires some clarification is licensing. If we were to include this jar we will need to adhere to the xpp3 jar license conditions. This may be accomplished by including the xpp3 jar and license file in the optional libraries folder, and we will also need to add the appropriate acknowledgement to Indiana University in the ServiceMix end-user documentation. Can someone from the core team please comment on the requirements we need to adhere to honor licensing concerns? Cheers, Jamie Notes: The xpp3 jar can be accessed here: http://extreme.indiana.edu/dist/java-repository/xpp3/ The xpp3 license can be accessed here: http://extreme.indiana.edu/dist/java-repository/xpp3/licenses/LICENSE.txt > Request to add xpp3 jar to optional libraries > - > > Key: SM-191 > URL: https://issues.apache.org/activemq/browse/SM-191 > Project: ServiceMix > Issue Type: Improvement >Affects Versions: 2.0.2 > Environment: n/a >Reporter: Matt DeHoust >Priority: Minor > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > If you use XStreamMarshaler.unmarshal you must add an XPP3 parser > implementation to your classpath. XStream depends on the pull parser in > fromXML as the stack trace below indicates. > XPP3 pull parser library not present. Specify another driver. For example: > new XStream(new DomDriver()) > java.lang.IllegalArgumentException: XPP3 pull parser library not present. > Specify another driver. For example: new XStream(new DomDriver()) > at > com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:19) > at com.thoughtworks.xstream.XStream.fromXML(XStream.java:493) > at > org.servicemix.components.util.xstream.XStreamMarshaler.unmarshal(XStreamMarshaler.java:75) > ... > It would be nice if the xpp3 jar were bundled along with the optional > libraries. Better yet, add a test case for the XStreamMarshaler and specify > xpp3 as a dependency in the pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Looks like JBoss is abandoning Tomcat
Paul McMahan wrote: >> From reading that PDF it looks to me more like it embeds Tomcat rather > than forking it. Kinda like us ;-)
Re: Looks like JBoss is abandoning Tomcat
From reading that PDF it looks to me more like it embeds Tomcat rather than forking it. Specifically, it says that it "uses" the 5.5 branch and then says that the servlet 2.5 and jsp 2.1 specs will be supported by Tomcat 6.0.x. On 3/3/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Haven't really looked at this yet, Does anyone know if this is a Tomcat fork ? http://labs.jboss.com/file-access/default/members/jbossweb/freezone/dist/1.0.1.GA/jbossweb-usersguide.pdf
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
I agree with Aaron that Pluto 1.1 would provide a much better baseline for making the admin console more pluggable. Jetspeed and Liferay are excellent portals as well but since they are application frameworks in their own right I think they provide a lot of functionality beyond what is needed for the admin console. David DeWolf from the Pluto team contacted us offering his assistance in upgrading the admin console to pluto 1.1, and that sparked a very interesting conversation. He specifically said that pluto 1.1 supports dynamic addition of portlets, which is key for making the admin console pluggable. See: http://tinyurl.com/3cdmj3 That was in 12/2005 (!) but maybe we can rekindle that conversation while we put the finishing touches on G 2.0. Best wishes, Paul On 3/3/07, Aaron Mulder <[EMAIL PROTECTED]> wrote: Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > > It's used by pluto for the admin console. No idea if more recent > > would work. > > > > We could upgrade pluto too if anyone has some time to investigate > > I wonder if anyone from the Pluto team would want to help with > that... looks like 1.1 is not compatible with 1.0.1... but also looks > like that might not be a bad thing: > > > Pluto 1.1 introduces a new container architecture. If you are > embedding Pluto in your portal, realize that 1.1 is not binarily > compatible with Pluto 1.0.x. > > Pluto 1.1 aims to simplify the architecture in order to make it more > user and developer friendly. You should find Pluto 1.1 easier to get > started with, easier to understand, and easier to embed with your > portal. Your feedback regarding how far we've come is always welcome > on the user and developer mailing lists! > > > > I don't know much abort portal muck, so I can't really show how much > better 1.1 might be... but I know that there have been some issues > with the console asis now to get stuff like plugin porlets installed > dynamically... perhaps 1.1 can help solve some of these issues? > > Anyone know? > > --jason > > > > >
[jira] Closed: (GERONIMO-2921) Tomcat does not register web service url mappings when web.xml is not present
[ https://issues.apache.org/jira/browse/GERONIMO-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender closed GERONIMO-2921. --- Resolution: Fixed Fix Version/s: 2.0-beta2 Ok...here is the story... Tomcat does it's own parsing of web.xml. I tried to manually push wrappers (Servlets) and patterns to the context, but this is not working. In debugging Tomcat, apparently the url patterns don't get placed at the appropriate level when the context is running. I don't know if this is a bug or not, but it certainly is not following the architecture for the embedded/.manual tomcat component building as shown in examples all over the place. The issue may be that the context is already started. Therefore, I am writing out the XML to the deployment dir if a web.xml does not exist. This is kind of a kludge because of the Tomcat explained above. Hence, creating and writing out a web.xml to the deployed location is the only way around this until Tomcat fixes that bug. Once/if Tomcat can allow a how deploy of a servlet and url-pattern mapping to get picked up and dispatched, I can do a cleaner implementation with pure objects, thus removing the need to write out a web.xml. But for now, this seems to work. Committed revision 514188. > Tomcat does not register web service url mappings when web.xml is not present > - > > Key: GERONIMO-2921 > URL: https://issues.apache.org/jira/browse/GERONIMO-2921 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Reporter: Jarek Gawor > Assigned To: Jeff Genender > Fix For: 2.0-beta2 > > Attachments: jaxws-war-2.0-SNAPSHOT.war > > > Here's some background info. The web.xml file is now optional for JAX-WS > POJO web services. In such cases, there are certain rules on how the web.xml > should get updated. That is, appropriate and > elements should be inserted into the web.xml. When I update the in-memory > representation of the web.xml with the appropriate entires, everything works > just fine on Jetty. However, with Tomcat, it seems like the url-mappings for > the web services do not get registered. Everything else is fine, e.g. the web > services gbeans get initialized, etc. and I can access a JSP deployed in the > same war as the web services. > After a bit of debugging I see that GeronimoStandardContext.addChild() is not > called if the web.xml file is not present even though the in-memory > representation of the DD is updated correctly. So somehow I think the > in-memory representation of the DD is not being passed around correctly. > Here's a stack trace when web.xml file is present and when addChild() is > called: > System Thread [RMI TCP Connection(9)-192.168.1.102] (Suspended (breakpoint at > line 217 in GeronimoStandardContext)) > GeronimoStandardContext.addChild(Container) line: 217 > GeneratedMethodAccessor201.invoke(Object, Object[]) line: not available > DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 > Method.invoke(Object, Object...) line: 585 > IntrospectionUtils.callMethod1(Object, String, Object, String, > ClassLoader) line: 899 > SetNextRule.end() line: 193 > SetNextRule(Rule).end(String, String) line: 229 > Digester.endElement(String, String, String) line: 1058 > SAXParserImpl$JAXPSAXParser(AbstractSAXParser).endElement(QName, > Augmentations) line: not available > XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanEndElement() > line: not available [local variables unavailable] > > XMLDocumentScannerImpl$ContentDispatcher(XMLDocumentFragmentScannerImpl$FragmentContentDispatcher).dispatch(boolean) > line: not available > > XMLDocumentScannerImpl(XMLDocumentFragmentScannerImpl).scanDocument(boolean) > line: not available > XIncludeAwareParserConfiguration(XML11Configuration).parse(boolean) > line: not available > > XIncludeAwareParserConfiguration(XML11Configuration).parse(XMLInputSource) > line: not available > SAXParserImpl$JAXPSAXParser(XMLParser).parse(XMLInputSource) line: not > available > SAXParserImpl$JAXPSAXParser(AbstractSAXParser).parse(InputSource) line: > not available > SAXParserImpl$JAXPSAXParser.parse(InputSource) line: not available > Digester.parse(InputSource) line: 1562 > ContextConfig.applicationWebConfig() line: 369 > ContextConfig.start() line: 1060 > ContextConfig.lifecycleEvent(LifecycleEvent) line: 261 > LifecycleSupport.fireLifecycleEvent(String, Object) line: 120 > GeronimoStandardContext(StandardContext).start() line: 4238 >
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Pluto 1.1 integration would be great, and would allow much more reasonable dynamic additions of screens to the console. Someone just needs to do the work. :) I expect Jetspeed 2 would do the same, but I think Pluto would be much more lightweight, so I would think it would be preferable for the console, whereas Jetspeed and Liferay would be preferable for people developing portal applications. I believe David J did some initial work along these lines a while back. Thanks, Aaron On 3/3/07, Jason Dillon <[EMAIL PROTECTED]> wrote: On Feb 13, 2007, at 5:49 PM, David Jencks wrote: > It's used by pluto for the admin console. No idea if more recent > would work. > > We could upgrade pluto too if anyone has some time to investigate I wonder if anyone from the Pluto team would want to help with that... looks like 1.1 is not compatible with 1.0.1... but also looks like that might not be a bad thing: Pluto 1.1 introduces a new container architecture. If you are embedding Pluto in your portal, realize that 1.1 is not binarily compatible with Pluto 1.0.x. Pluto 1.1 aims to simplify the architecture in order to make it more user and developer friendly. You should find Pluto 1.1 easier to get started with, easier to understand, and easier to embed with your portal. Your feedback regarding how far we've come is always welcome on the user and developer mailing lists! I don't know much abort portal muck, so I can't really show how much better 1.1 might be... but I know that there have been some issues with the console asis now to get stuff like plugin porlets installed dynamically... perhaps 1.1 can help solve some of these issues? Anyone know? --jason
[BUILD] TRUNK: Failed for Revision: 514164
Building with Maven version: 2.0.5
Revision: 514164 built with tests skipped
See the full build-1000.log file at
http://people.apache.org/~prasad/binaries/20070303/build-1000.log
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
[INFO] [car:package]
[INFO] Packaging module configuration:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/plan/plan.xml
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from axis2-m2-repo
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from codehaus-snapshots
[INFO] snapshot
org.apache.geronimo.modules:geronimo-persistence-jpa10-builder:2.0-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] Building jar:
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
/home/prasad/geronimo/trunk/configs/persistence-jpa10-deployer/target/persistence-jpa10-deployer-2.0-SNAPSHOT.car
to
/home/prasad/.m2/repository/org/apache/geronimo/configs/persistence-jpa10-deployer/2.0-SNAPSHOT/persistence-jpa10-deployer-2.0-SNAPSHOT.car
[INFO]
[INFO] Building Geronimo Configs :: OpenJPA with dependencies
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/prasad/geronimo/trunk/configs/openjpa/target/classes/META-INF
[INFO] Copying 2 files to
/home/prasad/geronimo/trunk/configs/openjpa/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/home/prasad/geronimo/trunk/configs/openjpa/target/plan/plan.xml
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-all:pom:0.9.6-incubating' from repository
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading:
http://ws.zones.apache.org/repository2//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-all:pom:0.9.6-incubating' from repository
axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-all/0.9.6-incubating/openjpa-all-0.9.6-incubating.pom
3K downloaded
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-xmlstore:pom:0.9.6-incubating' from repository
tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Downloading:
http://ws.zones.apache.org/repository2//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
[WARNING] Unable to get resource
'org.apache.openjpa:openjpa-xmlstore:pom:0.9.6-incubating' from repository
axis2-m2-repo (http://ws.zones.apache.org/repository2/)
Downloading:
http://people.apache.org/repo/m2-incubating-repository//org/apache/openjpa/openjpa-xmlstore/0.9.6-incubating/openjpa-xmlstore-0.9.6-incubating.pom
1K downloaded
Downloading:
http://tomcat.apache.org/dev/dist/m2-repository//org/apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.0.1/geronimo-j2ee-connector_1.5_spec-1.0.1.jar
[WARNING] Unable to get resource
'org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0.1' from
repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository/)
Do
Looks like JBoss is abandoning Tomcat
Haven't really looked at this yet, Does anyone know if this is a Tomcat fork ? http://labs.jboss.com/file-access/default/members/jbossweb/freezone/ dist/1.0.1.GA/jbossweb-usersguide.pdf
Re: Jars in the dist
It doesn't... I just commit the change to use 1.0.5 and include the new legal fluff. --jason On Mar 2, 2007, at 3:29 PM, Donald Woods wrote: castor-0.9.5.3 is a prereq for Pluto. I haven't tried using the newer version with Pluto to see if it breaks us yet. -Donald Jason Dillon wrote: On Mar 2, 2007, at 1:17 PM, Davanum Srinivas wrote: Team, #1) 2 versions of castor jar are present. Do we even need castor jar? castor-0.9.5.3.jar castor-1.0.5.jar I hope we can use the newer... never tried to see if that works or not though... #2) We need to get rid of activation-1.1.jar from Sun. (i will have to change axis2 pom's) #3) We could use saaj-api and jaxws-api jars from Axis2 instead of the sun versions #4) We need to get rid of mail-1.4.jar from Sun. (i will have to change axis2 pom's) #5) I guess xpp3-1.1.3.3.jar is needed by xstream-1.1.3.jar? Yes. #6) Do we really need to ship junit-3.8.1.jar? No, something probably has that set to a non-test scope and its getting sucked in. --jason
Re: Jars in the dist
Looks like castor 1.0.5 works fine with pluto 1.0.1 and our console. The console-testsuite passes too... 'cept for one time that it prompts for user-auth, but I don't think that is related to castor change... but manually typing in system/manager there and the entire suite passes. Looks like the console-testsuite prompts for some user- auth w/the current castor too. --jason On Mar 2, 2007, at 10:15 PM, Dain Sundstrom wrote: On Mar 2, 2007, at 1:22 PM, Jason Dillon wrote: On Mar 2, 2007, at 1:17 PM, Davanum Srinivas wrote: Team, #1) 2 versions of castor jar are present. Do we even need castor jar? castor-0.9.5.3.jar castor-1.0.5.jar I hope we can use the newer... never tried to see if that works or not though... OpenEJB uses castor to load two files still. OpenEJB is using version 1.0.5. -dain
