2009-04-06 16 views
6

Hiện tại, quá trình xây dựng của tôi bao gồm đóng gói lại tệp chiến tranh với tất cả thư viện java bắt buộc trong WEB-INF/lib và sau đó sao chép tệp chiến dịch vào máy chủ phát triển/demo/production để được triển khai lại bởi tomcat.Làm thế nào để tránh sao chép 40M của java lib trong một WAR khi kích thước của WAR là 41M?

Kích thước của tệp chiến tranh được đóng gói là khoảng 41M và hiện tại có khoảng 40 triệu thư viện java bên ngoài. Có phải là một cách tốt hơn. Bạn đã giải quyết vấn đề này như thế nào?

Máy phát triển của tôi là một hộp cửa sổ với Eclipse làm IDE và Ant làm công cụ xây dựng của tôi. Các máy chủ là tất cả các hộp Linux với Tomcat 5.5.

Tôi có nên thêm tệp jar vào gói chiến dịch ở phía máy chủ không?

Trả lời

17

Tôi có thể nhìn thấy những gì bạn đang nói, và đã có cùng một sự thất vọng với một số ứng dụng web của chúng tôi, nhưng vì sự nhất quán vì lợi ích, tôi sẽ đề nghị bạn giữ những thứ như họ đang có. Nếu sao chép các thư viện vào thư mục tomcat/lib bạn có thể gặp sự cố với classpath hệ thống so với classpath webapp.

Bằng cách giữ mọi thứ vì chúng chắc chắn bạn đang triển khai cùng một nội dung trong quá trình phát triển/demo khi bạn đang trong quá trình sản xuất. Cuộc sống hút khi bạn đang tinh chỉnh công cụ trong sản xuất, hoặc bạn có một số lỗi điên vì bạn quên cập nhật XYZ.jar từ phiên bản 1.6 lên 1.6.1_b33 trong sản xuất và bây giờ nó hoạt động khác với những gì bạn tin là chính xác cùng một mã trên bản demo .

Khi làm việc với thứ gì đó đủ quan trọng để có hệ thống dev/demo/production, tôi nghĩ tính nhất quán là vấn đề hơn nhiều so với kích thước tệp .war.

0

Bạn có thể thêm các lọ không thay đổi vào Đường dẫn thư viện Java ở phía máy chủ hay không và chỉ bao gồm các lọ thay đổi thường xuyên trong WAR của bạn?

+0

Sẽ không thực sự muốn làm hỏng toàn bộ môi trường máy chủ với các thư viện của một ứng dụng web. – kosoant

0

bạn có thể bao gồm thư viện java bên ngoài trong thư mục Tomcat/lib. Bằng cách đó họ ở lại trên máy chủ.

+0

Chỉ cần cẩn thận, điều này có thể gây ra vấn đề nếu các ứng dụng khác trên cùng một máy chủ yêu cầu một phiên bản khác của cùng một lib hoặc các sự cố trong đó một cá thể của một lớp được chia sẻ trên các trình nạp lớp –

+1

Nó cũng có thể gây ra nhiều đau buồn nếu các lớp được tải bởi trình nạp lớp hệ thống cố gắng tải các lớp đang ở trong WAR bằng cách sử dụng trình nạp lớp riêng của nó. Nó có thể là một thiết lập rất mong manh tùy thuộc vào bản chất của các lớp liên quan và nếu chúng cố gắng nạp động các lớp khi chạy. – Robin

+0

Tôi với Matt và Robin về điều này: Sẽ không thực sự muốn mess lên toàn bộ môi trường máy chủ với các thư viện của một webapp. – kosoant

0

Bạn chỉ có thể triển khai dưới dạng tệp JAR, sao chép môi trường triển khai của bạn cục bộ và chỉ sao chép qua các tệp đã thay đổi và bản thân bình. Con đường là vấn đề thực sự duy nhất.

Hoặc bạn có thể xem xét thiết lập EAR.

1

