Geert,
What has happened is Maven is becoming more of a limitation than a help
right now. I have had to change my structure of my application to reduce
the complexity so this is no longer an issue. Regardless, I am running into
yet another Maven induced issue that should be on the mailing list right
now. Feel free to look at it as I think the other problem stems from the
same issue that was causing my Deployer not to work.
Take care,
Jeremy
On 12/19/06, Geert Bevin <[EMAIL PROTECTED]> wrote:
Hi Jeremy,
yeah, I want this to be fully tracked down and working. It would
probable be nice to get an overview of the directory hierarchy of
your project and its files so that I get an idea of what you're
working with. Additionally, I would need to know what the working
directory is when you use "mvn jetty:run". I suppose I should set
this up myself to see if this fails in a minimal testcase too. Could
you continue this on the list, thanks?
Take care,
Geert
On 19 Dec 2006, at 18:45, Jeremy Whitlock wrote:
> Geert,
> I've been sending them only to you since I was including code
> that may had spawned other non-open discussions. I am happy
> sending my following requests to the list. Just so you know, I did
> set the rife.webapp.path to the directory that contains the WEB-INF
> directory but it didn't fix things. I did make progress though.
> Maven has a Jetty plugin that allows you to run a Maven web
> application. If I run "mvn jetty:run", it fails. If I run "mvn
> jetty:run-war" or "mvn jetty:run-exploded", it runs properly.
> Since I have it working, I'm no longer concerned but if you want to
> continue working on this, let me know and I will send a mail to the
> RIFE users list.
>
> Take care,
>
> Jeremy
>
> On 12/19/06, Geert Bevin <[EMAIL PROTECTED]> wrote: Btw, do you mean
> for your emails to only go to me privately instead
> of to the list? I prefer to go through the mailinglist, since this
> allows others to learn from this too (and later search for it).
>
> Would you mind resending this email, so that I can reply again on the
> list?
>
> On 19 Dec 2006, at 00:36, Jeremy Whitlock wrote:
>
> > Bevin,
> > I remember most of the conversation today but I still have a
> > minor misunderstanding. I have consolidated everything into one
> > application. When I combine the applications into one, I still get
> > the same problem. Here is some example code:
> >
> > @Override
> > public void deploy() throws EngineException {
> > try {
> > Config config = Config.getRepInstance();
> >
> > System.out.println (config);
> >
> > cBean = new SACConfigurationBean();
> >
> > cBean.initialize();
> >
> > bootstrapBundle();
> > bootstrapConfiguration();
> > } catch (Exception e) {
> > e.printStackTrace ();
> > }
> > }
> >
> > In the System.out.println() in the ElementDeployer, I get a Config
> > reference. If I do the same Config creation and System.out() in
> > the SACConfigurationBean's initialize() method, I get null which
> > leads to an NPE when trying to set the values based on the Config
> > reference, which you have the source code already. How does
> > setting the RIFE system property fix this? I'm not sure it will.
> > This is very confusing because now, the ElementDeployer,
> > SACConfigurationBean and all other application classes/resources
> > are all in the same war file but not within a .jar.
> >
> > Funny thing is that I can run the application flawlessly when the
> > application is warred up but when I run it via Maven, I can set the
> > rife.webapp.path and it does not affect the application's problem.
> > I'm not sure what the problem is but I attribute it to Maven, Jetty
> > or something else besides Maven. It sucks but it now is not your
> > problem. :)
> >
> > Take care,
> >
> > Jeremy
> >
> > On 12/16/06, Geert Bevin < [EMAIL PROTECTED]> wrote: Hi Jeremy,
> >
> > it looks to me that you simply have classpath issues. I think that
> > the classloader that is used from within your elements somehow isn't
> > the same as the classloader that is used when the repository starts
> > up. This is the only explanation that I can think of. It will result
> > in this behavior since the static reference to the default
> repository
> > will be different for the both pieces of code.
> >
> > I added your code to the jumpstart and used exactly the files and
> > configurations that you provided, and the config instance is
> > correctly retrieved. I get another error later, but that is about
> > something else, the initialize() method of SACConfigurationBean has
> > already run by then:
> > java.lang.NullPointerException
> > at net.collab.extranet.sac.elements.ApplicationInitializer
> > $Deployer.bootstrapConfiguration(ApplicationInitializer.java:61)
> > at net.collab.extranet.sac.elements.ApplicationInitializer
> > $Deployer.deploy(ApplicationInitializer.java:34)
> > at com.uwyn.rife.engine.ElementInfo.deploy(ElementInfo.java:
> > 280)
> > at com.uwyn.rife.engine.SiteBuilder.setupElements
> > (SiteBuilder.java:984)
> > at com.uwyn.rife.engine.SiteBuilder.setupData
> > (SiteBuilder.java:1618)
> > at com.uwyn.rife.engine.SiteBuilder.finish
> (SiteBuilder.java:
> > 261)
> > at com.uwyn.rife.engine.SiteBuilder.process
> > (SiteBuilder.java:252)
> > at com.uwyn.rife.engine.SiteBuilder.getSite
> > (SiteBuilder.java:178)
> > at com.uwyn.rife.rep.participants.ParticipantSite.initialize
> > (ParticipantSite.java:36)
> > at com.uwyn.rife.rep.BlockingParticipant.run
> > (BlockingParticipant.java:252)
> > at java.lang.Thread.run (Thread.java:613)
> >
> >
> > Do you get this error in development mode or when you create a war
> > file? Normally, with a war file you shouldn't have to worry about
> > classpath issues at all, it should just work inside a servlet
> > container. If the error disappears like this, it's 100% sure that
> > something isn't totally right with how things are setup for
> > development. I suggest that you double-check that all locations
> where
> > classes and resources are read from for usage inside your web
> > application are added to the rife.webapp.path JVM property, however
> > leave servlet container jars outside of it. A good rule is to
> include
> > just the directories that will end up inside the file .war file. You
> > don't need to add each individual one if they all have the same
> > parent directory, you can then simply use the parent path. However,
> > if you do that you have to be careful again that the parent path
> > doesn't also contain directories that contain classes or jar files
> > that shouldn't be packaged in the war file.
> >
> > I hope this helps, let me know how it goes.
> >
> > Best regards,
> >
> > Geert
> >
> > On 16 Dec 2006, at 06:45, Jeremy Whitlock wrote:
> >
> > > Geert,
> > > The source you have is for when I had the System.out.println
> > > (config) in there. This means that with the line breaks and the
> > > System.out call, the NPE occurred during the first call to
> > > config.getString(). Trust me, I ran the debugger and have
> > > outputted the config object to verify that this is in fact due to
> > > the Config being null and not a value I look for. Just to verify,
> > > here is the new error output with the proper matching line
> numbers:
> > >
> > > java.lang.NullPointerException
> > > at
> > > net.collab.extranet.sac.beans.SACConfigurationBean.initialize
> > > (SACConfigurationBean.java:28)
> > > at net.collab.extranet.sac.elements.ApplicationInitializer
> > > $Deployer.deploy (ApplicationInitializer.java:31)
> > > at com.uwyn.rife.engine.ElementInfo.deploy
> (ElementInfo.java:
> > > 280)
> > > at com.uwyn.rife.engine.SiteBuilder.setupElements
> > > ( SiteBuilder.java:984)
> > > at com.uwyn.rife.engine.SiteBuilder.setupData
> > > (SiteBuilder.java:1618)
> > > at com.uwyn.rife.engine.SiteBuilder.finish
> (SiteBuilder.java:
> > > 261)
> > > at com.uwyn.rife.engine.SiteBuilder.process
> > > (SiteBuilder.java:252)
> > > at com.uwyn.rife.engine.SiteBuilder.getSite
> > > (SiteBuilder.java:178)
> > > at
> com.uwyn.rife.rep.participants.ParticipantSite.initialize
> > > (ParticipantSite.java:36)
> > > at com.uwyn.rife.rep.BlockingParticipant.run
> > > (BlockingParticipant.java:252)
> > > at java.lang.Thread.run (Thread.java:595)
> > >
> > > This stack trace matches the code I emailed earlier. I know you
> > > are doing your due diligence but I assure you, the problem is
> > > because the Config object is null. I can add a System.out.println
> > > (config) if you'd like.
> > >
> > > Take care,
> > >
> > > Jeremy
> >
> >
> > --
> > Geert Bevin
> > Uwyn "Use what you need" - http://uwyn.com
> > RIFE Java application framework - http://rifers.org
> > Music and words - http://gbevin.com
> >
> >
> >
>
> --
> Geert Bevin
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
>
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
