Re: Java AdventureBuilder application deployment

2006-01-03 Thread Jakob Færch (Trifork)

ram me wrote:
> I am trying to distribute the Java Adventure Builder into Geronimo1.0,

Interesting - it's exciting to see if the deployment can be reproduced.


> I have some problem in the distribution of  Order Processing Center (opc)
>
> It shows this error
> Unable to set attribute port to ${smtpPort}
> org.apache.geronimo.common.DeploymentException: Unable to set attribute
> port to ${smtpPort}

The ${smtpPort} value is intended to be replaced with the value of 
smtpPort from the project.properties file.


Do you use the plans from sandbox/adventurebuilder in a source checkout?

You should be able to issue the command
 maven -o
in a prompt in the adventurebuilder directory; this will replace the 
values automatically.


Please let the list know if this helps.

Kindly,
Jakob


Re: Java Adventure Builder Reference application. Issues with the tomcat distribution, issues with the javamail implementation

2005-12-23 Thread Jakob Færch (Trifork)

David Jencks wrote:

I can't seem to find them anywhere in the "normal" source checkout  I 
have got by following the Wiki instructions on wiki.apache.org/geronimo/GettingSourceCode>.



Get them from http://svn.apache.org/viewcvs.cgi/geronimo/specs/trunk/



Well, the actual 1.0 specs should be from

https://svn.apache.org/viewcvs.cgi/geronimo/specs/tags/1_0/

although I think there are no differences at this point.

To build (with maven 2) I think you just type

mvn

Hope this is not too nit-picky and is helpful


Not at all nit-picky!

Worked like a charm - although i had to
 - checkout using svn and URL 


 - run "mvn install" instead of "mvn"
to make the build work.

Thanks a lot.

Jakob


Re: Java Adventure Builder Reference application. Issues with the tomcat distribution, issues with the javamail implementation

2005-12-22 Thread Jakob Færch (Trifork)


I got at few conflicts when updating. First thing tomorrow I will 
resolve them, check that the application deploys and seems to be working 
on my system, then I'll attach a new patch.


I'm trying to make the status mails work. I'll look further into that 
tomorrow; hopefully my cry for help on the user list will help me decide 
 what to do next.


Jakob


Hi Jacek

Using the 1.0 prerelease from 
, 
I get ClassNotFoundException: org.apache.jasper.servlet.JspServlet when 
booting the server using the tomcat build. It seems the error occurs for 
 every webservice-enabled bean in the application.


I've included the stacktrace from the log for one of the beans. Do you - 
or anyone else who might be reading this - have any idea what is going on?


If I exchange the artifactId for the unpackServer goal to use the 
geronimo-jetty-j2ee distribution, everything seems to work all right; no 
errors on startup, and the orders I submit seems to be processed all the 
 way to 'completed' state.


I guess I'm just experiencing problems with the tomcat distributions 
created so far, but we still have to sort this out when the 1.0 enters 
final.


I continue looking into the problems sending mail; I think I have 
tracked the problem down to an anomaly in the Geronimo implementation of 
 javax.mail.internet.MimeMessage from the 
geronimo-javamail_1.3.1_spec-1.0.jar.


The behaviour I'm seeing is that To receipients set on a MimeMessage msg 
using msg.setRecipients isn't returned by msg.getAllReceipients().


Do you know if it's documented somewhere how to get hold of the spec 
sources and build them? I can't seem to find them anywhere in the 
"normal" source checkout I have got by following the Wiki instructions 
on .
I can find the source for the specs at 
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-spec-javamail/src/, 
and it seems like it could be the source for the 
geronimo-javamail_1.3.1_spec-1.0.jar, but I guess I have no way to be sure.


Also, do you (or anyone else) know if newer version of the javamail spec 
 exists. I searched the JIRA for an issue like the one I'm 
experiencing, but couldn't seem to find one.
I think I might have a patch for the problem; nevertheless, I wouldn't 
want to waste time trying to solve a problem which might be fixed in a 
newer version.


