`

Connecting Apache’s Web Server to Multiple Instances of Tomcat

    博客分类:
  • WEB
阅读更多

http://www.linuxjournal.com/article/8561

 

Recently, I was asked to reorganize some of our Web applications to
improve their stability. The major push was to get each of our applications
running in its own instance of Tomcat. These applications all are in
various stages of development, and if a single instance allocates all of
the memory available, the entire Tomcat server must be restarted. This,
in turn, brings down all of the other applications.

An obstacle to running multiple instances is each instance would
have to run on a unique port. Enter Apache's Web server. With the use
of mod_jk, we were able to forward requests to specific hosts and contexts
to the respective running instance of Tomcat.

Pulling all of this together was not the hardest thing I've done;
however, it did prove challenging due to a lack of documentation. By no
means, though, is this statement a stab at any of the development teams. In fact,
the developers themselves helped me on numerous occasions when I found myself
in over my head. When the documentation had me confused or I could not find
exactly what I was looking for, I would head over to #tomcat or #apache on
irc.freenode.org and pose my question there. Usually, I received a response
within minutes.

The following software was used for the purposes of this article. See
the resources section at the end of this article for download locations:

  • J2sdk1.4.2_09
  • Tomcat 5.0.28
  • Apache 2.0.54
  • mod_jk 1.2.14

I am certain some of you are wondering why I used the Java software
development kit (SDK) rather than the Java runtime environment (JRE).
The answer is simple: Tomcat requires tools.jar to compile JSP pages,
and tools.jar is provided in the SDK. If you do not wish to use the SDK,
you need to place tools.jar in $CATALINA_HOME\common\lib.
Assumptions
For the purposes of this article, I assume that you already
have Apache, Java and Tomcat installed. With all of the software listed
above installed, except mod_jk, let's set up our environment.

In order for Tomcat to start, you need to set two environment
variables, JAVA_HOME and CATALINA_HOME. JAVA_HOME should point to the
J2sdk installation directory, and CATALINA_HOME should point to the installation
directory for Tomcat. To make life easier, I have placed the
following lines in /etc/bashrc:

export JAVA_HOME=/usr/java/j2sdk1.4.2_09
export CATALINA_HOME=/opt/tomcat 

Notice that I have set CATALINA_HOME to /opt/tomcat. Although this is
the case, /opt/tomcat actually is a symlink to
/opt/jakarta-tomcat-5.0.28. Although you can tell which version of
Tomcat you have installed by running $CATALINA_HOME/bin/catalina.sh
version, I prefer to be able to note the version immediately by
looking at the installation directory.

Before we dive into compiling mod_jk, I would like to dispel some
confusion I came across while working on this project. Specifically, the
confusion centers around the myth that bigger is better. In the world of
Tomcat connectors, there exists mod_jk and mod_jk2. In my mind mod_jk2
was the logical choice, as it had a higher version number. After a bit of
probing and inquiring, however, I discovered that mod_jk2 is
deprecated--it is no longer being developed. Unfortunately for me, I
had invested several hours in getting mod_jk2 to work when I discovered
this fact. Hopefully, you will have saved yourself some time by reading this article.
Compiling, Installing and Configuring mod_jk
Open a terminal and change directories to the location where you have
saved the mod_jk source. See the Resources section at the end of this
article for the download link. In the terminal window, extract the
source archive and install with the following four lines:

tar -xzvf jakarta-tomcat-connectors-1.2.14.1-src.tar.gz
cd jakarta-tomcat-connectors-1.2.14.1/jk/native
./configure --with-axps=/usr/sbin/axps 
make && make install

The --with-axps=/usr/sbin/apxs configuration option allows us to build
Apache modules without requiring the Apache source. If all goes well,
you should see a message near the end informing you of the location of
the libraries. On my distribution, it is /usr/lib/httpd/modules.

With mod_jk installed, we must now configure Apache to load the module
by editing httpd.conf. httpd.conf is located in /etc/httpd/conf on my
system. Configuring Apache to load mod_jk is a simple two-line step:

#Load the mod_jk connector LoadModule jk_module
/usr/lib/httpd/modules/mod_jk.so

A mistake I initially made was naming the module mod_jk, as in
LoadModule mod_jk /usr/lib/httpd/modules/mod_jk.so.
The above command is certain to make Apache complain and refuse to start. With
that said, it is a good idea to start or restart Apache now to verify
that it can load the newly compiled module. If Apache starts
without a problem, it is safe to continue.
Setting Up Multiple Tomcat Instances
Multiple Tomcat instances are possible to create with the use of the CATALINA_BASE
environment variable. Each instance uses a common binary distribution
but uses its own conf, webapps, temp, logs and work directories.
Each instance also has its own JVM and, thereby, its own memory
pool. If you have defined the maximum memory to be 512MB via JAVA_OPTS,
each instance will attempt to allocate a maximum of 512MB.

Let's proceed now to set up these directories. As I mentioned before,
Tomcat is installed in /opt/tomcat. To keep things somewhat organized,
I created the following folders in /opt: /opt/tomcat_instance1,
/opt/tomcat_instance2 and /opt/tomcat_instance3. It probably is more
appropriate, however, to name these folders based on their purposes or
applications. Remember that each of the three folders will contain
conf, webapps, temp and work directories.
Configuring the First Instance
Tomcat uses a server.xml configuration file to determine
the ports, connector engines and various other "server"
configuration options. We are going to copy the installed
server.xml from $CATALINA_HOME/conf/server.xml to
/opt/tomcat_instance1/conf/server.xml. While we are at
it, we might as well copy $CATALINA_HOME/con/server.xml
to /opt/tomcat_instance2/conf/server.xml and
/opt/tomcat_instance3conf/server.xml as well.

Tomcat also uses a global web.xml file. By global, I mean it is used
for each instance. The web.xml file provides the default configuration
for each Web application running under the given instance. If an option is not defined in the
individual Web application, the default web.xml option is used.
We can copy $CATALINA_HOME/conf/web.xml to /opt/tomcat_instance1/conf,
/opt/tomcat_instance2/conf and /opt/tomcat_instance3/conf.

Now we must make some edits to server.xml. First, we need to disable
the Coyote connector. To do this, we comment out the Coyote connector
information. This is an XML file, so it uses the same comment syntax as
HTML. After we are done commenting out the the connector, it should look
something like this:

 <!-- 
  <Connector port="8080"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               debug="0" connectionTimeout="20000"
               disableUploadTimeout="true" />
 -->

Because this is the first running instance, we do not need to modify
any more of this file. For subsequent instances, we are required to
change the shutdown port and the AJP connector port. The AJP connector
port is the port that Apache uses to forward requests.

Next, copy the servlets-examples file provided with the
installation of Tomcat from $CATALINA_HOME/webapps/servlets-examples to
/opt/tomcat_instance1/webapps/servlets-examples. Again, copy the sample
application to /opt/tomcat_instance2/webapps and
/opt/tomcat_instance3/webapps as well. At this point, the set up of
tomcat_instance1 is complete. We now need to set up the second and third
instances before we pull it all together.
Configuring the Second Instance
We already copied server.xml from the installation directory. We now
need to make the same edit to /opt/tomcat_instance2/conf/server.xml as we
did for the first instance. That is, comment out the Coyote connector exactly as
we did above.

Additional required edits are to change the SHUTDOWN port from 8005 to
8105. We must change the port from 8005 because the first instance
already is using it. You can change the second instance's port to be
any unused port above 1024, but for simplicity and organization's sake,
let's use 8105. Here is the line as it should be in the file:

<Server port="8105" shutdown="SHUTDOWN" debug="0">

Now we must change the AJP connector from 8009 to 8109. Again, this is
required because the first instance already is using 8009. Below
is the line to change with the required edit:

    <Connector port="8109"
	enableLookups="false" redirectPort="8443" debug="0"
      protocol="AJP/1.3" />

If you are using SSL, you also should change the redirectPort to
the appropriate SSL port that Apache is listening on, normally 443.
Configuring the Third Instance
We need to make the same edits to /opt/tomcat_instance3/conf/server.xml as we
did for the second instance, except we substitute 8205 for 8005 and
8209 for 8009. In case this does not make sense, here are the respective
sections of server.xml:

<Server port="8205" shutdown="SHUTDOWN" debug="0">

    <Connector port="8209"
	enableLookups="false" redirectPort="8443" debug="0"
      protocol="AJP/1.3" />

Configuring mod_jk
mod_jk uses a file named workers.properties. I recommend placing this
file with the rest of your Apache configuration files. workers.properties
is used to define where Apache looks for the Tomcat instances. Here, I
cover only the items we are going to use for the three instances we have
set up. Below is the workers.properties file we are going to use,
followed by an explanation of the options:

worker.list=worker1,worker2,worker3
# Set properties for worker1
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
# Set properties for worker2
worker.worker2.type=ajp13
worker.worker2.host=localhost
worker.worker2.port=8109
# Set properties for worker3
worker.worker3.type=ajp13
worker.worker3.host=localhost
worker.worker3.port=8209

worker.list is a comma-separated list of worker names. You could have
Tomcat workers defined later in the file that will not be used. Any worker
defined is not used unless the worker is listed in the worker.list value.
Workers are defined in format of
worker.NAMEOFWORKER.type, with the value being
the type of connector. All of our workers are of type ajp13. In the
above example, we have defined three workers: worker1, worker2 and worker3.

You may have noticed the host portion of the configuration. This can
be used to configure Apache to forward to Tomcat instances on separate
machines. In fact, this is an option that one might choose to employ in
order to make a site more secure. Because Tomcat and Apache both reside
on the same machine, we use localhost.

Each worker also needs to define the port on which the connector is configured
to work. If you remember, earlier we configured instance1 to listen
on port 8009, instance2 to listen on port 8109 and instance3 to listen
on port 8209.
Configuring Apache with mod_jk
To get all of this started, we need to tell Apache where to find the
workers.properties file and where to log mod_jk requests. We also need
to specify the format of the log files and the options specific to
mod_jk. I did this by adding the following lines to httpd.conf; I
placed all mod_jk configuration directives just before the virtual
host declarations:

JkWorkersFile "/etc/httpd/conf/workers.properties"
JkLogFile     "/var/logs/www/mod_jk.log"
JkLogLevel  info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions     +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat     "%w %V %T"

The above options tell Apache to use /etc/httpd/conf/workers.properties
for the worker definitions and to use the /var/logs/www/mod_jk.log
log file. If you are experiencing trouble with mod_jk, adjust the
JkLogLevel to "debug" in order to get more verbose messages. JKLogStampFormat
and JkRequestLogFormat define the logging formats. The option
ForwardKeySize instructs mod_jk to forward the SSL key size along with
the request. ForwardURICompat instructs mod_jk to forward the URL to
Tomcat normally. -FowardDirectories instructs mod_jk not to return a
directory listing from Tomcat.
Configuring Apache to Forward
We use domain1, domain2 and domain3 as our virtual hosts. To pull this
off, we also have to edit /etc/hosts to ensure that domain1, domain2
and domain3 are resolved properly. To do this, we make three
VirtualDirectory declarations, each corresponding to a worker defined
in workers.properties. Below is the VirtualHosts section, followed
by an explanation of the options.

<VirtualHost *:80>
    ServerName domain1
    JkMount  /servlets-examples/* worker1
</VirtualHost>
<VirtualHost *:80>
    ServerName domain2
    JkMount  /servlets-examples/* worker2
</VirtualHost>
<VirtualHost *:80>
    ServerName domain3
    JkMount  /servlets-examples/* worker3
</VirtualHost>

Configuring the Instances to Start at Boot
Now that we have most of the configuration complete, it is time to set
up the instances to start at boot. This partially is done by creating
a bash script and placing it in /etc/init.d. I used the start-up
script found
here.

#!/bin/bash
#
# tomcat        
#
# chkconfig: 
# description:  Start up the Tomcat servlet engine.

# Source function library.
. /etc/init.d/functions


RETVAL=$?
export CATALINA_BASE="/opt/tomcat_instance1"
export CATALINA_HOME="/opt/tomcat"

case "$1" in
 start)
        if [ -f $CATALINA_HOME/bin/startup.sh ];
          then
            echo $"Starting Tomcat"
            /bin/su tomcat $CATALINA_HOME/bin/startup.sh
        fi
        ;;
 stop)
        if [ -f $CATALINA_HOME/bin/shutdown.sh ];
          then
            echo $"Stopping Tomcat"
            /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh
        fi
        ;;
 *)
        echo $"Usage: $0 {start|stop}"
        exit 1
        ;;
esac
exit $RETVAL

Copy the contents above and place them in /etc/init.d/tomcat_instance1, /etc/init.dtomcat_instance2 and
/etc/init.d/tomcat_instance3. Be sure to change CATALINA_BASE to
the appropriate directory for each script. Now, we need to link to
these in /etc/rc5.d. To create the symlinks, issue the following as root:

cd /etc/rc5.d
ln -s /etc/init.d/tomcat_instance1  S71tomcat_service1
ln -s /etc/init.d/tomcat_instance2 S71tomcat_service2
ln -s /etc/init.d/tomcat_instance3 S71tomcat_service3

Testing the Setup
With all of our configuration complete, it now is time to test our
setup. We begin by starting Apache or restarting if it already is
running. Next, bring up the first instance:

/etc/init.d/httpd stop
/etc/init.d/httpd start
/etc/init.d/tomcat_service1 start

Now, open a browser window and go to http://domain1/servlets-examples/.
If all goes well, you should see something similar to Figure 1.
Figure 1. Checking Your Setup
If you do not see a page similar to the above, look in the
log files. Specifically, check /var/logs/httpd/mod_jk.log and
/opt/tomcat_instance1/logs/catalina.out for any errors that may have
occurred.

If everything looks correct, go ahead and start the remaining
two contexts:

/etc/init.d/tomcat_instance2 start
/etc/init.d/tomcat_instance3 start

Point your browser to http://domain2/servlets-examples and
http://domain3/servlets-examples. You should see the exact same page
for all three instances.

To make things a bit more clear and to verify that we are hitting the
correct instance, we can modify a line
in /opt/tomcat_instance2/webapps/servlets-examples/index.html and
/opt/tomcat_instance3/webapps/servlets-examples/index.html. The line to
modify in both files is:

<b><font face="Arial, Helvetica, sans-serif"><font size=+2>Servlet
Examples with Code</font></font></b>

For the second instance, we want the line to read as follows:

<b><font face="Arial, Helvetica, sans-serif"><font size=+2>Domain 2 Servlet
Examples with Code</font></font></b>

Make a similar modification to the third instance:

<b><font face="Arial, Helvetica, sans-serif"><font size=+2>Domain 3 Servlet
Examples with Code</font></font></b>

If you now point your browser to http://domain2/servlets-examples and
http://domain3/servlets-examples, you should see Domain 2 and Domain 3 at
the beginning of the respective page.
Conclusion
Hopefully this HOWTO has given you a step-by-step understanding of what
it takes to get multiple instances of Tomcat running when Apache is
the front-end. Many more options are available that would produce similar
setups. You could, for example, use Apache as a front-end and load
balance between several servers running Tomcat. See the documentation
for mod_jk for more information about the available options.
Resources
The Apache
Jakarta Tomcat Connector

Jakarta-Tomcat
Connectors Source Files

Apache Tomcat

J2SE

Apache

分享到:
评论

相关推荐

    受激拉曼散射计量【Stimulated-Raman-Scattering Metrology】 附Matlab代码.rar

    1.版本:matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点:参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象:计算机,电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。

    MMC整流器技术解析:基于Matlab的双闭环控制策略与环流抑制性能研究,Matlab下的MMC整流器技术文档:18个子模块,双闭环控制稳定直流电压,环流抑制与最近电平逼近调制,优化桥臂电流波形,高效

    MMC整流器技术解析:基于Matlab的双闭环控制策略与环流抑制性能研究,Matlab下的MMC整流器技术文档:18个子模块,双闭环控制稳定直流电压,环流抑制与最近电平逼近调制,优化桥臂电流波形,高效并网运行。,MMC整流器(Matlab),技术文档 1.MMC工作在整流侧,子模块个数N=18,直流侧电压Udc=25.2kV,交流侧电压6.6kV 2.控制器采用双闭环控制,外环控制直流电压,采用PI调节器,电流内环采用PI+前馈解耦; 3.环流抑制采用PI控制,能够抑制环流二倍频分量; 4.采用最近电平逼近调制(NLM), 5.均压排序:电容电压排序采用冒泡排序,判断桥臂电流方向确定投入切除; 结果: 1.输出的直流电压能够稳定在25.2kV; 2.有功功率,无功功率稳态时波形稳定,有功功率为3.2MW,无功稳定在0Var; 3.网侧电压电流波形均为对称的三相电压和三相电流波形,网侧电流THD=1.47%<2%,符合并网要求; 4.环流抑制后桥臂电流的波形得到改善,桥臂电流THD由9.57%降至1.93%,环流波形也可以看到得到抑制; 5.电容电压能够稳定变化 ,工作点关键词:MMC

    Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪:基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪:基

    Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪:基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪:基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构,Simulink建模,MPPT最大功率点追踪,扰动观察法采用功率反馈方式,若ΔP>0,说明电压调整的方向正确,可以继续按原方向进行“干扰”;若ΔP<0,说明电压调整的方向错误,需要对“干扰”的方向进行改变。 ,Boost升压;光伏并网结构;Simulink建模;MPPT最大功率点追踪;扰动观察法;功率反馈;电压调整方向。,光伏并网结构中Boost升压MPPT控制策略的Simulink建模与功率反馈扰动观察法

    STM32F103C8T6 USB寄存器开发详解(12)-键盘设备

    STM32F103C8T6 USB寄存器开发详解(12)-键盘设备

    2011-2020广东21市科技活动人员数

    科技活动人员数专指直接从事科技活动以及专门从事科技活动管理和为科技活动提供直接服务的人员数量

    Matlab Simulink仿真探究Flyback反激式开关电源性能表现与优化策略,Matlab Simulink仿真探究Flyback反激式开关电源的工作机制,Matlab Simulimk仿真

    Matlab Simulink仿真探究Flyback反激式开关电源性能表现与优化策略,Matlab Simulink仿真探究Flyback反激式开关电源的工作机制,Matlab Simulimk仿真,Flyback反激式开关电源仿真 ,Matlab; Simulink仿真; Flyback反激式; 开关电源仿真,Matlab Simulink在Flyback反激式开关电源仿真中的应用

    基于Comsol的埋地电缆电磁加热计算模型:深度解析温度场与电磁场分布学习资料与服务,COMSOL埋地电缆电磁加热计算模型:温度场与电磁场分布的解析与学习资源,comsol 埋地电缆电磁加热计算模型

    基于Comsol的埋地电缆电磁加热计算模型:深度解析温度场与电磁场分布学习资料与服务,COMSOL埋地电缆电磁加热计算模型:温度场与电磁场分布的解析与学习资源,comsol 埋地电缆电磁加热计算模型,可以得到埋地电缆温度场及电磁场分布,提供学习资料和服务, ,comsol;埋地电缆电磁加热计算模型;温度场分布;电磁场分布;学习资料;服务,Comsol埋地电缆电磁加热模型:温度场与电磁场分布学习资料及服务

    ibus-table-chinese-yong-1.4.6-3.el7.x64-86.rpm.tar.gz

    1、文件内容:ibus-table-chinese-yong-1.4.6-3.el7.rpm以及相关依赖 2、文件形式:tar.gz压缩包 3、安装指令: #Step1、解压 tar -zxvf /mnt/data/output/ibus-table-chinese-yong-1.4.6-3.el7.tar.gz #Step2、进入解压后的目录,执行安装 sudo rpm -ivh *.rpm 4、更多资源/技术支持:公众号禅静编程坊

    基于51单片机protues仿真的汽车智能灯光控制系统设计(仿真图、源代码)

    基于51单片机protues仿真的汽车智能灯光控制系统设计(仿真图、源代码) 一、设计项目 根据本次设计的要求,设计出一款基于51单片机的自动切换远近光灯的设计。 技术条件与说明: 1. 设计硬件部分,中央处理器采用了STC89C51RC单片机; 2. 使用两个灯珠代表远近光灯,感光部分采用了光敏电阻,因为光敏电阻输出的是电压模拟信号,单片机不能直接处理模拟信号,所以经过ADC0832进行转化成数字信号; 3. 显示部分采用了LCD1602液晶,还增加按键部分电路,可以选择手自动切换远近光灯; 4. 用超声模块进行检测距离;

    altermanager的企业微信告警服务

    altermanager的企业微信告警服务

    MyAgent测试版本在线下载

    MyAgent测试版本在线下载

    Comsol技术:可调BIC应用的二氧化钒VO2材料探索,Comsol模拟二氧化钒VO2的可调BIC特性研究,Comsol二氧化钒VO2可调BIC ,Comsol; 二氧化钒VO2; 可调BIC

    Comsol技术:可调BIC应用的二氧化钒VO2材料探索,Comsol模拟二氧化钒VO2的可调BIC特性研究,Comsol二氧化钒VO2可调BIC。 ,Comsol; 二氧化钒VO2; 可调BIC,Comsol二氧化钒VO2材料:可调BIC技术的关键应用

    C++学生成绩管理系统源码.zip

    C++学生成绩管理系统源码

    基于Matlab与Cplex的激励型需求响应模式:负荷转移与电价响应的差异化目标函数解析,基于Matlab与CPLEX的激励型需求响应负荷转移策略探索,激励型需求响应 matlab +cplex 激励

    基于Matlab与Cplex的激励型需求响应模式:负荷转移与电价响应的差异化目标函数解析,基于Matlab与CPLEX的激励型需求响应负荷转移策略探索,激励型需求响应 matlab +cplex 激励型需求响应采用激励型需求响应方式对负荷进行转移,和电价响应模式不同,具体的目标函数如下 ,激励型需求响应; matlab + cplex; 负荷转移; 目标函数。,Matlab与Cplex结合的激励型需求响应模型及其负荷转移策略

    scratch介绍(scratch说明).zip

    scratch介绍(scratch说明).zip

    深度学习模型的发展历程及其关键技术在人工智能领域的应用

    内容概要:本文全面介绍了深度学习模型的概念、工作机制和发展历程,详细探讨了神经网络的构建和训练过程,包括反向传播算法和梯度下降方法。文中还列举了深度学习在图像识别、自然语言处理、医疗和金融等多个领域的应用实例,并讨论了当前面临的挑战,如数据依赖、计算资源需求、可解释性和对抗攻击等问题。最后,文章展望了未来的发展趋势,如与量子计算和区块链的融合,以及在更多领域的应用前景。 适合人群:对该领域有兴趣的技术人员、研究人员和学者,尤其适合那些希望深入了解深度学习原理和技术细节的读者。 使用场景及目标:①理解深度学习模型的基本原理和结构;②了解深度学习模型的具体应用案例;③掌握应对当前技术挑战的方向。 阅读建议:文章内容详尽丰富,读者应在阅读过程中注意理解各个关键技术的概念和原理,尤其是神经网络的构成及训练过程。同时也建议对比不同模型的特点及其在具体应用中的表现。

    day02供应链管理系统-补充.zip

    该文档提供了一个关于供应链管理系统开发的详细指南,重点介绍了项目安排、技术实现和框架搭建的相关内容。 文档分为以下几个关键部分: 项目安排:主要步骤包括搭建框架(1天),基础数据模块和权限管理(4天),以及应收应付和销售管理(5天)。 供应链概念:供应链系统的核心流程是通过采购商品放入仓库,并在销售时从仓库提取商品,涉及三个主要订单:采购订单、销售订单和调拨订单。 大数据的应用:介绍了数据挖掘、ETL(数据抽取)和BI(商业智能)在供应链管理中的应用。 技术实现:讲述了DAO(数据访问对象)的重用、服务层的重用、以及前端JS的继承机制、jQuery插件开发等技术细节。 系统框架搭建:包括Maven环境的配置、Web工程的创建、持久化类和映射文件的编写,以及Spring配置文件的实现。 DAO的需求和功能:供应链管理系统的各个模块都涉及分页查询、条件查询、删除、增加、修改操作等需求。 泛型的应用:通过示例说明了在Java语言中如何使用泛型来实现模块化和可扩展性。 文档非常技术导向,适合开发人员参考,用于构建供应链管理系统的架构和功能模块。

    清华大学104页《Deepseek:从入门到精通》

    这份长达104页的手册由清华大学新闻与传播学院新媒体研究中心元宇宙文化实验室的余梦珑博士后及其团队精心编撰,内容详尽,覆盖了从基础概念、技术原理到实战案例的全方位指导。它不仅适合初学者快速了解DeepSeek的基本操作,也为有经验的用户提供了高级技巧和优化策略。

    MXTU MAX仿毒舌自适应主题源码 苹果CMSv10模板.zip

    主题说明: 1、将mxtheme目录放置根目录 | 将mxpro目录放置template文件夹中 2、苹果cms后台-系统-网站参数配置-网站模板-选择mxpro 模板目录填写html 3、网站模板选择好之后一定要先访问前台,然后再进入后台设置 4、主题后台地址: MXTU MAX图图主题,/admin.php/admin/mxpro/mxproset admin.php改成你登录后台的xxx.php 5、首页幻灯片设置视频推荐9,自行后台设置 6、追剧周表在视频数据中,节目周期添加周一至周日自行添加,格式:一,二,三,四,五,六,日

    基于matlab平台的数字信号处理GUI设计.zip

    运行GUI版本,可二开

Global site tag (gtag.js) - Google Analytics