Connection Refused in Tomcat build
22 views
Skip to first unread message
ldibanyez
Nov 24, 2009, 12:24:36 PM11/24/09
to tempo-dev
Hi,
After the switch to Jetty as Servlet Container, i was interested in
keeping one copy with tomcat. After some reading, i modified the rsc/
scripts/config.rb, commenting the Jetty mode and uncommenting the
# build with ode, axis2, uifw
#
:mode => [BuildMode::BPMS,BuildMode::UIFW],
#
line.
The build went ok, and i regenerate the database to test.
I configured that instance to run in port 8280 by changing the
server.xml file in tomcat. But when i tried to login,failed, raising a
java.net.ConnectionRefused exception. I doubled check the JNDI and its
ok.
The weird thing is that when i connect with the Jetty instance to the
same database, it works ok. And moreover, after that, the tomcat
instance starts to work ok too (even after cleaning cache, cookies and
sessions from the browser)
Any clue about this? Maybe something related with the port change?
After the switch to Jetty as Servlet Container, i was interested in
keeping one copy with tomcat. After some reading, i modified the rsc/
scripts/config.rb, commenting the Jetty mode and uncommenting the
# build with ode, axis2, uifw
#
:mode => [BuildMode::BPMS,BuildMode::UIFW],
#
line.
The build went ok, and i regenerate the database to test.
I configured that instance to run in port 8280 by changing the
server.xml file in tomcat. But when i tried to login,failed, raising a
java.net.ConnectionRefused exception. I doubled check the JNDI and its
ok.
The weird thing is that when i connect with the Jetty instance to the
same database, it works ok. And moreover, after that, the tomcat
instance starts to work ok too (even after cleaning cache, cookies and
sessions from the browser)
Any clue about this? Maybe something related with the port change?
Nicolas Modrzyk
Nov 24, 2009, 9:07:54 PM11/24/09
to temp...@googlegroups.com
Quick answer. Yes, the port change is the cause.
A grep/replace script to replace all the ports is your best bet. There are a few configuration files you need to do that. (var/config) also deployed files have urls to change.
if you have a nice ruby script you want to contribute, we are interested. :)
For the record, I just checked tomcat on a regular port and it worked no problems.
Nicolas,
A grep/replace script to replace all the ports is your best bet. There are a few configuration files you need to do that. (var/config) also deployed files have urls to change.
if you have a nice ruby script you want to contribute, we are interested. :)
For the record, I just checked tomcat on a regular port and it worked no problems.
Nicolas,
--
You received this message because you are subscribed to the Google Groups "tempo-dev" group.
To post to this group, send email to temp...@googlegroups.com.
To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tempo-dev?hl=en.
ldibanyez
Nov 25, 2009, 5:06:34 PM11/25/09
to tempo-dev
Well, i've started to filter the outcome of grep -R "8080" * in both
the tempo git clone and the generated tomcat bundle. After getting rid
of logs, tomcat examples and yui's color codes, i've found:
In the tempo clone:
1) Under "test" folder, a lot of xml config files under MODULE/src |
target/resources/* with references to localhost:8080, which i think is
ok. But, there are some java files wired with the 8080 reference, in
the ui-fw module, that would be a problem if someone needs to run the
tests in other port.
2) Under "config" xml files for each module (maybe from here the test
port should be picked?)
3) Liferay, jetty and tomcat config files. I suppose that if i change
some here, the tempo_builder would configure the container for the
generated bundle accordingly. Am i right?
4) In the tempo_builder_lib.rb script, a couple of methods:
set_tomcat_ports ({"8005"=>"9005","8080"=>"9080", "8443"=>"9443",
"8009"=> "9009"})
and
replace_all_with_map_in_folder({"localhost:8080"=>"bpms.tempo.com:
8080", "127.0.0.1:8080"=>"bpms.tempo.com:8080"}, "#{@@server_folder}/
var/config")
What this calls do?
5) Finally, the following src/main/*.java references in the code:
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _pxeBaseUrl =
"http://localhost:8080/ode";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _fdsUrl = "http://
localhost:8080/fds/workflow/ib4p";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _tmsUrl = "http://
localhost:8080/axis2/services/TaskManagementServices";
tas-service/src/main/java/org/intalio/tempo/workflow/tas/core/
WDSStorageStrategy.java: * WDS endpoint (including the trailing
slash), such as <code>http://localhost:8080/wds/</code>
tas-service/src/main/java/org/intalio/tempo/workflow/tas/sling/
SlingStorageStrategy.java: private String slingUrl = "http://
localhost:8080/sling";
ui-fw/src/main/java/org/intalio/tempo/uiframework/
Configuration.java: private String _tmpEndpoint = "http://localhost:
8080/ode/processes/completeTask";
This seems important for the port changing issue.
In the Generated tomcat Bundle:
1) The binary coincidences of the .class corresponding to 5) above.
2) tomcat config files.
3) Tempo config files, guess the same ones in 2) above.
4) The Deployed WSDL and BPEL files has references to localhost:8080,
You put this reference in the designer? or is configured somewhere in
tempo?
5) One jsp file wired.
webapps/ode/fileupload.jsp: opts.setTo(new
EndpointReference("http://localhost:8080/ode/processes/
DeploymentService"));
So, summarizing:
1) Where should be the port change? providing a script at the bundle
seems the best option, but the references in the .java files doesnt
affect?. the other option would be a switch in the tempo_builder.rb to
make a build with the selected port.
2) What can be done with the wired test cases?
I want to contribute, the codebase here is very advanced, and the SOA-
orientation makes it cooler. The problem is that the documentation
sums up to the install.txt file and your answers, which is somewhat
short to understand how to use and how to extend.
Because of that, i'm thinking about contributing with docs, and
modifying the rsc/scripts to make them more flexible. Lets see if my
boss agrees, he wants some workflows automated, not a bunch of ruby
scripts.
I'm more a python-svn guy than ruby-git, but i can give a try.
Sorry for the long statement, but i'm very interested in this.
On 25 nov, 21:07, Nicolas Modrzyk <hellon...@gmail.com> wrote:
> Quick answer. Yes, the port change is the cause.
>
> A grep/replace script to replace all the ports is your best bet. There are a
> few configuration files you need to do that. (var/config) also deployed
> files have urls to change.
>
> if you have a nice ruby script you want to contribute, we are interested. :)
>
> For the record, I just checked tomcat on a regular port and it worked no
> problems.
>
> Nicolas,
>
> > tempo-dev+...@googlegroups.com<tempo-dev%2Bunsu...@googlegroups.com>
> > .
the tempo git clone and the generated tomcat bundle. After getting rid
of logs, tomcat examples and yui's color codes, i've found:
In the tempo clone:
1) Under "test" folder, a lot of xml config files under MODULE/src |
target/resources/* with references to localhost:8080, which i think is
ok. But, there are some java files wired with the 8080 reference, in
the ui-fw module, that would be a problem if someone needs to run the
tests in other port.
2) Under "config" xml files for each module (maybe from here the test
port should be picked?)
3) Liferay, jetty and tomcat config files. I suppose that if i change
some here, the tempo_builder would configure the container for the
generated bundle accordingly. Am i right?
4) In the tempo_builder_lib.rb script, a couple of methods:
set_tomcat_ports ({"8005"=>"9005","8080"=>"9080", "8443"=>"9443",
"8009"=> "9009"})
and
replace_all_with_map_in_folder({"localhost:8080"=>"bpms.tempo.com:
8080", "127.0.0.1:8080"=>"bpms.tempo.com:8080"}, "#{@@server_folder}/
var/config")
What this calls do?
5) Finally, the following src/main/*.java references in the code:
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _pxeBaseUrl =
"http://localhost:8080/ode";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _fdsUrl = "http://
localhost:8080/fds/workflow/ib4p";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _tmsUrl = "http://
localhost:8080/axis2/services/TaskManagementServices";
tas-service/src/main/java/org/intalio/tempo/workflow/tas/core/
WDSStorageStrategy.java: * WDS endpoint (including the trailing
slash), such as <code>http://localhost:8080/wds/</code>
tas-service/src/main/java/org/intalio/tempo/workflow/tas/sling/
SlingStorageStrategy.java: private String slingUrl = "http://
localhost:8080/sling";
ui-fw/src/main/java/org/intalio/tempo/uiframework/
Configuration.java: private String _tmpEndpoint = "http://localhost:
8080/ode/processes/completeTask";
This seems important for the port changing issue.
In the Generated tomcat Bundle:
1) The binary coincidences of the .class corresponding to 5) above.
2) tomcat config files.
3) Tempo config files, guess the same ones in 2) above.
4) The Deployed WSDL and BPEL files has references to localhost:8080,
You put this reference in the designer? or is configured somewhere in
tempo?
5) One jsp file wired.
webapps/ode/fileupload.jsp: opts.setTo(new
EndpointReference("http://localhost:8080/ode/processes/
DeploymentService"));
So, summarizing:
1) Where should be the port change? providing a script at the bundle
seems the best option, but the references in the .java files doesnt
affect?. the other option would be a switch in the tempo_builder.rb to
make a build with the selected port.
2) What can be done with the wired test cases?
I want to contribute, the codebase here is very advanced, and the SOA-
orientation makes it cooler. The problem is that the documentation
sums up to the install.txt file and your answers, which is somewhat
short to understand how to use and how to extend.
Because of that, i'm thinking about contributing with docs, and
modifying the rsc/scripts to make them more flexible. Lets see if my
boss agrees, he wants some workflows automated, not a bunch of ruby
scripts.
I'm more a python-svn guy than ruby-git, but i can give a try.
Sorry for the long statement, but i'm very interested in this.
On 25 nov, 21:07, Nicolas Modrzyk <hellon...@gmail.com> wrote:
> Quick answer. Yes, the port change is the cause.
>
> A grep/replace script to replace all the ports is your best bet. There are a
> few configuration files you need to do that. (var/config) also deployed
> files have urls to change.
>
> if you have a nice ruby script you want to contribute, we are interested. :)
>
> For the record, I just checked tomcat on a regular port and it worked no
> problems.
>
> Nicolas,
>
> > .
Nicolas Modrzyk
Nov 25, 2009, 9:30:32 PM11/25/09
to temp...@googlegroups.com
Good morning,
That is a nice set of questions !
Let's go through them one by one.
That is a nice set of questions !
Let's go through them one by one.
Well, i've started to filter the outcome of grep -R "8080" * in both
the tempo git clone and the generated tomcat bundle. After getting rid
of logs, tomcat examples and yui's color codes, i've found:
As a first, I would say you only need to change the ports on the bundle, not in the source code.
The buildr script has what you need in ruby to change default ports, but you may need to extract it to have a standalone command for it.
The buildr script has what you need in ruby to change default ports, but you may need to extract it to have a standalone command for it.
In the tempo clone:
1) Under "test" folder, a lot of xml config files under MODULE/src |
target/resources/* with references to localhost:8080, which i think is
ok. But, there are some java files wired with the 8080 reference, in
the ui-fw module, that would be a problem if someone needs to run the
tests in other port.
Only two remote tests should really be used for testing. There are in tms-client and they check the entire set of apis for Tempo.
For your own tests, there are also ruby scripts you can use to target the server you want on the port you want which are more accurate. The tests are mostly used to test end to end integration of the different Tempo components.
For your own tests, there are also ruby scripts you can use to target the server you want on the port you want which are more accurate. The tests are mostly used to test end to end integration of the different Tempo components.
2) Under "config" xml files for each module (maybe from here the test
port should be picked?)
Yes, this is the main concerned folder.
3) Liferay, jetty and tomcat config files. I suppose that if i change
some here, the tempo_builder would configure the container for the
generated bundle accordingly. Am i right?
Liferay and Tomcat requires a bit more investigation.
4) In the tempo_builder_lib.rb script, a couple of methods:
set_tomcat_ports ({"8005"=>"9005","8080"=>"9080", "8443"=>"9443",
"8009"=> "9009"})
Yes, those are used to change the default ports when making multi server deployment, when using tomcat+liferay, or opensso-server and a few others.
and
replace_all_with_map_in_folder({"localhost:8080"=>"bpms.tempo.com:
8080", "127.0.0.1:8080"=>"bpms.tempo.com:8080"}, "#{@@server_folder}/
var/config")
What this calls do?
The replace the base urls (and thus ports as well). You can definitely re-use those to make a standalone script.
5) Finally, the following src/main/*.java references in the code:
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _pxeBaseUrl =
"http://localhost:8080/ode";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _fdsUrl = "http://
localhost:8080/fds/workflow/ib4p";
fds/src/main/java/org/intalio/tempo/workflow/fds/
FormDispatcherConfiguration.java: private String _tmsUrl = "http://
localhost:8080/axis2/services/TaskManagementServices";
tas-service/src/main/java/org/intalio/tempo/workflow/tas/core/
WDSStorageStrategy.java: * WDS endpoint (including the trailing
slash), such as <code>http://localhost:8080/wds/</code>
tas-service/src/main/java/org/intalio/tempo/workflow/tas/sling/
SlingStorageStrategy.java: private String slingUrl = "http://
localhost:8080/sling";
ui-fw/src/main/java/org/intalio/tempo/uiframework/
Configuration.java: private String _tmpEndpoint = "http://localhost:
8080/ode/processes/completeTask";
Those are default endpoints and are overridden when loaded.
This seems important for the port changing issue.
Those classes are loaded through spring bean configuration. The default values are set given the different configuration files.
In the Generated tomcat Bundle:
1) The binary coincidences of the .class corresponding to 5) above.
2) tomcat config files.
3) Tempo config files, guess the same ones in 2) above.
4) The Deployed WSDL and BPEL files has references to localhost:8080,
You put this reference in the designer? or is configured somewhere in
tempo?
Yes, designer generates the proper endpoints for each.
5) One jsp file wired.
webapps/ode/fileupload.jsp: opts.setTo(new
EndpointReference("http://localhost:8080/ode/processes/
DeploymentService"));
Hum .. not sure where this one is coming from. It is related to Ode. I usually do not track Ode different releases, unless a major bug is blocking the workflow. For an updated version of Ode, you can refer to their website, and just install a new war file.
So, summarizing:
1) Where should be the port change? providing a script at the bundle
seems the best option, but the references in the .java files doesnt
affect?. the other option would be a switch in the tempo_builder.rb to
make a build with the selected port.
Yes that would be super to have a default port. You would need to put that in the configuration file I guess. One for the http port, and one for the https port.
2) What can be done with the wired test cases?
I leave it up to you. I use ruby/groovy scripts to test everything.
I want to contribute, the codebase here is very advanced, and the SOA-
orientation makes it cooler. The problem is that the documentation
sums up to the install.txt file and your answers, which is somewhat
short to understand how to use and how to extend.
Yes, contributions on the documentation are very welcome. I can open up confluence access anytime you want just mail me.
Because of that, i'm thinking about contributing with docs, and
modifying the rsc/scripts to make them more flexible. Lets see if my
boss agrees, he wants some workflows automated, not a bunch of ruby
scripts.
Well, integration testing and deployment can go through Ruby scripts without problems.
I'm more a python-svn guy than ruby-git, but i can give a try.
Anyone welcome to contribute. :)
Nico
Nico
To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
ldibanyez
Dec 3, 2009, 11:46:33 AM12/3/09
to tempo-dev
Ok, I've just invested the last days learning about ruby and git, and
i think i'm ready to dive in. So, the plan is as follows:
1) I've created a personal git branch named "installScripts", from the
tag 6.0.0.85. I later noticed that there are some differences between
that tag and the current head, but that means a real case where to
practice how to merge. What should be the strategy to send you
changes? patches? get a github for me?
2) I'm going to start using rdoc to document the scripts involved on
the installation process now, after that, i think i can modify them to
install on separated tomcat (and im thinking to add separated
glassfish, but it has less priority on my list)
3) The script to change the ports, separated to change the port
whenever needed, but called from the installation battery, so it can
be defined in config.rb and start from a defined port (default 8080)
thoughts? suggestions?
> > <tempo-dev%2Bunsu...@googlegroups.com<tempo-dev%252Buns...@googlegroups.com>
i think i'm ready to dive in. So, the plan is as follows:
1) I've created a personal git branch named "installScripts", from the
tag 6.0.0.85. I later noticed that there are some differences between
that tag and the current head, but that means a real case where to
practice how to merge. What should be the strategy to send you
changes? patches? get a github for me?
2) I'm going to start using rdoc to document the scripts involved on
the installation process now, after that, i think i can modify them to
install on separated tomcat (and im thinking to add separated
glassfish, but it has less priority on my list)
3) The script to change the ports, separated to change the port
whenever needed, but called from the installation battery, so it can
be defined in config.rb and start from a defined port (default 8080)
thoughts? suggestions?
Nicolas Modrzyk
Dec 3, 2009, 11:22:45 PM12/3/09
to temp...@googlegroups.com
Hi,
This is great news !
Well, once you have a github account, let's get in touch, and I will give you access to the repository and you can then commit straight to it.
Any change to the documentation and adding of new scripts can go straight into the master branch.
We could indeed add a port configuration in the config this is a very good idea.
You would need to specify the http port and the https port I suppose.
Welcome to the team :)
Nico
This is great news !
Well, once you have a github account, let's get in touch, and I will give you access to the repository and you can then commit straight to it.
Any change to the documentation and adding of new scripts can go straight into the master branch.
We could indeed add a port configuration in the config this is a very good idea.
You would need to specify the http port and the https port I suppose.
Welcome to the team :)
Nico
To unsubscribe from this group, send email to tempo-dev+...@googlegroups.com.
ldibanyez
Dec 9, 2009, 11:31:09 AM12/9/09
to tempo-dev
Hi, already opened the github account (ldibanyez), although i'm not
very sure of how this works. I did a fork of tempo, but dont know what
it means yet xD.
I had advanced some in documentation, get slowed some while reading
about buildr.
But know i guess i should merge some stuff, i've seen that ark has
made some script changes last days.
On 4 dic, 23:22, Nicolas Modrzyk <hellon...@gmail.com> wrote:
> Hi,
>
> This is great news !
>
> Well, once you have a github account, let's get in touch, and I will give
> you access to the repository and you can then commit straight to it.
>
> Any change to the documentation and adding of new scripts can go straight
> into the master branch.
>
> We could indeed add a port configuration in the config this is a very good
> idea.
> You would need to specify the http port and the https port I suppose.
>
> Welcome to the team :)
>
> Nico
>
> ...
>
> leer más »
very sure of how this works. I did a fork of tempo, but dont know what
it means yet xD.
I had advanced some in documentation, get slowed some while reading
about buildr.
But know i guess i should merge some stuff, i've seen that ark has
made some script changes last days.
On 4 dic, 23:22, Nicolas Modrzyk <hellon...@gmail.com> wrote:
> Hi,
>
> This is great news !
>
> Well, once you have a github account, let's get in touch, and I will give
> you access to the repository and you can then commit straight to it.
>
> Any change to the documentation and adding of new scripts can go straight
> into the master branch.
>
> We could indeed add a port configuration in the config this is a very good
> idea.
> You would need to specify the http port and the https port I suppose.
>
> Welcome to the team :)
>
> Nico
>
>
> leer más »
Reply all
Reply to author
Forward
0 new messages