That was a lot of questions from me; I hope someone will take the time 
to answer some of them - that would bring us a little nearer the end of 
this, I think.


Jakob


19:37:34,113 INFO  [ContextConfig] Missing application web.xml, using 
defaults only 
StandardEngine[Geronimo].StandardHost[localhost].StandardContext[/webservice/WebServiceBroker]
19:37:34,193 ERROR [[/webservice/WebServiceBroker]] Error loading 
WebappClassLoader

  delegate: true
  repositories:
--> Parent Classloader:
[org.apache.geronimo.kernel.config.MultiParentClassLoader 
id=org/apache/geronimo/OPC1.0.3]

 org.apache.jasper.servlet.JspServlet
java.lang.ClassNotFoundException: org.apache.jasper.servlet.JspServlet
	at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1338)
	at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1187)
	at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1027)

at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:925)
	at 
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3880)
	at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4141)
	at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)

at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
	at 
org.apache.geronimo.tomcat.TomcatContainer.addWebService(TomcatContainer.java:337)
	at 
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke()

at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
	at 
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
	at 
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
	at 
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)

at 
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
	at 
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
	at 
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
	at 
org.apache.geronimo.webservices.SoapHandler$$EnhancerByCGLIB$$4f1143be.addWebService()

at org.openejb.server.axis.WSContainer.(WSContainer.java:98)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at 
sun.reflect.NativeConstructorAcce

Re: Java Adventure Builder Reference application

2005-12-21 Thread Jakob Færch (Trifork)

Jacek Laskowski wrote:
I still haven't gotten nearer resolving the issue I was referring to 
in my mail of 2005-12-15 (the findByPrimaryKey method which doesn't 
see an entity created in the same transaction ctx).
My mail didn't foster any responses; would it be possible for you to 
ask someone who's in the know about OpenEJB whether this looks like a 
bug or a deployment issue?



I had to miss it. I'll be looking into it and will respond.


Sounds fine.

Thanks for the patches! I didn't apply them, so if you could create a 
new one with the diffs between your changes and the latest sources it 
would save me lots of time. Thanks again for your contribution!


I got at few conflicts when updating. First thing tomorrow I will 
resolve them, check that the application deploys and seems to be working 
on my system, then I'll attach a new patch.


I'm trying to make the status mails work. I'll look further into that 
tomorrow; hopefully my cry for help on the user list will help me decide 
 what to do next.


Jakob


Re: Java Adventure Builder Reference application, status

2005-12-20 Thread Jakob Færch (Trifork)
Whoohooo! I had lots of work the past week and couldn't spend much time 
on it. Thanks for taking it over during that time (but please attach 
your work to the JIRA issue as soon as possible).


To make best use of our time, maybe we should let me have a try at the 
application specific things?



What do you mean? Let's talk it over.

I haven't yet succeeden in having the maven script unpack a new server 
automatically, and the startup procedure I'm managed to get working is 
very clumsy. Maybe you could look into these issues some time? If you 
want it, I could distribute the diff on my sandbox/adventurebuilder 
directory now - if you don't need it, I'll wait until the application 
is  working.


What I meant was that it would be very nice, if you could spare the time 
to fix the unpack server/distribute application issues.


I guess from your questions regarding the maven deploy plugin that you 
might already be onto this.


I still haven't gotten nearer resolving the issue I was referring to in 
my mail of 2005-12-15 (the findByPrimaryKey method which doesn't see an 
entity created in the same transaction ctx).
My mail didn't foster any responses; would it be possible for you to ask 
someone who's in the know about OpenEJB whether this looks like a bug or 
a deployment issue?


If you could publish your changes by attaching a patch to the JIRA 
issue, it would be the best way to go on (and hopefully invite others to 
contribute). I'll be committing my changes later today.


My status is now that I've finally gotten the various web services and 
JMS queues wired up so well that I can submit and order and see it reach 
 "Completed State". I have an issue with the activity supplier sending 