Tomcat có một thư mục shared/lib, là nơi thích hợp cho các phụ thuộc ứng dụng toàn cầu. Tuy nhiên, chúng sẽ được hiển thị cho tất cả các ứng dụng, điều này sẽ ảnh hưởng đến quản lý phụ thuộc và có thể có hậu quả đối với những thứ như biến tĩnh. Tôi không chắc chắn nếu bạn có thể cấu hình bất cứ điều gì tốt hơn trong Tomcat.

Cách khác là chuyển sang vùng chứa web tinh vi hơn. Ví dụ: Máy chủ ứng dụng WebSphere Ấn bản cộng đồng (phiên bản màu xanh lam Geronimo) hỗ trợ per-asset libraries. Các máy chủ thương mại và miễn phí khác cũng hỗ trợ điều này. Tôi biết WebSphere Application Server và tôi chắc chắn bạn có thể làm điều đó trong Glassfish.

+0

Cảm ơn lời khuyên về các thùng chứa nâng cao hơn. – kosoant

0

Tôi làm việc với 'ứng dụng web đã phát' trong các máy chủ phát triển và đôi khi trong quá trình sản xuất. Quá trình triển khai (dựa trên ANT) cập nhật các JAR trong WEB-INF/lib với các gói của chúng tôi. Chỉ trong máy chủ phát triển, chúng tôi kích hoạt tải lại Tomcat, việc này sẽ đảm nhiệm việc khởi động lại ứng dụng khi có sự thay đổi. Bạn nên gán thêm một số bộ nhớ vĩnh viễn cho các Tomcats này và có cách khởi động lại máy chủ, vì việc tải lại có thể làm hỏng Tomcat theo thời gian.

Tôi biết đó là cấu hình kỳ lạ, nhưng tôi không thể hiểu cách liên tục đóng gói lại 30MB (và đang phát triển) của ứng dụng điển hình của chúng tôi có thể làm tốt hơn. Có thể một ngày, bộ mô tả phát triển cho phép các tham chiếu bên ngoài tới các thư viện mà vùng chứa có thể tải xuống và bộ nhớ cache. ??

Xin lỗi tiếng Anh kém của tôi.

1

@McDowell, khi đề cập đến các máy chủ J2EE này, bạn nên chính xác rằng chúng là các máy chủ J2EE (thùng chứa servlet + phần còn lại).

Giống như @digitaljoel, tôi khuyên bạn nên giữ những thứ như vậy. Có vẻ như bạn chưa triển khai nhiều ứng dụng web. Các vấn đề mà bạn sẽ có không đáng giá (xung đột phiên bản, lỗi triển khai, v.v.).

0

Điều bạn cần là công cụ kiểm soát phiên bản và quy trình tạo.

Sử dụng CSV, SVN, GIT hoặc bất kỳ điều gì phù hợp để giữ cho nguồn của bạn được kiểm soát. sử dụng công cụ xây dựng để xây dựng ứng dụng của bạn: Maven, ant, ...

Bây giờ, khi bạn muốn triển khai ứng dụng trên máy chủ, bạn chỉ cần cam kết cập nhật trên máy tính, cập nhật nguồn của bạn máy chủ, xây dựng ứng dụng của bạn và triển khai nó từ máy chủ.

Bằng cách này, máy chủ sẽ chỉ phải tải các sửa đổi của bạn và nó sẽ nhanh hơn nhiều.

5

Chúng tôi sử dụng công cụ rsync cho điều này (trong trường hợp của chúng tôi, sử dụng Cygwin dưới cửa sổ) để sao chép các triển khai đến các máy chủ (chạy Linux). Chúng tôi sử dụng các tệp WAR/EAR đã phát nổ (tức là cấu trúc thư mục có tên MyApp.war chứ không phải tệp zip có tên là MyApp.war), rsync sẽ chỉ chuyển các tệp đã thay đổi.

Sử dụng chung, rsync sẽ chuyển 30-40 megabyte phát nổ EAR của chúng tôi trong khoảng 5 giây.

+0

+1 Tôi đồng ý, tôi cũng làm tương tự từ bên trong một mục tiêu chống kiến – stivlo

Các vấn đề liên quan