Re: building an internal Maven repo for archive purposes?
On Tue, Jan 29, 2008 at 05:16:37PM -0500, Donald Woods wrote: > > maven-proxy > Mirror of all required maven repos > http:///maven-proxy/repository > * > I just noticed something odd. There's a "repository" directory in the Geronimo source tree (at least the 2.0.2 tree) and it appears as if the way it works is to set itself up as a remote repo and then "depend" the jars into the user's cache repo. By setting the "mirrorOf" to "*" you also override that in-tree repository so the jars come from the outside world. Is this kosher or is there an "except for" syntax that I can use in the mirrorOf element? Thanks, Toby
Re: building an internal Maven repo for archive purposes?
Thanks Donald, Your (and Iain's) tip about settings.xml was on the money - it appears that it's the only way to get Maven to *not* pull things from repo1.maven.org. It's a shame that it's a user-level setting as I'd like to be able to track some projects (such as the Geronimo trunk) online, and keep others (such as our internal build of 2.0.2) entirely offline. I'll just have to remember to switch settings.xml back and forth. Thanks for your tip about maven-proxy, it looks interesting. I was hoping to be able to simply serve up a pile of files, since we run apache httpd but not Java app servers in our corporate infrastructure. Unfortunately, Maven complains that it can't find a valid version of org.apache.maven.plugins:maven-site-plugin in my internal repo even though the same bits are there as are online. So I might have to go with the servlet approach. Regards, Toby
Re: deploy vs redeploy
On Wed, Jan 30, 2008 at 02:53:36AM -0800, MarcoLaponder wrote: > In my autmatated build script is use the deploer jar to deploy my EAR, but as > I am not aware if my ear is already loaded I would like to a deploy if it > not present or a redeploy if it is already present. What is the best way to > accomplish this ? In 1.0 I started the server in the background (since I couldn't get the offline mode to work) then ran the distribute command which would work in either case. In 2.0.2 --offline works so I run offline undeploy and ignore any errors, then run offline deploy. It's ugly but it seems to work OK.
Re: building an internal Maven repo for archive purposes?
On Tue, Jan 29, 2008 at 08:13:08AM +, iain starks wrote:
> I expect you want to look in settings.xml which can be in a number of
> places but yours is likely in ${MAVEN_HOME}/conf
Thanks Iain, that's a good tip.
I have such a file but it's all comments and no file in the
$MAVEN_HOME tree contains the string "repo1". The hunt for repo1
continues!
Thanks,
Toby
building an internal Maven repo for archive purposes?
Hi Folks, I've been told that it's a "best practice" to build a Maven repo on the corporate intranet and use that for building copies of Geronimo that I might want to build months (or years) from now. Seems reasonable, so I'm trying, but it's a challenge to get Maven to use my internal repo and not external ones. I started by setting up a copy of my ~/.m2 tree (minus the jars that Geronimo builds locally) on an internal web server and modifying the top-level pom.xml to use only that repo. That works most of the time, i.e. Maven makes ~599 attempts to download files from there. Unfortunately, it seems to be making 290 attempts to download files from repo1.maven.org, which I can't find in any of the pom.xml files in the source tree so I don't know how Maven learned about it (unless it's built into Maven). Any help appreciated. Thanks, Toby
Re: "Browse Space" wiki link broken?
Hi Hernan, Thanks for the info, server migrations are always challenging. The link is http://cwiki.apache.org/confluence/pages/listpages.action?key=geronimo but it's no big deal, I'll try again on Monday. Thanks, Toby
"Browse Space" wiki link broken?
Hi Folks, I'm getting back into Geronimo after a long absence (which means that 1.0 is working well for us) so I'm coming up to speed with the many changes, including infrastructure. When I try to follow the "Browse Space" link on the wiki I get: > HTTP Status 404 - /confluence/pages/listpages.action > > type Status report > > message /confluence/pages/listpages.action > > description The requested resource (/confluence/pages/listpages.action) is > not available. > Apache Tomcat/5.5.16 Is this to be expected? The reason I tried to follow that link is that I'm guessing that there are a lot more pages in the wiki than there are links on the front page. Is there another way to get a list of the wiki pages? Thanks, Toby
Re: stress test performance issue
On Fri, Jul 14, 2006 at 01:01:11PM +0200, [EMAIL PROTECTED] wrote: > I was thinking that could be a possibility. Is there any way of confirming > this ? You could try running under a profiler, but those tend to be pretty intrusive so I'd start by playing around with the command-line params that affect GC. For example, if you're using a Sun VM you can get GC stats using -Xloggc:. You can also try running Geronimo with more or less memory and see if that affects the frequency of the "hiccups". Run "java -X" for some info on the command-line flags.
does 1.1 support manifest classpath entries?
Hi Folks, I'm fooling around with a 1.1 build and trying to get my little "hello, world" application to deploy and run. It mostly does (much thanks to the plan conversion utility) but one feature doesn't seem to work as it used to. My EAR has (among other stuff) a webapp in a war, and a jar with some utility classes in it. In 1.0 I could put the utility jar name in the war's manifest.mf file like so: Class-Path: hello-utility.jar ... and the classes in hello-utility.jar would be visible to the servlets in the war. In 1.1 this doesn't seem to work (I get NoClassDefFoundError exceptions at deploy-time). Now I'm not sure if what I was doing was J2EE-kosher to begin with so if not that's cool. But if it's *supposed* to work I'm not sure that it does anymore. Thanks, Toby
Re: User Feedback Request -- this means you!
Hi David! On Tue, Mar 28, 2006 at 12:00:35PM -0800, David Blevins wrote: > So this is the first of what I think should be a quarterly event. > Geronimo is ultimately your project and we committers are but your > humble servants. To serve you best, we need some critical high level > feedback to help us steer the project and focus on what matters most > to you! OK, I'll start with things I like about Geronimo. At the top of the list would have to be messages like yours. Working with the Geronimo team is a pleasure, and I can't say that about every open source project that I've worked with. I like the emphasis on making things "just work." There's lots to be done in that area (this is j2ee after all) but over the last couple of years the dev team has made it a lot easier to deploy and run by whittling down the complexity of the DD's needed. I like that the developers think like users. Example: a couple of times I've seen deployment messages like "element foo doesn't work anymore, try element bar." Projects like Geronimo move fast, so it's hard to keep up. Pointers like this help a lot because they point me in the right direction. > Please, every user out there, give us your top 5 things we can do to > make Geronimo better for you. I think my list will be a little off-the-wall since I'm not going to focus on features: 1. There are currently 293 unassigned bugs. A few are mine, and it's discouraging. I'd suggest assigning them to a developer quickly, even if she can't work on them right off the bat. At least that way I know that someone's responsible for looking at it. 2. I've lost track of the wiki situation, but it looks as if there are still two active wikis. It would be great if these could be merged into one. 3. Better Javadoc. Geronimo's code is solid and the architecture is very robust, but a lot of what makes Geronimo cool gets lost because it's not documented in places where wanna-be developers can find it. Javadoc is a fantastic doc system, we really need to take better advantage of it. That's all I can think of for now, but I'll second the previous suggestions for more frequent releases. Thanks! Toby
Re: jetty transport-guarantee behavior?
Hi David, On Mon, Jan 30, 2006 at 03:35:52PM -0800, David Jencks wrote: > On the other hand I couldn't convince myself that the spec required > a redirect. I agree - sending a 403 appears to be spec-compliant. Sending a redirect also appears to meet the spec and is way more user- and developer-friendly, though. At the moment I've got a filter that builds an HTTPS URL and redirects the request but this requires turning the transport guarantee off, so that the filter can do its job. It's a workaround but an auto-redirect from Jetty would be great. > Maybe a greg or another jetty expert can explain how it is supposed > to work? That would be cool. Thanks, Toby
jetty transport-guarantee behavior?
Hi Folks, I've got an application that I'm running over HTTPS and I'd like to make it so that users can't connect to it over plain old HTTP. I think that the web.xml user-data-constraint/transport-guarantee element is what I'm after but I have a question about its behavior. When I set it to CONFIDENTIAL and make a request over HTTPS then all's well, and when I make the same request over HTTPS I get a 403. I suppose that this is OK, if somewhat user-hostile, but I can probably work around it using a listener or some such. I was poking around in JettyConnector.java, however, and it looks like it's trying to configure a few parameters to make Jetty automatically redirect HTTP requests over to HTTPS, but I'm not getting that behavior. So my question is: how do I enable the auto-redirect behavior? Is there a flag in a plan file that I need to set? Thanks, Toby
Re: list-targets command
Thanks Aaron and David, I've modified o.a.g.client.builder.AppClientModuleBuilder and o.a.g.deployment.Deployer to accept multiple ConfigurationStore references, so now Geronimo will run with two ConfigurationStores specified in system-plan.xml. As you guys expected, you can pass a Target to the deployment cli and it gets passed to DeploymentManager.distribute() but it's lost on the server side since the Deploy.deploy() method that gets called doesn't take a target parameter. I'm a little fuzzy on the theory of operations on the server side - i.e. how the data gets from the wire to Deployer.deploy(). It looks like it uses MX4J but if one of you could sketch out how that code gets set up I could take a look at adding the target code to Deploy tomorrow. Thanks, Toby PS. Please feel free to move this conversation over to the dev list if that's a more appropriate place for it.
Re: list-targets command
On Mon, Nov 21, 2005 at 02:24:48PM -0500, Aaron Mulder wrote: > You could in theory have multiple config-stores, for example one > read-only containing some core modules that are never supposed to > change and one read-write for new deployments. However we haven't > tested that adequately and I'm not convinced it would really work > properly right now. I believe we do intend to make this work > eventually, I just don't think it's on the very short-term horizon. This could be very useful in my application. Currently I've got geronimo running from a read-only partition which works great since the runtime configuration never changes, but it would be great to be able to put a configuration store in /var and deploy new applications there. How can I help? Given some pointers as to what's there (and maybe what's not) I'd be willing to poke around and see what works and what doesn't. Thanks, Toby
Re: packaging a custom LoginModule?
> You should be able to construct a jar including your class, and get it > into the application classloader using a > toby/jars/cabot-security-1.0.jar > element. I think I actually tested something like this when I added > support for it :-) Thanks! That's the ticket. Works great.
packaging a custom LoginModule?
Hi Folks, I need to authenticate users of a webapp running in Geronimo, but the creds come from a proprietary XML format file. My first thought was to write a quick hack in my webapp, but then I thought that I'd try it the J2EE way. So I started poking around in the guts of Geronimo's security code. Alan's "org/apache/geronimo/Demo" webapp was very helpful, as was the Security page on the wiki. I've got a trivial skeleton LoginModule that seems to work, but I can't figure out how to package it. It works if I add it to repository/geronimo/jars/geronimo-security-1.0-SNAPSHOT.jar but I doubt that this is the recommended way to go. I tried putting the files into a jar in the repository but then got ClassNotFound errors. The wiki deployment page talks about deploying services but the examples pass only a descriptor to the deployer tool, not a package. If anyone has any advice about how I should package a custom LoginModule cleanly and "J2EE"-y I'd much appreciate it. Thanks, Toby
Re: Instructions on building geronimo from svn?
On Sat, Nov 26, 2005 at 09:26:36AM -0500, Brian Bonner wrote: > I'm not exactly sure which modules I should be checking out and > building. If someone could point me to a page describing this it > would be great. Two pages on the wiki should help you get started. http://wiki.apache.org/geronimo/GettingSourceCode shows how to get the geronimo code using subversion. Then http://wiki.apache.org/geronimo/Building talks about how to build it. HTH, Toby
Re: The state of Geronimo
On Wed, Oct 19, 2005 at 03:23:28PM -0700, [EMAIL PROTECTED] wrote: > Why use Geronimo? That's the $64,000 question. At this point Geronimo is more "raw" than its commercial and open-source alternatives, so part of deciding to use Geronimo is being willing to deal with a few cuts and bruises. Pretty much any J2EE feature can be made to work, but it will require more effort (and maybe some time perusing the code) than it would with one of Geronimo's alternatives. But that's to be expected with *any* pre-1.0 product. Or in the commercial world, any pre-3.0 product. So what's the upside? For me there are a couple of things, for other people I'm sure there are more. First, the Apache license is more permissive than the GPL so if you work for a company that distributes software your lawyers will prefer Geronimo to a GPL or LGPL product. If you're using it in-house then this is less important. YMMV but I find Geronimo interesting because it's so raw. Because there's no spiffy GUI configurator I end up spending more effort but learning how Geronimo works, not just how to turn a few knobs to make it do something. This often requires some work on evenings and weekends since I don't expect my employer to indulge my curiosity, but for me it's worth it. On a more touchy-feely level, I've found the Geronimo community to be very easy and pleasant to work with. They want to teach people "how to fish" with Geronimo. They're cooperative and patient. This is good because you'll probably need their help to get a non-trivial J2EE application running in Geronimo. So if you're looking to roll down the fall-line I'd recommend one of Geronimo's alternatives. If you've got some time and some curiosity then Geronimo is for you. Good luck, Toby
Re: Security app--demo app in source tree
On Thu, Oct 13, 2005 at 12:24:09PM -0700, [EMAIL PROTECTED] wrote: > ok, I'm looking at the demo app. I can find the user > name passwords, etc. So I've got it up and running on > localhost, but I always get the error page. > > I'm sure this is a simple error, or something I > haven't come across yet. I've been playing around with this and in order to get all of the gbeans to start I had to tweak one of the config files: http://issues.apache.org/jira/browse/GERONIMO-1061 You'll know if this is the problem if you've got some gbeans that are stuck in the "starting" state and don't transition to "running". If this is your problem you can hack the file and then rebuild the modules/assembly directory.
Re: Security app
On Wed, Oct 12, 2005 at 02:41:35PM -0700, [EMAIL PROTECTED] wrote: > I'm looking into building a simple application that > implements the security features of Geronimo that can > later be built upon. You'll probably want to take a look at the demo application in the applications/demo directory of the geronimo source tree. It implements some of what you're looking for, although it isn't as dynamic as what you're proposing. It uses a couple of properties files (var/security/demo*.properties) to store the user and group data, and then sets up Geronimo's properties-based login manager to read those files. It will probably give you some useful pointers at least in terms of the configuration that you'll need.
Re: proposal for new site
> Ok. Will do that. Want to keep helping? :) Sure!
Re: proposal for new site
> We've been talking about new site content for a while, so I threw > together a quick, simple site that uses velocity and simple xml-based > documents for content. Looks much better than the old site! Based on discussion on the -user list in February I submitted bug 575 which was an attempt to stem the "is Geronimo alive?" questions that popped up from time to time. You might want to take a look at that patch to see if there's any text that you can use. You can at least close the bug ;) http://issues.apache.org/jira/browse/GERONIMO-575
Re: When can we expect geronimo 1.0?
On Tue, May 17, 2005 at 10:58:32AM -0400, Geir Magnusson Jr. wrote: > > On May 12, 2005, at 6:25 PM, toby cabot wrote: > > >On Thu, May 12, 2005 at 05:24:55PM -0400, Geir Magnusson Jr. wrote: > > > >>You are right. Our website is awful. THanks for volunteering! :) > >> > > > >The more the merrier, but please base your work on > >http://issues.apache.org/jira/browse/GERONIMO-575 so we don't re-do > >the same things. > > Cool! So this is just static to be applied directly? Yup. Here's some background: There was yet another "is Geronimo dead" thread on this list back in February and people seemed to think that the web site needed a freshening so I volunteered. Unfortunately, the mailing list archive for February 2005 seems to have been lost so that conversation isn't available anywhere. But I tried to respect the consensus that came out of it and I think that my changes are pretty benign. The biggest change is adding a lot of "we're not dead just working on certification" verbiage. You can take a look at http://www.caboteria.org/~tobyc/g6o-docs/ > I was thinking of tossing the maven site completely and starting from > scratch with something simple. That's a good idea. One of the problems with the auto-generated site is that a lot of the pages are "stubs" that don't have any useful content but Maven doesn't know to *not* generate them. A few hand-coded pages with lots of links to the wiki would probably be a lot more user-friendly because there would be fewer "dead ends."
Re: When can we expect geronimo 1.0?
On Thu, May 12, 2005 at 05:24:55PM -0400, Geir Magnusson Jr. wrote: > You are right. Our website is awful. THanks for volunteering! :) The more the merrier, but please base your work on http://issues.apache.org/jira/browse/GERONIMO-575 so we don't re-do the same things. Cheers, Toby
Re: Nightly builds?
There was another discussion about the stale website a few weeks back. There's a refresh to the web site in the Jira queue: http://issues.apache.org/jira/browse/GERONIMO-575
Re: deploying minimal web app
On Thu, Mar 31, 2005 at 02:46:32PM -0800, Scott Anderson wrote: > Deployment failed > Server reports: No deployer present in kernel I use the "distribute" command to deploy my application and get this error if there's an instance of Geronimo running when I run the deployer. Not sure whether it applies to you...
Re: ANN: Geronimo 1.0-M3 Release
Bruce, Geronimo Team, "What we've got here, is a failure to communicate." There's a difference between "progress" and "the appearance of progess" and both are important. There's a *lot* of progress happening, and you guys are justifiably proud of that progress, but the message that you're getting here is that it's harder than it should be for "outsiders" to figure that out. It's probably hard for people to really understand this if they're too close to the project, but as a gedankenexperiment try pretending that you're some random guy that's heard about Geronimo and wants to find out more about it. So you go to geronimo.apache.org, maybe look at the releases on the front page, maybe click on the "news" link, and for 99.99% of the people that's it, they're gone. I think you'll agree that from that perspective the *appearance* of progress is way out of line with the *actual* progress. I think that will probably push a lot of people away. If nothing else, it's troll food. So in the spirit of constructive criticism I'll offer a few suggestions that I hope will make the *appearance* of progress more closely reflect the *actual* progress: 1. The code in the svn repo is light years more functional than the code on the front page of the website, and releases are disruptive and time-consuming (and thus infrequent), so maybe someone can add a note to the "Downloads" section of the home page, something like: Geronimo development is moving quickly, so we recommend that you get a copy of the source code and build it, rather than use any binary release that's more than a month old. By building from source you'll get the latest functionality and you'll also be one step closer to being able to contribute to Geronimo. Instructions for building Geronimo can be found on the Geronimo wiki at http://wiki.apache.org/geronimo/Building. 2. From mailing list traffic I've seen it looks as if the source releases are broken (at least the tarballs), and they're definitely obsolete and unmaintained, so why not just get rid of them entirely? People who are interested in the code would be *much* better served by getting it from source control. 3. A couple of people mentioned that a lot of work is going on behind the scenes that can't be publicised because of agreements with Sun, etc etc. So why not add a note to the News page indicating that? Something like: The Geronimo Development Team is now working on J2EE certification. Because of our agreements with Sun we're not allowed say anything specific about our status, but we're working hard and making progress! 4. There *is* a lot more news about Geronimo than is on the news page. Didn't EJBQL just land the other day? That's significant! Maybe moving news to the wiki would make it easier for folks to add items that they think are important. Hell, if nobody's got the time to add items to the news page maybe the link on the home page should point to http://wiki.apache.org/geronimo/RecentChanges . That page isn't all that easy to read but at least it's got lots of recent changes to it. I believe that a small amount of time spent bringing appearances in line with reality would be well spent in terms of saving time by not having discussions like this one. It might even attract more people to Geronimo, at least it won't turn them away. If folks agree with the gist of these ideas I can submit a patch to the web site. Regards, Toby
Re: JavaWorld Article and Certification Claims
Jboss is licensed under the LGPL, and the LGPL is an OSI certified license[1] as well as a Free Software license[2]. So while the term "open source" means different things to different people I'd claim that Jboss is "open source" using a very common definition of the term. regards, Toby P.S. Does anyone else find this talk about corporations co-opting the open source process to be ironic? After all, the term "open source" was invented to water down the idea of Free Software so it would be more palatable to corporations. And whether you prefer the LGPL or the Apache License, it's a point of fact that the Apache License is much more permissable than the LGPL is. Let's say I'm a company and I'd like to build a product around an open source application server. Let's say that I'd prefer to take from the community but give nothing back. I'd be allowed to do that with an Apache-licensed project but not an LGPL project, so which license protects the community better? Note that I'm not advocating on behalf of either license, I think that both are useful. I'm just saying that the Apache license is much more business-friendly than the LGPL (which is more business-friendly than the GPL). [1] http://www.opensource.org/licenses/ [2] http://www.gnu.org/licenses/license-list.html
Re: geronimo/jetty https?
Thanks Jeremy! I'm making good progress with your help. I've started a wiki page with my notes so far: http://wiki.apache.org/geronimo/JettySSL Regards, Toby
geronimo/jetty https?
Hi folks, I'd like to experiment with running Geronimo/Jetty with https. I can't find much info on the wiki or google, so here I am with hat in hand asking if anyone has some pointers. For example, does Geronimo come up with https enabled already? If not where should I start to look? Thanks, Toby
Re: Geronimo JNDI properties
On Wed, Aug 25, 2004 at 11:13:45AM +0200, Jacek Laskowski wrote:
> Just saw the thread, and I'm concerned with the system properties and
> the JNDI factories. Would you send me an example that proves it?
Hi Jacek,
Thanks for the help. Here's the story:
If I set up a simple EJB (like the ones used in the OpenEJB remote
tests) and call it remotely it works fine if I specify the 4
parameters needed in code
Properties p = new Properties();
p.put("java.naming.factory.initial",
"org.openejb.client.RemoteInitialContextFactory");
p.put("java.naming.provider.url", "127.0.0.1:4201");
p.put("java.naming.security.principal", "myuser");
p.put("java.naming.security.credentials", "mypass");
And it also works if I put the first two on the command line
Properties p = new Properties();
p.put("java.naming.security.principal", "myuser");
p.put("java.naming.security.credentials", "mypass");
$ java
-Djava.naming.factory.initial=org.openejb.client.RemoteInitialContextFactory
-Djava.naming.provider.url=127.0.0.1:4201 etc...
but if I try to put the java.naming.security.principal on the command
line
Properties p = new Properties();
p.put("java.naming.security.credentials", "mypass");
$ java
-Djava.naming.factory.initial=org.openejb.client.RemoteInitialContextFactory
-Djava.naming.provider.url=127.0.0.1:4201
-Djava.naming.security.principal=myuser etc...
then I get
javax.naming.ConfigurationException: Context property cannot be null:
java.naming.security.principal
at
org.openejb.client.JNDIContext.getInitialContext(JNDIContext.java:163)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.(InitialContext.java:195)
at g6o.ServerUnitTest.newOpenEJBInitialContext(ServerUnitTest.java:50)
at g6o.ServerUnitTest.findStatelessSessionBean(ServerUnitTest.java:118)
at g6o.ServerUnitTest.testPing(ServerUnitTest.java:95)
I thought that perhaps junit wasn't passing the properties through,
but since the first two get propagated I think that's not likely to be
the problem.
If you'd like me to send you code please let me know.
Regards,
Toby
Re: Geronimo JNDI properties
On Wed, Aug 18, 2004 at 11:40:43PM +0530, Sai Arunachalam wrote: > Exception in thread "main" javax.naming.NoInitialContextException: > Cannot instantiate class: > org.openejb.client.RemoteInitialContextFactory [Root exception is > java.lang.ClassNotFoundException: > org.openejb.client.RemoteInitialContextFactory] That's progress. It looks as if the properties are OK but now you don't have all of the jars that you need on the classpath. Here's a fragment that I use: java -classpath lib/geronimo/geronimo-security-1.0-SNAPSHOT.jar:lib/openejb/openejb-core-2.0-SNAPSHOT.jar:lib/openejb/cglib-full-2.0.jar:lib/sun/j2ee.jar You might not need Sun's j2ee jar, I might have that left over from some other stuff I was doing. RemoteInitialContextFactory is in openejb-core-2.0-SNAPSHOT.jar, and I'm pretty sure that you need cglib as well. You can experiment and figure out what works for you. Hint: if you get a ClassNotFoundException then you need to start running "jar tv" on the jars that you've got to see which one has the class that you're looking for. Put that one on the classpath and try again. You're almost there.
Re: Geronimo JNDI properties
On Wed, Aug 18, 2004 at 07:32:59PM +0530, Sai Arunachalam wrote: > Hi, > I am trying to run a stateless session HelloWorld example that > comes with MasteringEJB2 (it is meant for WebLogic 6.1) on Geronimo. My understanding is that at the moment OpenEJB uses its own JNDI provider so you can get the property values, etc from http://www.openejb.org/hello-world.html . The only caveat that I'd add is that it doesn't look as if OpenEJB picks up the properties from the system properties so you need to specify them explicitly (like they do on that page). > The HelloWorld.jar gets deployed on the server and I am able to start > the server with the appropriate configId but ain't able to run the > client. I am getting the following exception: > > Exception in thread "main" javax.naming.NameNotFoundException: HelloHome This looks like a JNDI error so I'd check the properties from the above page and try again.
Re: Is geronimo compatible with resource adapters deployed in weblogic
On Thu, Aug 12, 2004 at 01:50:41PM +0530, Sai Arunachalam wrote: > Not sure. > I've found that this isn't needed - geronimo will load the values from the ra.xml config-property elements without needing an entry in geronimo-ra.xml, at least for resource adapters so it should work for connection factories, too. > > > two more related tags are and > I'm not sure, but I'd say that these look like tuning parameters to me so you're probably OK for testing without them. I think that the schema for the geronimo-config.ra file is modules/connector/src/schema/geronimo-connector_1_5.xsd in the geronimo source tree.