quite a lot of duplicate invoices. I'll look into that today, but I 
guess it would make sense for me to create another patch.


Should I make another patch against revision 357942, or should I wait 
for you to commit your work and the patches I uploaded yesterday, and 
then make the patch against those files?


Kindly,
Jakob


Create followed by findByPrimaryKey in same transaction ctx, caller in another jar: FindByPrimaryKey fails

2005-12-15 Thread Jakob Færch (Trifork)
During adventure builder deployment, I'm running into a problem that 
looks a lot like the GERONIMO-598 Jira issue.


The setup is as follows (from the Adventure Builder 1.0.3):
opc.ear contains opc-ejb.jar and processmanager-ejb.jar
opc-ej contains
  WorkFlowManagerBean (Message Driven Bean)
processmanager-ejb contains
  ProcessManagerSB (SB)
  ManagerBean (CMP Entity Bean)

all methods involve have trans-attribute Required.

The WorkFlowManagerBean invokes (in the same transaction context) two 
methods on the ProcessManagerSB, first create, which calls create on the 
  ManagerBean home, then updateStatus, which does a findByPrimaryKey on 
the ManagerBean home (followed by a setStatus on the bean instance 
returned).


The findByPrimaryKey fails; I've verified that the same primary key is 
used on the create and the findByPrimaryKey calls.


If I change the trans-attribute on the two methods on ProcessManagerSB 
to RequiresNew, everything works fine, and I can see the ManagerBean 
entity persisted in the database.


Can anyone figure out what might be going on? The only difference from 
GERONIMO-598 I notice is the call across jar files. Maybe someone with 
more insight into OpenEJB can tell, if this could have any importance?


I've looked into the no-cache-flush mentioned in the Jira, but as far as 
I can tell, it would only make things worse.


Kindly,
Jakob


Re: Java Adventure Builder Reference application, status

2005-12-14 Thread Jakob Færch (Trifork)

Jacek Laskowski wrote:
At last I could build the latest version of Geronimo. It wasn't that 
easy as it should be. I remember having to run maven several times 
before all jars were in place and the build finished with no errors.


I'm looking into getting AB up and running in it.


My status is that I have AB deploying without errors on the (broken) 
1.0-prebuild.


Compared to the plans/sql in the repository, so far I have:
- Set up (more) correct references to web services
- Added undefined web service endpoints
- Started to get the autogenerated primary keys for CMP's working
  (using your work from the Pet Store as template)

I feel that I'm getting nearer a working AB - having got past Geronimo 
build and deployment trouble brings me nearer to my usual (J2EE 
application) domain :-)


To make best use of our time, maybe we should let me have a try at the 
application specific things?


I haven't yet succeeden in having the maven script unpack a new server 
automatically, and the startup procedure I'm managed to get working is 
very clumsy. Maybe you could look into these issues some time? If you 
want it, I could distribute the diff on my sandbox/adventurebuilder 
directory now - if you don't need it, I'll wait until the application is 
 working.


Jakob


Nonsense error "Module was not a wae" when trying to deploy web-application on server with no running jetty-deployer

2005-12-14 Thread Jakob Færch (Trifork)
I recently experienced trouble deploying an ear file containing a war 
module. After a lot of head scratching (and waste of Aaron's time) I 
discovered that the source of the error was that the jetty-deployer 
wasn't started.
The error returned by the deployer was "Module was not a war: 
Adventure.war", which didn't help me a lot to say the least.

The error is printed from EARConfigBuilder.java in module j2ee-builder.

I'm on the 1.0 build being voted about earlier today. Transcript [1] at 
the bottom of this mail exposes the error.


I know that I'm partly to blame (the jetty-deployer is active in the 
default configuration), but nonetheless someone might want to create a JIRA?


Kindly,
Jakob


Transcript [1]:
$ java -jar target/geronimo-1.0/bin/deployer.jar --user system 
--password manager distribute target/plan/consumerwebsit

e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear
Distributed org/apache/geronimo/Adventure1.0.1

~/projects/geronimo-ab/sandbox/adventurebuilder
$ java -jar target/geronimo-1.0/bin/deployer.jar --user system 
--password manager stop geronimo/jetty-deployer/1.0/car


Stopped geronimo/jetty-deployer/1.0/car

~/projects/geronimo-ab/sandbox/adventurebuilder
$ java -jar target/geronimo-1.0/bin/deployer.jar --user system 
--password manager distribute target/plan/consumerwebsit

e1.0.1.ear-plan.xml adventure1.0.3/consumerwebsite.ear
Error: Operation failed: Module was not a war: adventure.war



---
[2] Running configurations:
  + geronimo/activemq-broker/1.0/car
  + geronimo/j2ee-server/1.0/car
  + geronimo/jetty-deployer/1.0/car
  + geronimo/ldap-realm/1.0/car
  + geronimo/uddi-jetty/1.0/car
  `-> uddi-jetty @ http://jrf:8080/juddi
  `-> uddi-db
  + geronimo/online-deployer/1.0/car
  + geronimo/activemq/1.0/car
  + geronimo/directory/1.0/car
  + geronimo/j2ee-security/1.0/car
  + geronimo/j2ee-deployer/1.0/car
  + geronimo/system-database/1.0/car
  + geronimo/j2ee-system/1.0/car
  + geronimo/rmi-naming/1.0/car
  + geronimo/jetty/1.0/car
  + geronimo/webconsole-jetty/1.0/car
  `-> geronimo-console-standard-1.0.war @ 
http://jrf:8080/console-standard

  `-> geronimo-console-framework-1.0.war @ http://jrf:8080/console
  + geronimo/geronimo-gbean-deployer/1.0/car



Re: Java Adventure Builder Reference application, deployment/build issues

2005-12-12 Thread Jakob Færch (Trifork)

Jacek Laskowski wrote:

Jakob Færch (Trifork) wrote:


I guess I'm in dire need of some help with the (new?) build process.



Hi Jakob,

It seems that the new build process is a very hot topic recently. It's 
not yet described in the wiki and thus scratching your head is of a 
little help when in trouble ;)




I'll just continue working with the jetty-j2ee distribution I managed to 
build yesterday.




I tried running maven m:default in the source root, but that didn't
produce anything in ~/.maven/repository/distributions.



Why did you do that at all?


I wish I was able to provide an answer to that :-)




I copied the dependency on the javamail-spec from the "main" project.pom.
The one in sandbox/adventurebuilder seemed to inherit a
geronimo_spec_javamail_version=1.0 from etc/project.properties which
isn't healthy anymore.


Why? I thought that 1.0 is the latest version of any spec.


I'm not sure exactly what happened, but it seems related to the change 
of groupid to org.apache.geronimo on the specs. The following is in the 
sandbox/adventurebuilder/project.xml now:


  geronimo-spec
  geronimo-spec-javamail
  ${geronimo_spec_javamail_version}

but the only version my repository contained was called something like 
1.3.1-rc6.

The following snippet seems to comply with what is build by maven new:

  org.apache.geronimo.specs
  geronimo-javamail_1.3.1_spec
  ${geronimo_spec_javamail_version}

(not that I get why 1.3.1 is hardcoded into the artifactId).



While trying to distribute the application (running maven -o in
sandbox/adventurebuilder) the deployer doesn't seem to recognize the
--offline option. This might be caused by my tinkering around with the
distribution files, so I guess I'd try to fix the above first.



I remember very vaguely that offline might not work. Try starting a 
server and distribute then.


I'll try to fiddle a little with the maven.xml script and start a server 
 before deploying. I wasn't able to do it yesterday (couldn't get the 
deployer.jar to recognize the user and password options), but it seems 
the other sample apps use the maven deploy goal. I'll try if that works 
better.


Absolutely right. You'd be better off doing it online so that you won't 
have to build Geronimo yourself and download necessary dependencies as 
needed.



Perhaps all that is needed is some maven dependency, but I have
not been able to figure out which.



Take a look at samples and copy necessary parts. It hasn't changed much, 
I hope.


I'll defer getting the dependencies to work; 
<http://cvs.apache.org/repository/geronimo/distributions/> doesn't seem 
to have any recent builds, so I'm not sure there would be anything 
interesting for Maven to download.


Jakob


Java Adventure Builder Reference application, deployment/build issues

2005-12-12 Thread Jakob Færch (Trifork)

I guess I'm in dire need of some help with the (new?) build process.

After running
  maven m:clean m:clean-repo new
in the source root, the build produces (among others) a distribution
named geronimo-jetty-j2ee-1.0-SNAPSHOT.zip (in
~/.maven/repository/geronimo/distributions).

This makes the unpackServer maven goal unhappy, so I the jetty-j2ee to
geronimo-1.0-SNAPSHOT.zip (in the maven repository) to make unpackServer
happy.

I tried running maven m:default in the source root, but that didn't
produce anything in ~/.maven/repository/distributions.

I copied the dependency on the javamail-spec from the "main" project.pom.
The one in sandbox/adventurebuilder seemed to inherit a
geronimo_spec_javamail_version=1.0 from etc/project.propertis which
isn't healthy anymore.
This makes maven able to get through it's dependency resolve phase, but
to no help:

While trying to distribute the application (running maven -o in
sandbox/adventurebuilder) the deployer doesn't seem to recognize the
--offline option. This might be caused by my tinkering around with the
distribution files, so I guess I'd try to fix the above first.

My repository is at version 356264; I'd expect this to be on the trunk, 
not on the 1.0 branch, and I guess the trunk is where we wanna be, 
considering the AB issue has been re-scheduled to 1.1.

Would you please correct me if I'm wrong regarding which branch to use?

So in short, could anyone (Jacek, maybe?) do anything to help me build
Geronimo in a form compatible with the deployment code in
sandbox/adventurebuilder.

Just as welcome would be some instructions on how to avoid building the
server altogether; if I just remove all geronimo stuff from my local
repository and run maven -o in sandbox/adventurebuilder, the
unpackServer goal fails due to the distributions snapshop not being
present. Perhaps all that is needed is some maven dependency, but I have
not been able to figure out which.

Kindly,
Jakob



Re: Java Adventure Builder Reference 1.0.3 webapp deployed

2005-12-08 Thread Jakob Færch (Trifork)

Jacek Laskowski wrote:

[*Q1]
Would you like me to send you the plans I have developed - I guess the 
repository would be better off with these than with the ones currently 
there.



Send them to the list or better yet attach to the JIRA issue - 
http://issues.apache.org/jira/browse/GERONIMO-1164. Both will work fine.




I've attached a zip to the JIRA issue.


It seems to be the case that for the 1.0-SNAPSHOT builds I am able to 
produce, all "internal" configurations follow the "car" naming style 
rather than the "org/apache/geronimo"-naming style. The 1.0-M5 build I 
downloaded follow the "org/apache/geronimo"-naming style.
I guess we will have to get the application running on a build 
resembling M5.



Nope. The work is being done on the recent development builds. Of course 
you might work on the past releases, but since the application is still 
in the sandbox I wouldn't bother to support too much versions and keep 
it up-to-date. It makes it easier to promote the sample apps to the main 
build rather than keep it in the sandbox.





[*Q2]
Is there an easy way to make the maven script in 
sandbox/adventurebuilder use the M5-build. I tried changing 
geronimo_version in src/etc/project.properties to 1.0-M5, but that 
doesn't seem to do the trick.



I haven't tried it and don't think I will. Sorry. Why do you stick with 
the M5 version? If you don't want to build Geronimo from the sources, 
please check out sandbox only (and etc) and work with it. Maven will 
download the necessary components.


I guess I thought the org/apache/geronimo were the "official" names - if 
the snapshot builds are like the build we're going to support in the 
end, of course the right thing is to stick with those.



Nevertheless, when starting the server, none of the web service 
endpoint beans are able to start. As an example, for the 
CreditCardEndpointBean the following appears in the log:
13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
because no targets are running for reference WebServiceContainer 
matching the patterns 
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer 





and then at the end of the startup:
13:06:26,725 WARN  [SilentStartupMonitor] Unable to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
(starting)


I guess this means that the bean didn't start ;-) It doesn't answer on 
the address (http://localhost:8080/webservice/CreditCardService) 
specified in the deployment descriptor.


[*Q3]
Have you got any ideas on how to make the beans start?
I notice the J2EEModule=org/apache/geronimo/Jetty in the reference 
matching string in the first log entry. The jetty configuration 
reported by deployer.jar's list-modules is named 
geronimo/jetty/1.0-SNAPSHOT/car.
Could this be related to Q2 on how to get to run on a server with 
"org/apache/geronimo"-naming style for configurations?



I couldn't work on it yesterday, but will certainly tonight. I hope 
others on IRC will help me to understand and fix it once and for all.


It seems wonderful that David Jencks already fixed the bug.

I wasn't able to either build or get maven to download a fresh snapshot.
On the build I'm using (an older homebrew version as far as I can tell), 
I'm getting an ArrayIndexOutOfBoundsException during deployment of OPC, 
it seems related to some repository lookup. The entire stacktrace in my 
JIRA comment.


Maybe you would be able to get my files from the JIRA and give it at try?

I'm afraid I won't be able to work on anything Geronimo until monday 
morning - but I'm looking forward to logging on and getting the status here.


Kindly,
Jakob


Re: Java Adventure Builder Reference 1.0.3 webapp deployed

2005-12-08 Thread Jakob Færch (Trifork)

Jakob Færch (Trifork) wrote:
Nevertheless, when starting the server, none of the web service endpoint 
beans are able to start. As an example, for the CreditCardEndpointBean 
the following appears in the log:
13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
because no targets are running for reference WebServiceContainer 
matching the patterns 
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer 



and then at the end of the startup:
13:06:26,725 WARN  [SilentStartupMonitor] Unable to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
(starting)


I guess this means that the bean didn't start ;-) It doesn't answer on 
the address (http://localhost:8080/webservice/CreditCardService) 
specified in the deployment descriptor.


[*Q3]
Have you got any ideas on how to make the beans start?
I notice the J2EEModule=org/apache/geronimo/Jetty in the reference 
matching string in the first log entry. The jetty configuration reported 
by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car.
Could this be related to Q2 on how to get to run on a server with 
"org/apache/geronimo"-naming style for configurations?


The issue seems very similar to the problem Jacek faced in
<http://www.nabble.com/WARN-SilentStartupMonitor-Unable-to-start-...-%28starting%29-t515844.html#a1395857>

But I am not able to figure out the connection; the reference for 
WebServiceContainer must be defined in some GBean - there's no such 
reference in the ear plan I'm trying to deploy (unless it's some default 
reference from any ear that includes a web service exposed EJB).


I've been trying to get the deployer scripts to use my M5 build, but am 
running into all sorts of maven problems. I will continue to try later 
today.


Kindly, Jakob



Re: Java Adventure Builder Reference 1.0.3 webapp deployed

2005-12-08 Thread Jakob Færch (Trifork)

Hi Jacek

The status for my endeavour on the adventure builder:
I have (only locally) plans that enable all the ear files to deploy.

[*Q1]
Would you like me to send you the plans I have developed - I guess the 
repository would be better off with these than with the ones currently 
there.


I have had to replace a few parentId's from e.g. 
org/apache/geronimo/SystemDatabase to 
geronimo/system-database/1.0-SNAPSHOT/car.
It seems to be the case that for the 1.0-SNAPSHOT builds I am able to 
produce, all "internal" configurations follow the "car" naming style 
rather than the "org/apache/geronimo"-naming style. The 1.0-M5 build I 
downloaded follow the "org/apache/geronimo"-naming style.
I guess we will have to get the application running on a build 
resembling M5.


[*Q2]
Is there an easy way to make the maven script in 
sandbox/adventurebuilder use the M5-build. I tried changing 
geronimo_version in src/etc/project.properties to 1.0-M5, but that 
doesn't seem to do the trick.


The server starts and afterwards and a superficial poke around the 
consumer web site seems to have it working all right.
All the configurations corresponding to ear's in the application are in 
state running.


Nevertheless, when starting the server, none of the web service endpoint 
beans are able to start. As an example, for the CreditCardEndpointBean 
the following appears in the log:
13:06:11,032 DEBUG [GBeanSingleReference] Waiting to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
because no targets are running for reference WebServiceContainer 
matching the patterns 
geronimo.server:J2EEApplication=null,J2EEModule=org/apache/geronimo/Jetty,J2EEServer=geronimo,j2eeType=GBean,name=JettyWebContainer 



and then at the end of the startup:
13:06:26,725 WARN  [SilentStartupMonitor] Unable to start 
geronimo.server:name=CreditCardEndpointBean,J2EEServer=geronimo,J2EEApplication=org/apache/geronimo/Bank1.0.3,j2eeType=WSLink,J2EEModule=null 
(starting)


I guess this means that the bean didn't start ;-) It doesn't answer on 
the address (http://localhost:8080/webservice/CreditCardService) 
specified in the deployment descriptor.


[*Q3]
Have you got any ideas on how to make the beans start?
I notice the J2EEModule=org/apache/geronimo/Jetty in the reference 
matching string in the first log entry. The jetty configuration reported 
by deployer.jar's list-modules is named geronimo/jetty/1.0-SNAPSHOT/car.
Could this be related to Q2 on how to get to run on a server with 
"org/apache/geronimo"-naming style for configurations?


Kindly,
Jakob



Re: Java Adventure Builder Reference 1.0.3 webapp deployed

2005-12-07 Thread Jakob Færch (Trifork)

Selvaraj, Saraswathi (Cognizant) wrote:

Hi Jakob,
Herewith I am resending all the latest plans along with the jms plan that I 
have.  Still now I don't have plans for mail & principal objects.

   The plans included:
(1) activitysupplier-plan
(2) airlinesupplier-plan
(3) bank-plan
(4) lodgingsupplier-plan
(5) opc-plan
(6) processmanager-plan
(7) jms-plan


Thanks a lot. I have started to incorporate the plans that are not in 
the repository into application plans to match the deployment script; I 
will continue this evening (it's 3 pm now).


I guess it would speed up my work a tiny bit if you would distribute the 
 sql to create the data tables not already created by ab1.0.1.sql in 
the repository.


Kindly,
Jakob

(I have been unable to connect to cvs.apache.org all day, so I apologize 
if any of my requests are already in the repository)


Re: Java Adventure Builder Reference 1.0.3 webapp deployed

2005-12-07 Thread Jakob Færch (Trifork)

Jakob Roesgaard Færch wrote:

Jacek Laskowski wrote:

Whow! Thanks for sharing them with us. With them all I think we can 
achieve the goal of deploying PetStore and Adventure Builder on time 
*before* 1.0 is announced.



I'm a little uneasy about the fact that we still need to add CMP fields 
to the CMP beans to make the application deploy - with this limitation, 
will we able to claim that Geronimo is compatible with the adventure 
builder app?




It seems my limited understanding got me fooled :-(

The fields that Saraswathi has added are of course "virtual" OpenEJB 
fields, so the application deploys without any changes. I'm sorry for 
making such ado about nothing.


Kindly, Jakob